Johnson Wong TP047339 DBS Report

GROUP ASSIGNMENT
TECHNOLOGY PARK MALAYSIA

CT069-3-3-DBS
DATABASE SECURITY
UC3F2103CS(DA)
STUDENT NAME : JOHNSON WONG ING CHENG (TP047339)
MUZAMIL MOHAMMED AHMED (TP048867)
RICHARD WIJAYA (TP053319)
LECTURER : MR. ABDALLAH S.M. ALNATSHA

HAND OUT DATE : 04TH AUGUST 2021
HAND IN DATE : 01ST NOVEMBER 2021

CT069-3-3-DBS UC3F2103CS(DA)
Table of Contents
1 Entity Relationship Model (ERM)....................................................................................... 1
1.1 Assumptions .................................................................................................................. 1
1.2 Business Rules ............................................................................................................... 1
1.3 Logical Design ............................................................................................................... 4
1.4 Entity Relationship Diagram (ERD) ............................................................................. 5
2 Database Auditing Environment ......................................................................................... 9
2.1 General Objectives ........................................................................................................ 9
2.2 Audited Entities .......................................................................................................... 10
2.3 People .......................................................................................................................... 11
2.4 Procedures .................................................................................................................. 12
2.5 Database ...................................................................................................................... 12
3.0 Authorization Matrix...................................................................................................... 13
3.1 Richard Wijaya (TP053319) ....................................................................................... 13
3.1.1 Head Nurse ........................................................................................................... 13
3.1.2 General Nurse ...................................................................................................... 14
3.2 Johnson Wong Ing Cheng (TP047339) ....................................................................... 15
3.2.1 Hospital Management .......................................................................................... 15
3.2.2 Doctor ................................................................................................................... 16
3.3 Muzamil Mohammed Ahmed Abdulatief (TP048867)................................................ 17
3.3.1 Trainee Nurse ....................................................................................................... 17
3.3.2 Receptionist .......................................................................................................... 18
4 Individual Users................................................................................................................. 19

5 Logon Trigger.................................................................................................................... 26
6 Data Manipulation Language (DML) Trigger .................................................................. 32
6.1.1 Track changes in the Nurse table ......................................................................... 32
6.1.2 DML trigger to check Actual Leave date ............................................................. 35
6.2.1 DML Trigger to Track Changes/Audit in Ward Entity ....................................... 37
6.2.1 DML Trigger to Check the Number of Beds for Each Ward............................... 40
6.3.1 Track Changes Made to Patient Table................................................................. 42
6.3.2 Avoiding Deletion of Patient Using Instead of Trigger ........................................ 45
7 Encryption ......................................................................................................................... 47
8 Backup and Restore Strategy ............................................................................................ 64
References ............................................................................................................................ 67
Appendices ........................................................................................................................... 69
Workload Matrix .............................................................................................................. 69

1 Entity Relationship Model (ERM)

1.1 Assumptions
To build a full secure database, a few assumptions is needed to be made. The assumptions are as
of follow:
• The hospital consists of a total of 17 wards with 15 wards having 14 beds and 2 wards
having 15 beds.
• The total number of beds in each wards ranges between 14 to 15 beds.
• One general nurse and one trainee nurse are assigned to each ward.
• A patient can only be either an out-patient or an in-patient.
• An in-patient can have only one activity at a time assigned to them to be performed by the
nurse.
1.2 Business Rules

To complete the SQL solution, there are few business rules needed. This is because an effective
business rules help set expectations and provide guidelines on how work on the database will be
conducted. There are as follows:
1. The scenario states that there are 17 wards in Wellmeadows Hospital which includes an
out-patient clinic and a total of 240 beds. For each ward, a unique number is used to identify
it along with a ward name, the total number of beds, the gender of patients in the ward and
the telephone extension number. Therefore, the first business rule is as follows. Each
WARD has a unique ward ID, ward name, total number of beds, ward gender and extension
number.
2. The scenario also states that every ward has a head nurse as well as a general or trainee
nurse. The activities of the heard nurse are to update the daily activities for the patients
whereas the general nurse can only view these activities assigned and update the status
along with the date and time of the updating. Therefore, the second business rule is as
follows. Each WARD has a single head NURSE and a single trainee NURSE, and each
type of NURSE is only assigned to only one WARD. Moreover, a NURSE can be assigned
many ACTIVITIES, but a single ACTIVITY can only be assigned to a single NURSE.
1|Page
3. The scenario next states that when patients first visit the hospital, they are given a unique
patient ID. Additionally, other details are recorded including the patient’s first name and
last name, address, telephone number, date of birth, gender, marital status, date of
registration with the hospital, the patient’s next of kin’s name, relationship and telephone
number. Therefore, the third business rule is as follows. Each PATIENT has their details
recorded, including their first name, last name, unique patient ID, telephone number, date
of birth, gender, marital status and date of registration. Moreover, each PATIENT’s next
of kin’s first name, last name, relationship and telephone number are also recorded.
4. The scenario then states that when a patient is referred to Wellmeadows Hospital, they are
given an appointment through either their phone or by visiting the hospital for examination.
Each appointment that is given has a unique appointment number and the details of the
patients are recorded by the receptionist. These details include the doctor’s name and staff
number, the date and time of the appointment. Based on the patient’s status, they are then
either referred to the out-patient clinic or given a bed. Therefor the fourth business rule is
as follows. A PATIENT can book one or more APPOINTMENTS. Each PATIENT is
then classified as either an IN-PATIENT or an OUT-PATIENT. If they are assigned as
an IN-PATIENT, they will be admitted to a WARD and given a bed.
5. The scenario then states that the details of out-patients that are recorded include the unique
patient number, the first and last name, address, telephone number, date of birth, gender,
time, date and location of the appointment at the out-patient clinic. Therefore, the next
business rule is as follows. The details of OUT-PATIENTS include the patient number,
first and last name, address, telephone number, date of birth, gender, time, date and location
of the appointment.
6. The scenario proceeds to state that the in-patient’s details that will be recorded include the
unique patient number, the first and last name, address, telephone number, date of birth,
gender, marital status, the next of kin’s details, the ward assigned, the expected duration of
stay, the date when they first began their stay and the date they are expected to leave the
ward along with the actual date that they leave the ward. Therefore, the next business rule
is as follows. Each IN-PATIENT is admitted into a WARD, and each WARD may have
many IN-PATIENTS.
2|Page
7. The scenario states that each doctor that works at Wellmeadows Hospital has their details
recorded. These include the first and last name, unique staff number, the doctor’s
specialties, and their extension number. Therefore, the next business rule is as follows.
Each DOCTOR may have one or more SPECIALTY, and each SPECIALTY may belong
to one or more DOCTORS.
8. Lastly, the scenario states that the appointment schedule is recorded for each doctor and
the schedule includes the date, time, location and patient name. Therefore, the last business
rule is as follows. Each DOCTOR may be assigned to one or more APPOINTMENTS,
and each APPOINTMENT can only be assigned to one DOCTOR.
3|Page
1.3 Logical Design
Full View: https://drive.google.com/file/d/1gQaP5JUQciRs_yH7upSxpsj1BK_BfhCi/view?usp=sharing
4|Page
1.4 Entity Relationship Diagram (ERD)
Full View: https://drive.google.com/file/d/1gQaP5JUQciRs_yH7upSxpsj1BK_BfhCi/view?usp=sharing
5|Page
Activity
Column name Description
Activity_ID Unique ID of the task to be performed by the nurse on an in-patient
Patient_ID Unique ID of the patient who is going to have the task performed for
them
Nurse_ID Unique ID of the nurse to perform the task
Daily_Dosage Amount of medicine to be given to patient daily
Special_Care Any additional special care instructions to be carried out on patients
Complete_DateTime Date and time of completion of task by nurse
Status Status of task, either complete or incomplete
Nurse
Nurse_ID Unique ID of the nurse
Ward_ID Unique ID of the ward the nurse is assigned to
Nurse_Fname Nurse first name
Nurse_Lname Nurse last name
Ward
Ward_ID Unique ID of the ward in the hospital
Ward_name Name of the ward
Total_bed Total number of beds in the ward
Ward_gender Gender of the ward
Extension_number Extension number of the ward
6|Page
In_Patient
Patient_ID Unique ID of patient
Ward_ID Unique ID of the ward that a patient is admitted to
Duration_stay Expected length of stay for a patient in days
Start_Date Start date of stay at hospital
Expected_Leave Expected date a patient is going to leave the hospital
Actual_Leave Actual date a patient leaves the hospital
Patient
Appointment_ID Unique ID of the appointment that a patient is given
Patient_Fname Patent’s first name
Patient_Lname Patient’s last name
Address Patient’s home address
Telephone_number Patient’s telephone number
DOB Patient’s date of birth
Gender Patient’s gender
Marital_Status Patient’s marital status
Date_Registered Patient’s date of registration at the hospital
NextOfKin_Fname Patient’s next of kin’s first name
NextOfKin_Lname Patient’s next of kin’s last name
NextOfKin_Relationship Relationship that next of kin has to the patient
NextOfKin_number Patient’s next of kin’s phone number
7|Page
Out_Patient
Appointment
Appointment_ID Unique ID of appointment
Doctor_ID Unique ID of the doctor who the appointment is assigned to
Appointment_DateTime Date and time of the appointment
Appointment_Location Ward ID at which the appointment is going to be done
Doctor
Column name Column name
Doctor_ID Unique ID of the doctor
Doctor_Fname Doctor’s first name
Doctor_Lname Doctor’s last name
Telephone_Extension Telephone extension number to reach doctor
Doc_Speciality
Doctor_ID Unique ID of the doctor
Speciality_ID Unique ID of the specialty that a doctor may have
Speciality
Speciality_ID Unique ID of the specialty that a doctor may have
Speciality Name of specialty
8|Page
2 Database Auditing Environment

Before the auditing environment is created, the objectives to the database auditing are
defined. This is because by defining the objectives, it allows the auditing environment to be created
based on the objectives thus, meeting the goal of audits and business rules. For this auditing
environment it is important that Wellmeadows hospital database supports audits as well as proper
user control to ensure all the data in the database is not misused dues to most of the information
being sensitive information.
2.1 General Objectives

• To design a create a structured hospital management system for Wellmeadows Hospital.
• To ensure all possible login activities are tracked and limited to ensure the database is login
by the appropriate user at the appropriate hours only. This is to prevent unwarranted access
to the database as it contains highly sensitive information such as the patient’s personal
data and medical record.
• To provide specific employees access to the database with specific login pertaining to their
role in the hospital. The employees are given specific roles and privileges to the database
of which all activities will be tracked and audited.
• To ensure all the data within Wellmeadows hospital database suffice the data integrity
motion through auditing and tracking of the changes made to the database. This ensure all
new and updated data to be accurate, complete, consistent and importantly safe with
compliance to the data regulatory board.
• To ensure all the data is secure to cater to the privacy policy and data handling of the
hospital through multilevel encryption hierarchy.
• To create a backup strategy for the hospital to prevent data loss or to recovery from a
potential unwarranted disaster.
9|Page
2.2 Audited Entities

The second component of the database auditing environment is the audited entities, which
comprises of the various things that are going to be audited. In the case of Wellmeadows Hospital,
the things that are going to be audited include the users, database activity, logon history, database
security and database maintenance.
• In Wellmeadows Hospital, the users include the various employees and staff members that
word there. This means that all nurses, doctors, management members, receptionists, and
administrators. The privileges and roles assigned to each user are documented to keep track
of who has access to and what each person can do. This reduces the chances of data
breaches and leaks occurring, as well as the misuse of information for things such as
identity theft.
• All database activity is going to be logged to keep track of all the different actions
performed on the database. These activities may include updates to tables and data,
insertions and deletions of data. This way, if any action is deemed to be improper, the
auditor can immediately take note of it and take action.
• Logon history to the system is also going to be logged to keep track of the users that log
in, the dates that they log in as well as the times they log in and out. This helps identify
what users spend the most amount of time staying logged in, and if they are not supposed
to be staying logged on, this might be considered a security breach.
• Database security is one of the most important aspects of a database. Thus, security
measures need to be performed to inhibit unauthorized actions to be performed by anyone
both inside and outside of the hospital. Furthermore, unauthorized logins will be prevented
which ensures data confidentiality and validity. The different types of encryptions
performed on the database need to be logged and the auditor must also make sure that the
data being encrypted is sensitive so as to not waste resources.
• Database maintenance refers to the checking for indications of corruption in the data by
monitoring the database to make sure that all of the data inside of it is valid and that noisy
data, such as duplicate rows, null values in the wrong places, wrong attribute values and
incomplete values do not exist in the database. Database maintenance is also attained by
ensuring the database is backed up at all times in case of an emergency. Logs of these back-
up files also need to be kept.
10 | P a g e
2.3 People
The third component of the database auditing environment is the people, which are the
people involved in the auditing process in an organization. These people can include the
administrator, auditor, employees, and managers. In the case of Wellmeadows Hospital, the people
refer to all of the different users involved in the database, which include the receptionist, doctors,
nurses, the hospital management and the database administrator. The receptionist is front man,
making them the person responsible for patient administration. They are able to view, insert and
update details regarding patients into the database as well as assign them appointments with
doctors. Doctors are able to view and update outpatient records. There are 3 types of nurses which
are the general nurse, the head nurse and the trainee nurse. The head nurse can view and update
in-patient details as well as the activities to be carried out for each patient by the other nurses.
Additionally, they can view the doctor, nurse and ward tables and update the nurse tables to assign
different nurses to different wards. The general nurse is able to view the details of the in-patients,
doctor, nurse and ward and the activities assigned to them as well as update the status of these
activities. Lastly, the trainee nurse can view and update the in-patient details, view the ward that
they are assigned to, view the activities assigned to them and update these activities. The hospital
management mainly deals with the staff at the hospital, making them able to add, update and delete
doctors, nurses, wards, appointments, specialties, and activities to be performed by the nurses. The
database administrator provides privileges and creates new users to be added to the database as
new employees. Additionally, they are responsible for assigning these new users the roles based
on the authorization matrices that they have created for each role. This makes them the main person
responsible for the maintenance and control of the entire database. Moreover, they can also revoke
permissions and privileges to ensure the security of the database.
11 | P a g e
2.4 Procedures
Procedures is the second last component of the database auditing environment where a set
of instructions or rules needed to be followed to perform auditing onto a database. Therefore, the
procedures are as follows
• Create accounts for users and provide them with the right privileges based on their roles
• Creating authorization matrices for any new roles added to the hospital management
system
• Creating DML and logon triggers to monitor and control any changes made to the database
• Encrypting sensitive data within the database
• Create backups for the data regularly
Additionally, as a medical institution, Wellmeadows Hospital needs to adhere to various
governmental regulations such as HIPAA and HITECH to ensure data confidentiality.
2.5 Database
The last component of the database auditing environment is the database, which is arguably
the most important component. The database contains all of the data regarding all of the patients
as well as all of the employees working at the hospital and the wards available. The database also
contains the roles and users created with the privileges assigned to them. In order to protect the
database, encryption was used on several tables and backup was also used in case any type of
attack, breach or corruption.
12 | P a g e
3.0 Authorization Matrix

3.1 Richard Wijaya (TP053319)
3.1.1 Head Nurse
Head Nurse Authorization Matrix
In
Privilege Outpatient Patient Appointment Doctor Nurse Ward Specialty Doc_Speciality Activity
Patient
READ Y N N N Y Y Y N N Y
INSERT N N N N N N N N N Y
MODIFY Y N N N N Y N N N Y
DELETE N N N N N N N N N N
GRANT N N N N N N N N N N
The first role established in the Wellmeadows Hospital database is the head nurse role where each ward has a designated head
nurse assigned to it. Generally, the head nurse does not have the authority in GRANT permissions to other users, DELETE records in
any of the tables, and INSERT data into any of the tables as inserting data is the receptionist role except for the activity table where the
head nurse is the one delegating and updating the tasks. Thus, the main permissions granted for the head nurse are SELECT and
UPDATE. The SELECT permission was granted on the “In Patient”, “Doctor”, “Nurse”, “Ward”, and “Activity” tables to read the
information within the tables. In terms of UPDATE permissions, the head nurse can modify the information within the “In Patient”,
“Nurse”, and “Activity” tables. As the head nurse can update the daily activities of the patients like the daily medicine dosage and special
care in the “Activity” table. Additionally, the head nurse can update the “Nurse” and “In Patient” table to update the ward ID in case
they are assigned to the other wards.
13 | P a g e
3.1.2 General Nurse

General Nurse Authorization Matrix
In
Patient
READ Y N N N Y Y Y N N Y
INSERT N N N N N N N N N N
MODIFY N N N N N N N N N Y
The second role defined for the Wellmeadows Hospital database is General Nurse. Similar to the head nurse, the general nurse
is unable to GRANT permissions, INSERT records and DELETE records within the database. Additionally, the general nurse is only
able to perform UPDATE operations only on the Activity table as the general nurse can update the status, date, and time of the activity.
Thus, the operations that the general nurse could perform is the SELECT operation only. For the SELECT operation, the general nurse
can read the “Activity” table as they are allowed to view the tasks that have been delegated to them. The general nurse can view “In
Patient” and “Nurse” tables, as it contains the Ward ID to tell them which ward, they are assigned to. Additionally, the “Doctor” and
“Ward” tables can be viewed as the general nurse need to see the ward name and information as well as the doctor that is in charge of
the patient.
14 | P a g e
3.2 Johnson Wong Ing Cheng (TP047339)

3.2.1 Hospital Management
Hospital Management Authorization Matrix
In Out
Privilege Patient Appointment Doctor Nurse Ward Specialty Doc_Specialty Activity
Patient Patient
SELECT Y Y Y Y Y Y Y Y Y Y
INSERT N N N N Y Y Y Y Y Y
UPDATE N N N N Y Y Y Y Y Y
The first role created is the hospital management which ranges from departments such as the human resource to the CEO of
Wellmeadows hospital. This role differs from the administrator role as the administrator will be the person that handles the database and
the management despite having most abilities, still has limited ability in terms of control of the entities. Therefore, in most of the entities,
the management has the ability to SELECT, INSERT, and UPDATE whereas in certain entities such as the “Appointment”, “In_Patient”,
“Out_Patient”, and “Patient” the management could only SELECT as the management would not directly interact with the patients thus,
there is not a need to have different privileges. Next, as the receptionist will handle all the appointments, the management would only
need to look at the details and not change any appointments.
15 | P a g e
3.2.2 Doctor
Doctor Authorization Matrix
In Out
Privilege Patient Appointment Doctor Nurse Ward Specialty Doc_Specialty Activity
Patient Patient
SELECT Y Y Y Y Y Y Y N N N
UPDATE N Y N N N N N N N N
The second role are the doctors of the hospital. Of all the entities that is granted to the doctors, most of the privileges are SELECT.
This is because the doctors do not need to update anything and only information regarding the outpatients as once, they are being
consulted, the patients would then leave the hospital and such they are given the privilege to UPDATE the details of the outpatients.
Next, the doctor is not given the privilege to UPDATE their detail as to update any details, since it is sensitive information only the
hospital management is able to update their personal details.
16 | P a g e
3.3 Muzamil Mohammed Ahmed Abdulatief (TP048867)

3.3.1 Trainee Nurse
Trainee Nurse Authorization Matrix
In
Patient
READ Y N N N N N Y N N Y
MODIFY Y N N N N N N N N Y
The first role created is the trainee nurse role. As mentioned in the business rules, the trainee nurses only have the ability to
check the activities assigned to them by the head nurse and update them as well as the date and time of updating. Therefore, they are
given the SELECT and MODIFY privileges on the In_Patient and the Activity tables. Next, since trainee nurses are assigned to only
one ward, they need to be able to see which ward they are assigned to. Therefore, they are given the SELECT privilege for the Ward
table.
17 | P a g e
3.3.2 Receptionist
Receptionist Authorization Matrix
In
Patient
READ Y Y Y Y N N N N N N
INSERT Y Y Y Y N N N N N N
MODIFY Y Y Y Y N N N N N N
Since the receptionist is the first person that a potential patient is going to see when they enter the hospital, they need to be able
to enter in patients’ details. Therefore, they are given the SELECT, INSERT and MODIFY privileges on the In_Patient, Out_Patient
and Patient tables. Next, they also need to be able to set appointments for the patients and so they are also given SELECT, INSERT and
MODIFY privileges on the Appointment table. Next, no patients are going to be deleted from the database in order to keep all of the
historical data in the database. Therefore, the DELETE privilege is not given even if patients have already left the hospital after their
stay.
18 | P a g e
4 Individual Users
Figure 1: Login creation, User creation, Role creation, and Role assigning
The code snippet above shows the creation of two logins for the database under the login
name ‘John’ and ‘Yaya’ with the password shown in the figure above. Next, both logins are added
as a user within the Wellmeadows database under the username ‘JohnGNurse’ and
‘Yaya_HeadNurse’. Next, the head nurse and general nurse roles mentioned in the authorization
matrix in section 3.1 is created within the Wellmeadows database. Finally, add the users to their
respective roles created in the Wellmeadows database is performed.
19 | P a g e
Figure 2: Granting privileges to roles
The figure above shows the privileges delegated to the head nurse and general nurse role
in the Wellmeadows Hospital database. The SELECT privilege on five tables within the database
which are “In_Patient”, “Nurse”, “Doctor”, “Ward”, and “Activity” tables are given to both head
and general nurse roles. In terms of UPDATE privilege, only the head nurse role is granted the
UPDATE permission for the ‘In_Patient’, ‘Nurse’, and ‘Activity’ tables. Additionally, the
INSERT privilege is only granted to the head nurse on the ‘Activity’ table as the head nurse is the
one who delegates and updates the activities of the nurses within the Weallmeadows Hospital.
20 | P a g e
Figure 3: Admin and Doctor Login Creation, User Creation, and Role Creation and Assignment
The code snippet above shows the creation of two users under the two roles specified in
section 3.2, hospital management and doctor. The first user is the hospital management whereby
the login name for the user is “bobo” with “admin123” as the login password. In the database, the
hospital management name will be indicated as “bobo4949” and is given the “Administrator” role.
The second user that is created is the doctor of Wellmeadows hospital, of which the login
name given to the user to login into the server is “alex” with “wmdoc!” as the login password.
Their role in the database will be indicated as “Doctor” with the “alex5959” as the database name
that is used for any user tracking.
21 | P a g e
Figure 4: Privilege Granting for Hospital Management
Figure 4 shows the privilege that is granted to the Administrator role. In total six entities,
“Doctor”, “Nurse”, “Speciality”, “Ward”, “Doc_Speciality”, and “Activity” is given the privilege
to SELECT, INSERT, and UPDATE data to the management of the hospital. Besides, four other
entities are given the SELECT only privilege to the management which includes the
“Appointment”, “In_Patient”, “Patient”, and “Out_Patient” entities.
22 | P a g e
Figure 5: Privilege Granting for Doctor
The figure above shows the grant privilege for the Doctor. In total 7 entities are granted
with the SELECT privilege with only the “Out_Patient” has an extra privilege whereby they are
allowed to UPDATE the details of the outpatient. These privileges are given to the entire role
instead of the user only in both, Administrator and Doctor role. This is done so that any other users
added to that position will immediately inherit these rights.
23 | P a g e
Figure 6: Trainee Nurse User Creation & Role Assigning
Figure 7: Receptionist User Creation & Role Assigning
The two code snippets above show the creation of two users under the roles specified in
the previous authorization matrices. The first user is the trainee nurse, which is given the login
name “Ayaya” and the password “coolnurse”. Their name in the database is going to be
“Ayaya123”. Once the role has been created, the user is added to that role using the database name.
Next, the SELECT and UPDATE privileges are given to them for the In_Patient table and the
24 | P a g e
SELECT privilege is given to them for the Ward table. These privileges are given to the entire role
instead of the user only. This is so that if any more users are added to that role, they automatically
inherit these privileges.
The second user that is created is the receptionist, which is given the login name “Emir”
and the password “ihatemyjob” and the database name “Emir123”. They are then assigned to the
receptionist role using the database name. They are then given the SELECT, INSERT and
UPDATE privileges for the Appointment, Patient, In_Patient and Out_Patient tables. Once again,
these privileges are given to the role instead of just the user so that any newly added users can also
inherit these privileges automatically.
25 | P a g e
5 Logon Trigger
The logon trigger applied onto the database is used to limit the multiple concurrent
connections of a single user within the database. The logon trigger is applied to the user “yaya”
and the specified user will not be able to run more than seven active user sessions within the
database. In a case where there are more than seven active user sessions, an error message will be
prompted to the user indicating that the specified user has more than seven active sessions running
within the database.
Figure 8: Logon trigger for Limiting active user sessions
The code snippet above is used to apply the logon trigger to limit the active user session to
no more than seven sessions within the database. The logon trigger will detect the login name
under the name of “yaya” and checking of the active user session is done every time the user
logged in. If the active session is more than seven. An error message indicating the user cannot log
in as the specified user has more than seven active user sessions within the database.
26 | P a g e
Figure 9:The session count per session and error message recorded in the SQL log
As seen in the figures above, the total session count of the user “yaya” is seven. Thus, the
error message appears the next time user ‘yaya’ tries to initiate a new session or query in the
database.
27 | P a g e

The logon trigger that was selected to be executed is a logon trigger that is used to track
the login activity of each user. This logon trigger is applied to both the hospital management and
doctor. Additionally, a table is separately created to keep track of the login activity whereby the
user’s name, database username, Server Process ID (SPID) and importantly the date and time of
the login. This table is created using the code snippet below.
Figure 10. ServerLogonHistory Entity Creation
Figure 11: Logon Trigger Creation to Track User Login Activity
Figure above shows the code snippet to create the logon trigger. Firstly, a new table,
“ServerLogonHistory” is created with the purpose to store the login details of the user such as the
server username login, database username login, SPID, and login time and date. SPID are
essentially sessions in SQL Server. Every time an application connects to SQL Server, a new
connection (or SPID) is created. This connection has a defined scope and memory space and cannot
interact with other SPIDs hence the output shown in the following figure. Once the logon trigger
is created, the server control is granted to both the users as it is required to insert the login data
into the created table.
28 | P a g e
Figure 12: ServerLogonHistory User Login Tracking Output
As can be seen in the figure above, both the “bobo” and “alex” user is logged into the table.
Due the SPID being unique and could not interact with other SPIDs, there will have multiple logs
each time a user login as during logon process, SQL goes through different processes.
29 | P a g e

The logon trigger that was selected to be executed is the logon trigger that is used to allow
the user to connect to the SQL server within specific hours. This logon trigger is applied to the
receptionist. The logon trigger will only allow them to log in to the server within their operating
hours, which is between 6 am and 6 pm. If they try to log in to the server outside of these office
hours, an error message is generated telling them that as a receptionist, they are not allowed to log
in to the system before 6 am and after 6 pm. Additionally, a table is separately created to keep
track of the date and time they try to log in outside of office hours. This table is created using the
code snippet below.
Figure 13: Table Used to Track Log Ins Outside Office Hours
Figure 14: Logon Trigger for Receptionist
Next, the code snippet above is used to create the logon trigger. The logon trigger detects
the login name used, which is going to be “Emir” since that is the only receptionist currently. Next,
the working hours for the receptionist are specified and if a logon is detected outside of these hours,
an error message saying “Receptionist is not authorised to login after office hours” is triggered and
the date and time of the attempted log in are stored in a separate table. An example of this can be
seen below.
30 | P a g e
Figure 15: Error message generated from Logon Trigger
Figure 16: Record added into table when Receptionist tries to login after office hours
As can be seen from the two figures above, the message is generated as the receptionist
tries to login at 10 pm on the 27th of October 2021, and therefore, this data is recorded into the
newly created table which acts as an audit for the receptionist as well.
31 | P a g e
6 Data Manipulation Language (DML) Trigger

6.1.1 Track changes in the Nurse table
The first DML trigger applied to the database is to track the changes made in the Nurse table.
Figure 17: Create Nurse Audit table
To record the changes made in the Nurse table, a different table called “NurseAudit” is
created to contain the same columns in the Nurse table including an additional three columns which
indicate which user modified the data, the time that the data has been manipulated, and the type of
the change being made to the data which is either insert, delete, or update. The main reason the
nurse table is tracked is to see the changes when the different ward has been appointed to the
nurses.
32 | P a g e
Figure 18: Nurse table DML Trigger
The code snippet above shows how the DML trigger for the nurse table is constructed.
Firstly, the Nurse table is specified to ensure that the auditing occurs in the nurse table. Next, the
after trigger is assigned on the INSERT, UPDATE, and DELETE operations performed on the
Nurse table. Next, the special tables used in the triggers are the “inserted” and “deleted” tables
which are only available within the trigger (Microsoft, 2021). When an INSERT operation is
performed on the Nurse table, the new data inserted into the table will be temporarily available in
the “inserted” table and inserted into the Nurse table as well. When the UPDATE operation is
performed on the Nurse table, the old data will be removed from the original table and inserted
into the “deleted” table. Then, the new data will be inserted into the Nurse table and the “inserted”
table. Thus, an IF function is utilized to ensure that both data is present in both the “inserted” and
“deleted” table. In the case where both data are present on both special tables, this indicates that
the UPDATE operation is performed on the Nurse table. The old data from the “deleted” table will
be added into the “NurseAudit” table with the label ‘before update’ and the new data from the
“inserted” and the table will be added into the “NurseAudit” as well with the label ‘after update’.
However, if the data is present on either of the special tables, this indicates that either an INSERT
or DELETE operation is performed on the table where the new data inserted will be added to the
33 | P a g e
“NurseAudit” table and labelled ‘Insert’ or the deleted data will be added from the “deleted” table
to the “NurseAudit” table and labelled ‘delete’.
Apart from the data from the Nurse table added into the “NurseAudit table”, the user that
performs the operation will be recorded using the “SYSTEM_USER” function, as well as the date
and time of the execution of the operation, will be added as well using the “getdate()” function. As
mentioned previously, the last data added into the table is the type of operation made. Thus, the
following are the testing made to ensure that the trigger audit Nurse DML trigger is working.
Figure 19:Update operation Nurse table DML trigger
The first operation tested was the update operation where the last name of the nurse with
ID ‘G0001’ is updated.
Figure 20: After update operation NurseAudit table
The figure above shows the ‘NurseAudit’ table where the previous data and updated data
was recorded in the table.
Figure 21:Insert operation Nurse table DML trigger
The second operation tested was the insert operation where a new nurse is inserted into the
Nurse table with a new nurse ID, ward ID, first name, and last name.
Figure 22:After insert operation NurseAudit operation
The figure above shows the ‘NurseAudit’ table after the details in figure xx is inserted into
the Nurse table. As seen in the figure above that the new details are recorded inside the
‘NurseAudit’ table.
34 | P a g e
Figure 23:Delete operation Nurse table DML trigger
The last operation tested was the delete operation where the nurse details were deleted from
the Nurse table with the Nurse ID of ‘G0018’
Figure 24: After DELETE operation NurseAudit operation
As seen in the figure above that the deleted details of the Nurse were recorded in the
‘NurseAudit’ table.
6.1.2 DML trigger to check Actual Leave date
Figure 25:DML Trigger to check insert and update of Actual Leave date in “In_Patient” table
The second DML trigger made is to check the “Actual_Leave” column in the “In_Patient”
column. The trigger is used to check the data inserted or updated in the actual leave date column
whether the date inserted is valid or not. The condition will check whether the inputted data is less
than the admission date. In the case where the input actual leave date is less than the admission
date, an error will be shown to the user indicating that the date the user inputted is wrong.
Afterwards, ‘rollback’ is used to revert/undo the action performed by the user.
35 | P a g e
Figure 26:
An example of the DML trigger is shown above where the actual leave is updated from
NULL to ‘2021-10-19’ for the patient with the ID of ‘P0001’. Since the actual leave date updated
is before the admission date, an error will be raised by the SQL indicating that the actual leave
data inputted by the user is before the admission date. A sample of the error is seen in the figure
below.
Figure 27: Error message DML trigger
36 | P a g e

6.2.1 DML Trigger to Track Changes/Audit in Ward Entity
Figure 28: WardAudit Entity Creation
The figure above shows the creation of the DML trigger to track the changes in the Ward
table. Firstly, a new table, “WardAudit” is created whereby the number of columns and datatype
of the table is similar to the Ward table with the addition of three extra columns, “Operation”,
“Executed_By”, and “Date_Modified”. The “Operation” column is used to track the type of
operation that is done to the Ward table. Next, the “Executed_By” column is used to track the user
that made any changes to the Ward table and the “Date_Modified” column will track the exact
time and date of when all the changes are made.
Figure 29: DML Trigger to Monitor INSERT, UPDATE, and DELETE in Ward Entity
Once the “WardAudit” table is created, then the DML trigger will be created. To start, the
Ward table was defined to guarantee that event monitoring was done for this table. Next, because
the data changes that will be monitored include insertions, updates, and deletions, two special
tables that are only available to triggers will be used: the inserted table and the deleted table. When
37 | P a g e
the INSERT command is executed on a table, new rows are added to both the original table being
updated and a separate table known as the inserted table (Microsoft, 2021). When the UPDATE
and DELETE functions are invoked on a table, the row is first deleted from the original table,
activating the delete table, and then the new row with the modified data is inserted into the table,
activating the inserted table once more, whereas the rows are deleted from the trigger table and
transferred to the deleted table for the UPDATE instance (Microsoft, 2021).
As a result, the data in these two special tables, inserted and deleted tables, is initially
examined. If data is present in both of these tables at the same time, it indicates that a UPDATE is
being performed on the Ward database. As a result, the previous row from the trigger table is
obtained from the deleted table and put into the WardAudit table with the operation set to
"UPDATE DELETE," and the new data is retrieved from the inserted table is added to the
WardAudit table with the action set to "UPDATE INSERT."
For both of these entries, the SYSTEM USER function is used to obtain the user's login
name to fill in the "Executed_By" column, and the GETDATE() function is used to retrieve the
date and time of the update to fill in the "Date_Modified" column. If the deleted table has no data,
the user is attempting to insert new data into the table. As a result, the new data is only received
from the inserted table with the action set to "INSERT" in the WardAudit table. Similar to the
DELETE operation of the trigger, if there is no data in inserted table, it indicates that the user is
trying to delete data from the trigger table, Ward. Therefore, the new data is retrieved only from
the trigger table and the operation set to “DELETE” in WardAudit. Some dummy data was used
to test the functionality of this DML trigger as seen in the following figure.
Figure 30: Query to Test DML Trigger INSERT
The figure above shows the testing of all the functions, INSERT, UPDATE, and DELETE
of the DML trigger created. For the insertion testing, a new ward is added with a new ward
identification number, ward name, the total number of beds in the ward, the ward gender, and the
extension number of the ward. Next, to test the update
38 | P a g e
Figure 31: WardAudit INSERT Functionality Test Output
Figure 32: Query to Test DML Trigger UPDATE
Once the new ward data is inserted, and UPDATE is done to the data to change the gender
type of the ward.
Figure 33: WardAudit UPDATE Functionality Test Output
As seen in the WardAudit table, when a record is updated, there are 2 records as whereby
it shows the past record and the updated record indicated by the “Operation” column. The past
record is indicated with the “UPDATE DELETE” whereas the new record is indicated with the
“UPDATE INSERT” operation.
Figure 34: WardAudit DELETE Functionality Test Output
Lastly, the DELETE functionality is tested whereby a newly added ward data is deleted.
The above code snippet will use pattern matching to match the ward identification number to the
query.
Figure 35: WardAudit DELETE Functionality Test Output
From figure 35, it can be seen that the ward with ward identification number “W0019” is
deleted as indicated with the “DELETE” operation.
39 | P a g e
6.2.1 DML Trigger to Check the Number of Beds for Each Ward
Due to each ward is limited to only 14 to 15 beds as per the business rule, the trigger is
used to check to ensure all the new data inserted into Ward table meets the constraint. This is
because with too much bed in a single ward, it causes unnecessary congestion where it might cause
patients to be uncomfortable and with too little beds, Wellmeadows is wasting valuable space
where more patients can be treated. The creation of the DML trigger is as shown in the code snippet
below.
Figure 36: DML Trigger to Monitor Total Number of Beds in New Input to Ward Entity
The code snippet above shows how the trigger is created. As can be seen, the moment an
INSERT statement is detected for the Ward table. Once this happens, the query will check the total
number of beds from the inserted table to ensure it is within the boundary of 14 to 15 beds. If the
condition is not met, an error message will be shown to the user. As there may have been changes
to the Ward table, a ROLLBACK is called to discard any changes made to the Ward table since
the last “BEGIN”. This trigger again needs to be tested and this is done using the code snippet
below.
Figure 37: Query to Test FALSE Constraint of DML Trigger
Figure 38: Error Message for FALSE Constraint Output
40 | P a g e
Figure 37 shows the code snippet where a sample ward data is added whereby the total
number of beds are set to 13. Due to the total number of beds is less than the allowed amount, and
error message will be prompted to the user as seen in the output in figure 38.
Figure 39: Query to Test TRUE Constraint of DML Trigger
Figure 40: Ward Entity Output
In another test, the number of beds is updated to the acceptable amount of 15 where in this
case, not error message in prompted and the data is successfully added into the Ward table. This
can be seen with the data in the Ward table as highlighted in figure 40.
41 | P a g e

6.3.1 Track Changes Made to Patient Table
The first DML trigger that was created was one that is used to track any changes made to
the Patient table by the receptionist. In order to do this, a separate table was created. This new table
contains all the same columns as the ones in the Patient table with an extra 3 columns, which are
“operation”, “executed_by” and “date_modified”. The “operation” column is going to track if the
change made is an insert or an update, the “executed_by” is going to track which user exactly made
the change and the “date_modified” column is going to track the exact date and time that the
modification occurred. This table is called the PatientAudit and this is done using the code snippet
below.
Figure 41: New Audit Table to Track Changes Made to the Patient Table
42 | P a g e
Figure 42: DML trigger to track changes
The code snippet above shows how the DML trigger was created. Firstly, the Patient table
was specified to ensure that the tracking of events was made for this table. Next, since the data
changes that are going to be tracked are insertions and updates to the data, two special tables that
are only accessible to triggers are going to be used which are the inserted table and the deleted
table. Whenever INSERT is triggered on a table, new rows are added into both the original table
that is being modified as well as a special table known as the inserted table (Microsoft, 2021).
Whenever UPDATE is triggered on a table, the row is first deleted from the original table, which
activates the delete table, and then the new row with the modified data is inserted into the table,
which activates the inserted table once again (Microsoft, 2021). Therefore, these two special tables
are first checked for data existing in them. If data exists in both these tables at the same time, then
it means that an UPDATE is being carried out on the Patient table. Therefore, the previous row
that was originally in the table is retrieved from the deleted table and inserted into the PatientAudit
table with the operation set to “Before Update” and the new data that is being inserted into the
table is retrieved from the inserted table and added into the PatientAudit table with the operation
set to “Update”. For both of these entries the user’s login name is retrieved using the
SYSTEM_USER function in order to fill in the “executed_by” column and the date and time of
the modification is retrieved using the GETDATE() function to fill in the “date_modified” column.
If there is no data in both the inserted and deleted tables, the user is trying to insert new data into
the table. Therefore, the new data is retrieved only from the inserted table with the operation set to
“Insert”. Some dummy data was used to test the functionality of this DML trigger.
43 | P a g e
Figure 43: Inserting data into Appointment and Patient tables
Since the Patient table has a foreign key from the Appointment table, and since each
appointment is unique to each patient, a new appointment is first created for the new patient. Next,
a new patient is added into the Patient table. Since this is a new row being added into the Patient
table, this should automatically trigger the DML trigger that was created, which is going to insert
this new row into the PatientAudit table.
Figure 44: PatientAudit table with new row
As can be seen from the figure above, the new row has been added into the PatientAudit
table with the operation as “Insert”, indicating that this data is new and has been newly inserted
into the Patient table. The user that did this operation was also the receptionist, which ensures that
the privileges were handed out successfully and correctly.
Figure 45: Updating data in Patient table
The second test that is done is to update data that is already in the table to ensure that it is
being audited. The code snippet above shows that the data being updated is the first name of the
patient whose ID is set to P0025, with the name changing from Richard to Muzamil.
Figure 46: PatientAudit with updated data
As can be seen above, two new entries have been added to the PatientAudit table. The first
is the old data being deleted from the Patient table, which can be seen with the “Before Update”
44 | P a g e
operation. Next, the new data with the modified first name is there inserted into the table, which
can be seen with the operation “Update”.
6.3.2 Avoiding Deletion of Patient Using Instead of Trigger

The next DML trigger that was created is an Instead Of trigger, which is used to avert the
execution of INSERT, UPDATE or DELETE statements, and instead runs other statements
specified within the trigger (Oracle, 2021). Therefore, this trigger is fired before the execution of
a DML command. This trigger is going to be used to prevent the receptionist from deleting patients
from the database. This is because it is important to keep records of previous patients which can
be used as either references or to keep track of this patient in case they return to the hospital.
Figure 47: Instead Of trigger used to prevent patient data deletion
The code snippet above shows how the trigger is created. As can be seen, the moment a
DELETE statement is detected for the In_Patient table. Once this happens, an error message is
generated saying “Patient can’t be deleted. Patient changed to discharged”. This way, instead of
deleting patients since the cause for that may have been because they have left the hospital, they
are instead changed to discharged by changing their actual leave date to today. This is done by
updating the In_Patient table and inner joining the In_Patient table and the virtual deleted table
based on the Patient_ID. This trigger again needs to be tested and this is done using the code
snippet below.
Figure 48: Deleting patient to test instead of trigger
45 | P a g e
As can be seen from the figure above, there is an attempt to delete patient P0001 from the
In_Patient table. Once this is ran, a message is output which says that patients cannot be deleted
and instead they are set to discharged, as can be seen from the output below.
Figure 49: Instead of trigger message output
In order to test if the actual leave date has been changed, the following code is executed and the
output is shown below.
Figure 50: Making sure actual date changed to today
The figure above shows that instead of patient P0001 being deleted, their actual date has
instead been changed to today’s date.
46 | P a g e
7 Encryption
Encryption is a complex process of encoding data in such a way that it can only be
deciphered by a special key (Puranik, 2020) . With scrambled character layers surrounding the
legitimate information, this prevents unauthorized access and ensures the security of sensitive
information. Businesses and government institutions that employ mobile devices to access data "at
rest" face an increasing risk of losing or stealing this data should the devices be lost or stolen; this
can also be problematic for databases managed by these systems. Stanford University estimates
that medical data grows by 48% yearly (Stanford Medicine, 2017). The exchange of information
about patients, their health status and insurance providers that happens in a hospital or doctor's
office falls under this category. Security levels need to be high for patients with such sensitive
information. In order to protect these kinds of electronic health records that are maintained by
entities, HIPAA Security Rule was enacted (Bednar, 2019). Among these entities are covered
health care providers, health plans, health care clearinghouses, and sponsors of Medicare
prescription drug cards. An example of not adhering to this regulation can be seen in the Cancer
Care Group in 2012, whereby it is estimated that 55,000 patients' names, social security numbers,
and insurance information were stolen from a laptop (Specops, 2019). The organization was liable
for $750,000 in damages as a result of this breach. Another act that was created is the Health
Information Technology for Economic and Clinical Health (HITECH), which expands on the
HIPAA encryption fulfilment standards by necessitating the public disclosure of non-encrypted
personal health information breaches (Thales, 2021). Due to this, it is crucial to be able to protect
the information of patients and employees by using encryption at Wellmeadows Hospital.
47 | P a g e

SQL Server uses layered encryption and key management system to encrypt the data. Each
layer utilizes a combination of certificates, asymmetric keys, and symmetric keys to encrypt the
layer underneath it. An Extensible Key Management (EKM) module can hold asymmetric and
symmetric keys outside of SQL Server (Microsoft, 2021).
Figure 51: Encryption Hierarchy (Microsoft, 2021)
The encryption hierarchy shown in the figure above will be utilized in the data. 4-level
encryption is used to secure the data by using the service master key → database master key →
certificate → symmetric key → encrypted data. The four-layered encryption is implemented as it
will prevent possible data breaches as layers of encryption need to be breached before gaining
information on the data.
The first layer is the service master key as it acts as the root of the SQL Server encryption
hierarchy as an SMK will be automatically created since SQL instance is launched and is used to
encrypt the database master key, credentials, and linked server password (Microsoft, SQL Server
and Database Encryption Keys (Database Engine), 2021). The second layer which is the database
48 | P a g e
master key is a symmetric key that is utilized to protect the asymmetric key and certificates
established within the database. The third layer is the public key certificate or known as a
certificate is a digitally signed declaration that ties the value of a public key to the identity of the
person, device, or service that owns the private key. A certifying authority is the one that issues
and signs certificates (Microsoft, 2021). The fourth and last layer used is the symmetric key which
is a single key that may be used to encrypt and decrypt data. The use of the symmetric key for
encryption and decryption is quick and suited for everyday usage with sensitive database data
(Microsoft, 2021).
Figure 52:Creation of Database Master Key, Certificate, and Symmetric Key
The code snippet above shows the creation of the database master key, certificate, and
symmetric key. The service master key is not created as it is automatically created as the SQL
instance was launched. Next, the database master key is created with the password ‘DMK123’,
and a certificate named “WMCert” is established as well under the subject of
“Wellmeadow_Certificate”. Lastly, the symmetric key named ‘WM_Symkey’ is created using the
encryption of the certificate “WMCert” with the algorithm of advanced encryption standard of 256
bits (AES_256). According to Microsoft (2021), the SQL server 2016 and later will deprecate all
algorithms except the AES algorithms which are AES_128, AES_192, and AES_256. Thus, the
49 | P a g e
usage of the AES_256 which has the most bit keys are utilized as it is more secure making the
encrypted data more complex and harder to breach into. Afterwards, the symmetric key is opened
to enable encryption of the appointment table which is shown in figure xx below.
Figure 53:Adding Encryption columns into the Appointment table and Encryption of the data
The code snippet above shows the adding of encryption columns within the appointment
table by using the ALTER operation. A total of four columns is added with “varbinary” data type
as it will contain the encrypted data. Next, the four columns that are encrypted are the
“Appointment ID”, “Doctor ID”, “Patient ID”, and “Ward ID”. By using the UPDATE operation,
the four columns that are added are updated to fill in the encrypted data using the ‘WM_Symkey’
that is defined in figure xx previously. After the encryption of the data has been performed, the
‘WM_Sykey’ symmetric key used to encrypt the data is closed to prevent a possible data breach.
50 | P a g e
Figure 54: Encrypted data in Appointment table
As mentioned previously, the columns that are encrypted are the “Appointment ID”,
“Doctor ID”, “Patient ID”, and “Ward ID”. Thus, the figure above shows the four encrypted
columns which are ‘En_AppointID’, ‘En_DoctorID’, ‘En_PatientID’, and ‘En_WardID’.
Figure 55: Decrypting the encrypted data
After the encryption of the data is performed, the figure above shows the decryption of the
appointment column data. Firstly, the ‘WMSymkey’ symmetric key used to decrypt the data is
opened using the ‘WMCert’ certificate to decrypt. Next, the ‘DECRYPTBYKEY’ function is used
to decrypt the four encrypted columns within the appointment table. Then, the symmetric key used
is closed to prevent data breaches.
51 | P a g e
Figure 56: Decrypted appointment table data
The figure above shows that the encrypted data in the appointment table have been
successfully decrypted using the query in figure xx.
52 | P a g e

SQL Server uses a hierarchical encryption and key management system to encrypt data.
Each layer encrypts the one underneath it with a mix of certificates, asymmetric keys, and
symmetric keys.
Figure 57: 4-Level Encryption Hierarchy
Source: https://www.sqlservercentral.com/articles/using-database-master-keys-in-sql-server
The figure above shows the encryption hierarchy that will be applied to the data. In total,
the encryption utilizes a 4-level encryption whereby according to the figure above the path of
encryption is: Service Master Key (SMK) → Database Master Key (DMK) → Asymmetric Keys
→ Symmetric Key → Data. This is because with a 4-level encryption the encryption is more secure
as for a potential data breach, it will need to go through 4 levels of encryption before retrieving
the data.
The SQL Server encryption hierarchy is led by the Service Master Key. The SMK is
produced automatically when the SQL Server instance is launched and is used to encrypt a
connected server password, credentials, and the database master key in each database (Microsoft,
53 | P a g e
SQL Server and Database Encryption Keys (Database Engine), 2021). The SMK is encrypted
using the Windows Data Protection API and the local machine key (DPAPI). The DPAPI employs
a key obtained from the SQL Server service account's Windows credentials and the computer's
credentials. Only the service account that generated it or a principal with access to the machine's
credentials may decrypt the service master key (Microsoft, SQL Server and Database Encryption
Keys (Database Engine), 2021).
Next, the database master key is a symmetric key that is used to safeguard the database's
private keys for certificates and asymmetric keys (Microsoft, SQL Server and Database Encryption
Keys (Database Engine), 2021). It may also be used to encrypt data, although due to length
constraints, it is less practical for data encryption than using a symmetric key. To allow automated
decryption of the database master key, the SMK is used to encrypt a duplicate of the key. It is
saved in the database where it is utilized as well as the master system database (Microsoft, SQL
Server and Database Encryption Keys (Database Engine), 2021).
In the encryption in total two different keys are used: asymmetric and symmetric keys. For
safeguarding symmetric keys, asymmetric keys are utilized. This is because asymmetric
encryption is relatively new compared to symmetric encryption approach. They can also be used
to encrypt limited amounts of data and to digitally sign database items. An asymmetric key is made
up of a private key and a public key that corresponds to it (Microsoft, SQL Server Certificates and
Asymmetric Keys, 2021). A symmetric key is a type of encryption technique for encrypting data.
According to Carter (2019), it is the weakest kind of encryption since it uses the same mechanism
to encrypt and decode data. Hence, to make it more secure, the asymmetric key is used to encrypt
the symmetric key.
54 | P a g e
Figure 58: DMK, Assymetric Key, and Symmetric Key Creation
The code snippet above shows the creation of the DMK, asymmetric key, and symmetric
key. Due to the SMK is automatically created, there is no query needed to create the SMK. Next,
the DMK is created with the password “wmjohn@999” assigned to it. The asymmetric key,
ASymKey is then created with password “wmjohnencrypt@999” assigned to it as well as the
algorithm used for the encryption is RSA_2048. According to Jeff (2014), RSA_2048 for now
despite RSA_4096 being newer. Security experts are projecting that 2048 bits will be sufficient
for commercial use until around the year 2030. Besides, the main downside to using a large cert,
such as 3072 or 4096, is that the algorithm is slightly slower due to the extra time needed for
handshaking hence taking up more resources (Jeff, 2014). Next, the symmetric key, SymKey is
created whereby it is encrypted by the asymmetric key. The algorithm used in the symmetric key
is AES_256. The AES technique has now been adopted as the industry standard for encrypting
data at rest. It is also used in many Internet protocols that combine asymmetric and symmetric key
operations (Townsend Security, 2017). As with SQL 2016, the AES algorithms available are
AES_128, AES_196, and AES_256. In this instance of symmetric key, AES_256 is chosen due to
being more secure as it is a more complex as it uses 14 rounds instead of 12 rounds of AES_196.
However, AES_256 uses 40% more resources but since Wellmeadows Hospital does not have
constant stream of high data flow, the tradeoff between security and speed is worth the more
computational resources as all the data in the database is highly sensitive (N-able, 2019).
55 | P a g e
Figure 59: Doctor Entity Coulmn Alteration and Encryption Query
To begin the encryption process, firstly three new columns is added to the Doctor table,
“Encrypt_Doctor_ID”, “Encrypt_Doctor_Fname”, and “Encrypt_Doctor_Lname”. These three
particular columns are chosen to encrypt due to the sensitivity of the information as it is personal
information and the doctor identification numbers, it is highly sensitive and thus, being encrypted.
Once the columns, are added, the symmetric key, SymKey is opened with the assigned password.
This is because if the symmetric is not opened, the encryption process could not be completed.
Next, the newly added column is then filled with scripted data from the existing column whereby
the “Encrypt_Doctor_ID” will contain data of encrypted Doctor_ID, “Encrypt_Doctor_Fname”
with Doctor_Fname, and “Encrypt_Doctor_Fname” with Doctor_Lname.
Figure 60: Doctor Entity Encryption Output
56 | P a g e
The figure above shows the Doctor table with the newly added columns along with the
encrypted data from the symmetric key.
Figure 61: Decryption Test Query
Figure 61 shows the decryption of the encrypted data using SymKey. The goal of this query
is to demonstrate the decryption of the encrypted data as seen in figure 60.
Figure 62: Doctor Entity Decryption Output
The figure above is the output from the query in figure 61. As it can be seen, the encrypted
data is successfully decrypted with the SymKey.
Figure 63: New Data Encryption Test Query
57 | P a g e
The query in figure 63 shows an example whereby two rows of data is added to the Doctor
table. The data consists of both normal and encrypted data. This is done mainly to show the
difference between normal and encrypted data. The figure below shows the record when it is
successfully inserted into the Doctor table.
Figure 64: Doctor Entity New Data Output
Figure 65: Symmetric Key Closing Query
Once the encryption and decryption are completed, the symmetric key is close so that when
other users access the database, they need the password for the encryption key. This acts as a safety
barrier to potential leak as without closing the key, the encryption level is reduced by a level.
58 | P a g e

SQL sever provides many ways to encrypt data. It does this by encrypting data in a hierarchical
infrastructure, with each layer encrypting the layer below through a mixture of certificates,
symmetric and asymmetric keys (Carter, 2019).
Figure 66: Encryption hierarchy (Jones, 2017)
The figure above shows the hierarchy levels that SQL server provides for encryption with
the arrows representing the path taken for this assignment. As can be seen above, the path taken is
Service Master Key (SMK) → Database Master Key (DMK) → Certificate → Symmetric Key →
Symmetric Key → Data. The reasoning behind this is because this is 5 levels of encryption
hierarchy being applied, making it more secure. The SMK is at the top of the SQL Server
encryption hierarchy. When the instance is built, the SMK is established automatically and is used
to encrypt database master keys, credentials, and connected server passwords (Carter, 2019). The
DMK is a symmetric key that is used to safeguard the database's private keys for certificates and
asymmetric keys (Microsoft, 2021). Certificates are asymmetrical keys that bind a public key to a
principal or device that holds a corresponding private key by means of digitally signed statements
59 | P a g e
(Microsoft, 2021). A symmetric key is a type of encryption algorithm that can be used to encrypt
data. Because it employs the same technique to encrypt and decrypt data, it is the weakest form of
encryption (Carter, 2019). Due to this, an attempt to make it more secure is made by encrypting it
using another symmetric key. The AES algorithm has now become the standard for encrypting
data at rest. It is also an integral part of many Internet protocols combining asymmetric and
symmetric key operations. It uses 128-bit blocks and can support multiple key sizes of 128, 192,
and 256 bits (Townsend Security, 2017). The 256-bit key size is used in the majority of new AES
implementations due to the increased security it provides. Therefore, this algorithm standard was
used in order to make the encryption more secure and make up for the disadvantages of using
symmetric keys.
Figure 67: Creation of DMK and certificate
The figure above shows the first step of encryption, which is the creation of the DMK and
the certificate. The password for the DMK is set to “Admin123”. Next, the certificate, which is
assigned the name “nurseid” is given the subject “Nurse Certificate”.
Figure 68: Symmetric keys creation and opening
Next, the first symmetric key, “nurse_symmkey”, is created with the algorithm set to AES-
256 to make it more secure and the symmetric key is encrypted using the certificate previously
60 | P a g e
created. Next, the second symmetric key, “ward_symkey” is created with the algorithm also set to
AES-256 to make it more secure and it is encrypted using the symmetric key “nurse_symmkey”.
Next, these keys are opened so that they can be used for the encryption process. Next, the
encryption is going to occur on the Nurse table in order to protect the nurse IDs and the ward IDs
that are present in that table. Therefore, four new columns are added into the table, which are the
“Encrypted_Nurse_ID” , the “Encrypted_Ward_ID”, the “Encrypted_Nurse_Fname” and the
“Encrypted_Nurse_Lname” with their data types set to varbinary using the code snippet below.
Figure 69: Adding new columns to Nurse table
Figure 70: Encrypting data
Next, the data is encrypted using the figure above. The “Encrypted_Nurse_ID” is going to
encrypt the data from the “Nurse_ID” column that is already present in the Nurse table, and this
encryption is going to take place using the “ward_symkey” symmetric key. The
“Encrypted_Ward_ID” is going to encrypt data from the “Ward_ID” column that is already present
in the Nurse table and the encryption is also going to be done using the “ward_symkey” symmetric
key. The same thing applies for the “Encrypted_Nurse_Fname” and the
“Encrypted_Nurse_Lname”, whereby each would encrypt the already existing “Nurse_Fname”
and “Nurse_Lname” columns. This encryption is going to be tested by printing out the contents of
the Nurse table. The output can be seen in the figure below.
61 | P a g e
Figure 71: Encrypted data in Nurse table
As can be seen from the figure above, the four columns, Nurse_ID, Ward_ID,
Nurse_Fname and Nurse_Lname have been encrypted and added into the Nurse table. All of the
columns in the nurse table have been encrypted since all of the columns contain sensitive data,
which comprise of unique IDs and the nurses’ names.
Figure 72: Closing of the keys
Lastly, the symmetric keys are closed in order to ensure the security of the database and
prevent breaches, as any access to the columns now needs these keys to be opened. To ensure that
this is done correctly, testing is done one of the columns to decrypt it and ensure that the data is
the same.
Figure 73: Decrypting data to ensure it is the same
As can be seen from the figure above, the keys need to be first re-opened in order to decrypt
the data. Next, the “Encrypted_Nurse_ID” is going to be decrypted and the data type is set to the
original column’s data type, which is char(5).
62 | P a g e
Figure 74: Decrypted data
As can be seen from the figure above, the data is successfully decrypted. This same decryption can
be used on any of the encrypted columns.
63 | P a g e
8 Backup and Restore Strategy

In any organisation, the incapability to access data due to a possible data breach,
cyberattack, natural disaster or anything of the sort can be crippling to their operations. This is
especially true for healthcare entities, whereby the loss, corruption or theft of patient data can lead
to potential disasters, especially since data is the pillar of healthcare and it just increases
exponentially every year (Tynan, 2019). According to (O'Flaherty, 2018), due to healthcare
organisations containing massive amounts of data regarding patients, these organisations are a
huge target for cyber-criminals as this data can be used for identity theft and obtain or capitalise
on medical benefits. This can be seen as an attack on Singapore’s governmental health database
was attacked, leading to the breach of 1.5 million patients (O'Flaherty, 2018). In healthcare,
breaches are especially dangerous since patient data can have severe consequences (Medicus IT,
2020). In her article, O'Flaherty highlights how data breaches may lead to medication being mixed
up or a patient not receiving the treatment and care they need (O'Flaherty, 2018).
Due to this, the Wellmeadows Hospital database has been fully backed up. In the future, a
differential backup will be implemented to back up any changes that have occurred since this full
backup. Firstly, there needs to be only one DMK. Therefore, a single new DMK is created for the
backup of the database centrally as can be seen in the code below.
Figure 75: Creation of new DMK for backup
As can be seen above, the password for this DMK is “wmasterkey@123”. Next, a
certificate is created with the subject set to “Backup Encryption Certificate”.
Figure 76: Certificate backup
64 | P a g e
Next, as can be seen from the figure above, the certificate that was created is backed up in
order to increase the security of the database and reduce the chances of this backed up data being
breached. Therefore, the certificate is backed up to a file with the private key also being generated
in that file and it is encrypted by the password “wmhospbackupkey@123”.
Figure 77: Database backing up
Next, the database is fully backed up to a file with compression to decrease and compress
the size of the backup file, and the encryption of this backup is set to the AES-256 algorithm and
the certificate being used to secure the backup. In order to ensure that the database has been backed
up, the certificate and the database will be dropped and there will be an attempt to restore them
from the created backed up files.
Figure 78: Certificate and database dropping
Figure 79: Certificate restoration using backed up data
As can be seen from the figure above, the first step in restoring the database is re-creating
the certificate using the backed-up certificate, private key and DMK password.
65 | P a g e
Figure 80: Database restoration
Next, the database is restored using the backed-up database file that is saved locally. As
can be seen above, the database has been restored successfully with the same number of pages.
66 | P a g e
References
Bednar, L. (2019, December 12). Importance of Encryption in the Healthcare Sector. Retrieved
from Secure Drive: https://www.securedrive.com/blog/importance-of-encryption-in-the-
healthcare-sector/
Carter, P. A. (2019). Encryption. In P. A. Carter, Pro SQL Server 2019 Administration (pp. 371-
408). Apress, Berkeley, CA.
Jeff. (2014, August 12). Advisories recommend 2048 for now. Security experts are projecting that
2048 bits will be sufficient for commercial use until around the year 2030. Retrieved from
security.stackexchange.com: https://security.stackexchange.com/questions/65174/4096-
bit-rsa-encryption-keys-vs-2048
Jones, S. (2017, August 15). Using Database Master Keys in SQL Server. Retrieved from SQL
Server Central: https://www.sqlservercentral.com/articles/using-database-master-keys-in-
sql-server
Medicus IT. (2020, January 30). Why Having IT Data Backup and Recovery Are More Important
Than Ever For Your Medical Practice in 2020. Retrieved from Medicus IT:
https://knowledge.medicusit.com/why-having-it-data-backup-and-recovery-are-more-
important-than-ever-for-your-medical-practice-in-2020
Microsoft. (2021, March 20). CREATE MASTER KEY (Transact-SQL). Retrieved from Microsoft
Docs: https://docs.microsoft.com/en-us/sql/t-sql/statements/create-master-key-transact-
sql?view=sql-server-ver15
Microsoft. (2021, June 12). Encryption Hierarchy. Retrieved from Microsoft Docs:
https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/encryption-
hierarchy?view=sql-server-ver15
Microsoft. (2021, March 4). SQL Server and Database Encryption Keys (Database Engine).
Retrieved from docs.microsoft.com: https://docs.microsoft.com/en-us/sql/relational-
databases/security/encryption/sql-server-and-database-encryption-keys-database-
engine?view=sql-server-ver15
Microsoft. (2021, September 10). SQL Server Certificates and Asymmetric Keys. Retrieved from
docs.microsoft.com: https://docs.microsoft.com/en-us/sql/relational-
databases/security/sql-server-certificates-and-asymmetric-keys?view=sql-server-ver15
67 | P a g e
Microsoft. (2021, September 11). Use the inserted and deleted Tables. Retrieved from Microsoft
Documents: https://docs.microsoft.com/en-us/sql/relational-databases/triggers/use-the-
inserted-and-deleted-tables?view=sql-server-ver15
N-able. (2019, July 29). Understanding AES 256 Encryption. Retrieved from www.n-able.com:
https://www.n-able.com/blog/aes-256-encryption-algorithm
O'Flaherty, K. (2018, October 5). Why Cyber-Criminals Are Attacking Healthcare -- And How To
Stop Them. Retrieved from Forbes:
https://www.forbes.com/sites/kateoflahertyuk/2018/10/05/why-cyber-criminals-are-
attacking-healthcare-and-how-to-stop-them/?sh=415667c87f69
Oracle. (2021). Oracle INSTEAD OF Triggers. Retrieved from Oracle Tutorial:
https://www.oracletutorial.com/plsql-tutorial/oracle-instead-of-triggers/
Puranik, M. (2020, August 5). Why Encryption is Essential in Healthcare Cybersecurity Strategies.
Retrieved from Health IT Security and Compliance: https://www.healthitanswers.net/why-
encryption-is-essential-in-healthcare-cybersecurity-strategies/
Specops. (2019, September 26). Healthcare encryption standards. Retrieved from Specops:
https://specopssoft.com/blog/healthcare-encryption-standards/
Stanford Medicine. (2017). Harnessing the Power of Data in Health. Stanford University.
Thales. (2021). What is HIPAA HITECH? Retrieved from Americas Compliance:
https://cpl.thalesgroup.com/faq/americas-compliance/what-hipaa-hitech
Townsend Security. (2017). THE DEFINITIVE GUIDE TO SQL SERVER ENCRYPTION & KEY
MANAGEMENT. Townsend Security.
Tynan, D. (2019, October 25). Make Backup Planning a Forefront Objective. Retrieved from
DATA CENTER: https://healthtechmagazine.net/article/2019/10/make-backup-planning-
forefront-objective
68 | P a g e
Appendices
Workload Matrix
JOHNSON WONG RICHARD WIJAYA MUZAMIL MOHAMMED
(TP047339) (TP053319) (TP048867)
Entity Relationship Model (ERM)
Assumptions 33% 33% 33%
Business Rules 33% 33% 33%
Logical Design 33% 33% 33%
Entity Relationship Diagram (ERD) 33% 33% 33%
Database Auditing Environment
Aim & Objectives 33% 33% 33%
Audited Entities 33% 33% 33%
People 33% 33% 33%
Procedures 33% 33% 33%
Database 33% 33% 33%
Backup & Restore Strategy 33% 33% 33%
Signature
69 | P a g e

Johnson Wong TP047339 DBS Report

Uploaded by

Copyright:

Available Formats

You might also like

Johnson Wong TP047339 DBS Report

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Johnson Wong TP047339 DBS Report

Uploaded by

Copyright:

Available Formats

GROUP ASSIGNMENT

TECHNOLOGY PARK MALAYSIA

STUDENT NAME : JOHNSON WONG ING CHENG (TP047339)

MUZAMIL MOHAMMED AHMED (TP048867)

RICHARD WIJAYA (TP053319)

LECTURER : MR. ABDALLAH S.M. ALNATSHA

HAND IN DATE : 01ST NOVEMBER 2021

1 Entity Relationship Model (ERM)....................................................................................... 1

1.1 Assumptions .................................................................................................................. 1

1.2 Business Rules ............................................................................................................... 1

1.3 Logical Design ............................................................................................................... 4

1.4 Entity Relationship Diagram (ERD) ............................................................................. 5

2 Database Auditing Environment ......................................................................................... 9

2.1 General Objectives ........................................................................................................ 9

2.2 Audited Entities .......................................................................................................... 10

2.3 People .......................................................................................................................... 11

2.4 Procedures .................................................................................................................. 12

2.5 Database ...................................................................................................................... 12

3.0 Authorization Matrix...................................................................................................... 13

3.1 Richard Wijaya (TP053319) ....................................................................................... 13

3.1.1 Head Nurse ........................................................................................................... 13

3.1.2 General Nurse ...................................................................................................... 14

3.2 Johnson Wong Ing Cheng (TP047339) ....................................................................... 15

3.2.1 Hospital Management .......................................................................................... 15

3.2.2 Doctor ................................................................................................................... 16

3.3 Muzamil Mohammed Ahmed Abdulatief (TP048867)................................................ 17

3.3.1 Trainee Nurse ....................................................................................................... 17

3.3.2 Receptionist .......................................................................................................... 18

4.1 Richard Wijaya (TP053319) ....................................................................................... 19

4.3 Muzamil Mohammed Ahmed Abdulatief (TP048867)................................................ 24

5.1 Richard Wijaya (TP053319) ....................................................................................... 26

5.2 Johnson Wong Ing Cheng (TP047339) ....................................................................... 28

5.3 Muzamil Mohammed Ahmed Abdulatief (TP048867)................................................ 30

6 Data Manipulation Language (DML) Trigger .................................................................. 32

6.1 Richard Wijaya (TP053319) ....................................................................................... 32

6.1.1 Track changes in the Nurse table ......................................................................... 32

6.1.2 DML trigger to check Actual Leave date ............................................................. 35

6.2 Johnson Wong Ing Cheng (TP047339) ....................................................................... 37

6.2.1 DML Trigger to Track Changes/Audit in Ward Entity ....................................... 37

6.3 Muzamil Mohammed Ahmed Abdulatief (TP048867)................................................ 42

6.3.1 Track Changes Made to Patient Table................................................................. 42

6.3.2 Avoiding Deletion of Patient Using Instead of Trigger ........................................ 45

7.1 Richard Wijaya (TP053319) ....................................................................................... 48

7.2 Johnson Wong Ing Cheng (TP047339) ....................................................................... 53

7.3 Muzamil Mohammed Ahmed Abdulatief (TP048867)................................................ 59

8 Backup and Restore Strategy ............................................................................................ 64

Workload Matrix .............................................................................................................. 69

1 Entity Relationship Model (ERM)

1.2 Business Rules

1.3 Logical Design

Full View: https://drive.google.com/file/d/1gQaP5JUQciRs_yH7upSxpsj1BK_BfhCi/view?usp=sharing

1.4 Entity Relationship Diagram (ERD)

Full View: https://drive.google.com/file/d/1gQaP5JUQciRs_yH7upSxpsj1BK_BfhCi/view?usp=sharing

2 Database Auditing Environment

2.1 General Objectives

2.2 Audited Entities

3.0 Authorization Matrix