The document assesses adding four new requirements to the iTrust medical records system: adding an emergency responder role, finding qualified healthcare professionals, updating diagnosis codes, and viewing access logs. Adding the emergency responder role carries the most risk as it provides access to sensitive patient data. Proper access controls, authentication, and encryption are recommended to secure data access and mitigate vulnerabilities like unauthorized access, wireless communication attacks, and credential misuse. A role-based access control model and two-factor authentication are suggested for emergency responders.

1. Running head: SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
1
Security Assessment of Adding Four Requirement to the iTrust Medical Record System
Team Blazers: Geoff Akey, Sarah Hall, Matt Jenkins, Dauryl Belle, Ronald Jackson,
James Shircliffe
University of Maryland, University College
October 25, 2015
Dr. Johnson Kinyua

2. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
2
Table of Contents
Section 1.0: Introduction………………………………………………………………… 3
Section 1.1: Scope Note………………………………………………………………4
Section 1.2: Methodology……………………………………………………………. 4
Section 1.3: System Description……………………………………………………... 5
Section 2.0: Assessment of New requirements…………………………………………... 5
Section 2.1: Add Role Emergency Responder………………………………………. 5
Section 2.2: Find qualified licensed health care professional……………………….. 7
Section 2.3: Update Diagnoses Code Table………………………………………… 12
Section 2.4: View Access Log……………………………………………………… 15
Section 3.0: Recommendations…………………………………………………………. 18
Section 3.1: Authentication………………………………………………………… 18
Section 3.2: Training………………………………………………………………... 19
Section 3.3: Access Control Policy…………………………………………………. 19
Section 3.4: Encryption…………………………………………………………….. 20
Section 3.5: Code Review………………………………………………………….. 20
Section 4.0: Implementation……………………………………………………………. 21
Section 5.0: Findings……………………………………………………………………. 21
References………………………………………………………………………………. 23

3. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
3
Section 1.0: Introduction
The Health Insurance Portability and Accountability Act (HIPAA) has set out the
creation and maintenance of electronic health records (EHR) as the means by which
patient care can be improved while the overall costs of healthcare to society can be driven
down. However, the ability to consolidate patient records and increase their portability
has increased their vulnerability to theft and exposure. Along with the requirement to
create EHRs, HIPAA has mandated security requirements for a class of information
identified as electronic protected health information (ePHI) in an effort to protect the
confidentiality of Personally Identifiable Information (PII) from criminal misuse and
general exposure.
The iTrust Medical Care Requirements System (iTrust) has been identified as a
Major System under the jurisdiction of HIPAA and is subject to the requirement to
implement “reasonable and appropriate” computer security safeguards. iTrust is an open
source software application designed to allow patients to review their medical history as
well as make decisions regarding their future medical treatment. Also, iTrust allows
medical professionals to access and track patient records from diverse location, and
perform various task functions like scheduling, prescription management, messaging, and
so on.
HIPPA is comprised of two rules, the Privacy Rule and the Security Rule. The
Privacy Rule, or Standards for Privacy of Individually Identifiable Health Information,
establishes national standards for the protection of certain health information. The
Security Standards for the Protection of Electronic Protected Health Information (the
Security Rule) establishes a national set of security standards for protecting certain health

4. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
4
information that is held or transferred in electronic form”. (“Understanding HIPPA”,
n.d.). The exposure of patients’ information does not include specific health information,
but it does include information that can identify an individual, thus putting them at risk
for social engineering attacks, such as phishing attacks. HIPAA denotes PII as referring
“to information that can be used to distinguish or trace an individual’s identity, either
alone or when combined with other personal or identifying information that is linked or
linkable to a specific individual” (“Rules and Policies”, 2014). This is the type of
information that iTrust currently contains.
Section 1.1: Scope Note
Team Blazer has conducted a security assessment on the addition of four new
requirements to iTrust: add the role of emergency responder, find a qualified healthcare
professional, update diagnosis code table, and view access log. The assessment was not
meant to look at the existing implementation and architecture, except where it was
pertinent to the addition of the four new requirements, as the security posture of the new
requirements will be shaped by the existing implementation. Conversely, the new
requirements will necessitate capabilities that will alter the existing implementation.
While Team Blazer’s recommendations for adding and implementing the new security
features necessitated by the new requirements are meant to be integrated into existing
iTrust security policies, it is believed they will enhance the overall security posture.
Section 1.2: Methodology
To conduct this security assessment Team Blazer identified each database and the
amount of ePHI it contained, then Team Blazer employed the Delphi method to
determine the value of each database. Then it was determined which of these databases

5. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
5
each new requirement would have to access and what vulnerabilities each requirement
contained to identify an increased attack surfaces that might expose ePHI.
Recommendations and an implementation strategy was then documented to offer courses
of action to decrease the new attack surface.
Section 1.3: System Description
The iTrust system relies on open source software. It uses an Apache Tomcat
Server to run a MySQL Database in a Windows environment. The web application side
of iTrust relies on an Eclipse framework running Java Developer Kit libraries.
Section 2.0: Assessment of New Requirements
Section 2.1: Add Role Emergency Responder
Description of Requirement.
Of the four new requirements being added to iTrust the addition of a new system
role, that of Emergency Responder, carries with it the most risk. This role could relate to
varying fields of service ranging from police officers to emergency medical
technicians. Having a database requirement of this scale can potentially provide access to
highly sensitive data. Users with this access control will become attributed toward
specific controls of medical records that are seamless with job associations of licensed
and unlicensed health care professionals, patients and iTrust administrators.
Creating this defined role will provide emergency responders the access to
information essential toward job efficiency and the enhancement of the number of lives
saved. Given the time sensitive nature of the work and the immediacy of the function to
the saving of human life the role of emergency responder is highly privileged in the
iTrust system. Team Blazer see this role being secured through a mobile cellular

6. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
6
connection via a terminal traveling with the emergency responder communicating
through a Virtual Private Network (VPN).
Vulnerabilities/security issues.
If data that is relative toward the Emergency Responder role is compromised or
accessed outside of the privilege assigned right user; iTrust would assume responsibility
of non-adherence with HIPAA law and rights. The U.S. Department of Health & Human
Services (HHS) states that the HIPPA Privacy Rule, as well as all the Administrative
Simplification rules, apply to all health plans, health care clearinghouses, and to any
health care provider who transmits health information in electronic form in connection
with transactions for which the Secretary of HHS has adopted standards under HIPAA.
(U.S. Department of Health & Human Services, n.d.) Integrated into this database
deployment a HIPAA violation would happen if internal access is not moderated or an
outside intrusion ensues. To effectively defend against these two threat vectors there is
need for developed policy that itemizes access along with perimeter and internal defense
mechanisms. Implementing access controls on a built in VPN, or through authentication
and firewalls, can assist in partitioning unauthorized access to the role of emergency
responder. Team Blazer suggests iTrust deploy a Role Based Access Control (RBAC)
solution using the Biba model association. (Biba Model, 2007)
The wireless communication pathway represents a second vulnerability. With
their scope of duties and responsibilities they are mobile and most if not all
communication will be done off site. This communication will be conducted utilizing the
emergency communication bands and/or the cellular network depending on the required
bandwidth. This vulnerability provides access to outside threats and the potential for

7. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
7
malicious penetration can occur, attack vectors ranging from man-in-the middle to
masquerading can potentially occur. Most suppliers and end users have settled on either
ISA100.11a (IEC 62734) or WirelessHART (IEC62591) as methods of protection
(Control Engineering, 2015). They both comprise of highly multifarious encryption
methods and utilize block cipher encryption standard of 128-bit AES. Stabilizing and
having firm control of the transport layer is only the start, there can also be threats toward
the actual disruption of communication of all radio devices and this level of security is
more intense in control.
Team Blazers recommends implementing a two factor authentication scheme for
emergency responders to access iTrust. While patients may access iTrust remotely over
architecture with as much vulnerability as the emergency responders, their enhanced
privliges at login means extra carry needs to be given to verifying their access. The use of
passwords and tokens is recommended as this will be far easier to deploy and manage.
Credential also brings another level on vulnerabilities in that the effectiveness is
determinant of how effective those in possession of credentials are with confidentiality
and security. Some users will have lazy habits and leave credentials in open areas, share
them with other users and bring them outside of the work environment. To mitigate
instances of credential fraud effective training of users and security polices can be
adopted. (Hodgson, 2014)
Section 2.2: Find qualified licensed health care professional
Description of Requirement
This requirement allows a patient who has just been diagnosis to find licensed
health care professionals (LHCPs) in the area who have experience handling that

8. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
8
condition. The patient chooses 'My Diagnoses” and is presented with a listing of all their
own diagnoses sorted by diagnosis date, with the most recent first. The patient can select
a diagnosis and will be presented with the LHCPs in the patient's living area, based upon
the first three numbers of their zip code, who have handled this diagnosis in the last three
years. The list is ranked by the quantity of patients the LHCP has treated for that
diagnosis, and each patient treated is only counted once regardless of the number of
office visits. For each LHCP, the following information is displayed:
 Name of LHCP linked to contact information for that LHCP
 The quantity of unique patients treated by that LHCP for that diagnosis.
 List of all prescriptions given by that LHCP for that diagnosis.
 List of all laboratory procedures ordered by that LHCP for that diagnosis
 The LCHP's average visit satisfaction.
 The LHCP's average treatment satisfaction
Vulnerabilities/security issues:
As the patient will be accessing this feature remotely the attack surface to iTrust is
expanded with vulnerabilities inherent in web applications and web browsers: Cross-Site
Scripting (XSS), Standard Query Language Attack Injection (SQL Injection), and Cross-
Site Request Forgery (CSRF)
Threat 1: Cross-Site Scripting (XSS)
In Cross-Site Scripting (XSS) attacks, an attacker injects scripts into trusted web
sites from the web session of an unsuspecting user. The XSS attacker manipulates the
unsuspecting user to send his, the attackers, malicious script to a target website via the

9. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
9
victim’s web browser. The target web site sees the request as coming from the victim’s
browser, a known and trusted account, and will execute the request (VeraCode, 2015).
The vulnerabilities are normally based in the web browser and are quite
common. They enable attacks to occur where ever web applications use input from a
user within the output it generates without encoding or validating it.
Because the script is coming from a trusted source, the targeted web application
has no way to validate that the script is suspect, and will execute the script. Due to the
trust relationship, the malicious script can access session tokens, cookies, or other
sensitive information retained by the browser for use with that site (OWASP, 2013).
In a Server XSS, the vulnerability is in server-side code where the browser
accepts the response and executes any valid-looking script embedded in it. It is termed a
“Reflected Server XSS” if the source of the data, the combined legitimate and malicious
code, comes from a user or object request. It is termed a “Stored Server XSS” if the
source of the data comes from a stored location.
Client XSS occurs when untrusted and invalidated user supplied data updates to a
Document Object Model (DOM is an application programming interface, or API, for
HTML and XML documents) with an unsafe JavaScript call. The source of the data could
be from the DOM, or it could have been sent by the server via a page load. The term
“Reflected Client XSS” refers to the source of the data coming from a request from a user
or object, and the term “Stored Client XSS” is coming from a stored location. The
importance here is that a DOM based XSS has its origins from the DOM and is a Client
XSS (OWASP, 2013).

10. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
10
When a XSS attack is successfully in exploiting these vulnerabilities, the attacker
can: (1) gain access to account credentials, (2) spread web worms, (3) access the user’s
computer and view the user’s browser history, (4) or control the browser remotely, and
(5) gain control of other applications, in addition to the browser (VeraCode, 2015).
To mitigate XSS Threat Team Blazer recommends all input submitted to any
application in the system must be treated as untrusted until validated. This would ideally
be written in to the application during the development stage. If not, then a web
application firewall can be installed to perform this filtering function. Addressing this
vulnerability is more costly, in the long term, by a post-production WAF or intrusion
detection product. It is cheaper and more effective when the security aspects of the
product are addressed during its development.
Threat 2: Standard Query Language Attack Injection
Any database that seeks user input and stores data in a back-end database is
potentially vulnerable to SQL injection. Most databases have some variant of SQL to
interoperate with web servers and application servers when they need to change, retrieve,
delete, and/or store data. An attacker can therefore add user accounts to the database, as
well as adding or removing transactions.
An attack would “inject” malicious code to get the database to provide data where
it should not. User input is required to execute the input below, a login. The interpreter
will execute the command based on the inputs received for the username and password
fields, such as:
String SQLQuery =”SELECT Username, Password FROM users WHERE Username=’ ”
+ Username + “ ‘ AND Password=’ “ + Password +” ‘;

11. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
11
To exploit this code an attacker provides a ‘or 0=0’ as the username and
password, as below:
String SQLQuery =”SELECT Username, Password FROM users WHERE Username=”
or 0=0” “ ‘ AND Passwords=” or 0=0” “ ‘ “;
This is a truthful statement, as 0 does equal 0, and the site will return without
error, indicating that the site is open to further malicious code that can further exploit the
database.
Team Blazer recommends building security in to development lifecycle to ensure
new applications and databases being designed today with protections against these
threats can be considered in future infrastructure (O’Boyle, 2012). Also, iTrust needs
strongly typed parameterized query Application Program Interfaces (API) with
placeholder substitution markers, even when calling stored procedures. Parameterized
queries limit the level of influence an attacker can have in exploiting the database
(VeraCode, 2015).
Threat 3: Cross-site Request Forgery (CSRF)
A Cross-Site Request Forgery (CSRF) attack manipulates a user to click on a link
taking them to a malicious Web site. The site then establishes a trusted link that enables
the attacker, from the website, to perform a function in the user’s name/credentials. XSS
exploits client’s validation of the application or website. CSRF exploits the opposite, the
trust the site has in the user. (Auguer, 2010) If the victim clicks on an embedded HTML
or JavaScript code from an e-mail or website, the code will request a specific URL that
will task the victim system. This exploit can go around HTTPS security, and operate

12. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
12
without the user’s knowledge. CSRF can also utilize an XSS flaw to indirectly get to the
targeted websites or applications (OWASP, 2015).
Team Blazer notes that the Synchronizer Token Pattern is recommended by
OWASP to process that generates random "challenge" tokens to be checked against a
current session. This tool enables the development of applications with strong verification
of the user’s submission of the requests. This helps limit, or eliminate, CSRF attacks in
sensitive data operations. The Encrypted Token Pattern utilizes encryption for Token
validation. Once properly authenticated, a unique Token is created at the server using a
unique key. The Token is then embedded in a secret field by the user’s system. Requests
are received by the server reads, which then reads the users Token value utilizing the key
used by the server to create the Token.
Team Blazer notes that the most effective counter to this attack is the
development of a security conscious culture. These include the familiar actions of
logging off immediately after using a Web application, do remember sites, do not save
passwords, use different browsers for sensitive or higher-risk activities (banking) and for
general surfing or research, and utilize plug-ins that make CSRF difficult (e.g. No-Script)
(OWASP, 2013).
Section 2.3: Update Diagnoses Code Table
Description of Requirement
Within this requirement, the American Medical Association has decided to
convert all diagnoses from the current code ICD-9CM to ICD-10CM. This code change is
to only affect the ovdiagnosis and icdcodes databases. According to the Medicaid.gov
(2014), there have been many changes in the current code reporting. The changes include

13. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
13
code set changes from five to seven positions, 68,000 diagnosis codes in ICD-10CM
compared to the 13,000 in ICD-9CM, and modernized terminology.
There are a few challenges faced when converting to the new codes set as
described by Medicaid (2014). These changes do not allow a one-to-one mapping from
the old code version to the new. By the code not being able to map from new to old poses
a scenario where any related databases must be altered to reflect the new code set. In our
Addendum, the only databases that have a direct correlation to the change in the codes
are icdcodes and ovdiagnosis. These databases have the standard codes for diagnosis,
which will be changing. The indirect relationship to other databases would be the link the
diagnosis and the VisitID. This correlation maps the Diagnosis to the VisitID, which
entails links to a lab procedure. Hazlewood (2003), talks about how ICD-9CM is
ineffective for monitoring, measuring and analyzing health care cost. The new methods
allows for further visibility on diagnosis codes as well as proper procedures. Hazlewood
(2003) also states, “These changes should result in major improvements in both the
quality and uses of data for various healthcare settings.”
Vulnerabilities/security issues:
When converting from ICD-9CM to ICD-10CM the many security risks
associated with the previous code version are mitigated through the upgrade process. But
like many versions of code, software updates and patches are still vulnerabilities that
allow for most security threats. Medical research as well as medical coding plays a big
part in healthcare as well as protecting our homeland. Many biological threats as well as
man made diseases can be released in which can cause life threatening damage. Gaudio
(2015) outlines how with the new ICD-10CM code can help health officials track and

14. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
14
monitor patients and diseases better than the old coding version ICD-9CM. ICD-9CM
does not give a full in depth look at tracking parameters which might get overlooked due
to the method being non specific. ICD-10CM allows for better tracking as well as a closer
look of patient care by utilizing a 68,000 code database compared to ICD-9CM’s 13,000
code stream.
When transitioning to this new code version, the room for a potential hacker to
intercept certain databases and change information widens. The integrity of the codes
used in ICD-10CM is extremely important as it relates to the diagnosis of specific
illnesses. Keeping information contained in this database must have a multi-form
authentication method and only allowed access to a set group of individuals. Information
contained in these databases must stay compliant with the American Health Information
Management Association (AHIMA). This organization governs the management of
computer, personnel, and patient information and makes sure the integrity and security of
the data stays up-to-date. Overall, there are more added security and fixed vulnerability
features in the new version of code. The biggest problem comes down to keeping the
database secured and accessible to only privileged individuals.
Team Blazer notes that when conducting any type of upgrades, as well as going
from a new platform to an old, can be a bit complex from the standpoint of big data as
well as security and integrity. In the case of the ICD-9CM database upgrade to ICD-
10CM, these databases contain medical diagnoses that are very vital to the medical
procedures and medical treatment that occurs. Team Blazer recommends that when going
between databases, there needs to be a clear and precise plan of action. One must know
the differences and functionalities that the new platform has that the old one does not

15. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
15
support. In the case of ICD-10CM, this platform has 68,000 codes compared to the
13,000 with ICD-9CM. When moving data between codes, there should be an integrity
audit done before and after to validate that information did not change. Depending how
data is migrated, the network the migration takes place on should be secured and if
possible done locally. There should not be a shared user on the server that has access to
alter the databases during the move.
Once the migration has been completed, a system administrator (SysAdmin) must
take further precautions to make sure the proper users have the right permissions to the
database. Because some codes may have changed as well as have been linked and altered
to other databases, there needs to be a consistency check that is performed to evaluate any
changes that need to be made. Database security is a high priority especially in the
medical field. One simple change can mean life or death for a patient. Do to certain
medical laws, data must only be accessed by privileged personnel. Although databases
live on servers that also add another layer of protection from unauthorized data, knowing
the vulnerabilities of the running platform and understanding the various ways that a
potential hacker can gain control and access highly privileged data
Section 2.4: View Access Log
Description of Requirement
The requirement to view the access log states “A patient can view a listing of the
names of licensed health care professionals that viewed or edited their medical records
and the date the viewing/editing occurred is displayed”. In order to satisfy this
requirement, patients must have access to the following tables in the database: patients,
users, transaction log and personnel. The figure below outlines what data is available in

16. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
16
each database table, and viewable by the patients who will have the ability to view the
access log.
Figure 1. Data type in data base tables utilized by “View Access Log” requirement.
Information
Patients MID, lastName, firstName, email, address1, address2, city, state, zip1,
zip2, phone1, phone2, phone3, eName, ePhone
Users MID, Password, Role, sQuestion, sAnswer
transactionlog transactionID, loggedInMID, secondaryMID, transactionCode,
timeLogged, addedInfo
personnel MID, role, enabled, lastName, firstName, address1, address2, city,
state, zip, zip1, zip2, phone, phone1, phone2, phone3, specialty
Vulnerabilities/security issues:
Access to patient information via the patient table creates several potential
security issues to include: increased risk of access to PII violations, increased risk of
patients being targeted for attacks (i.e. phishing, social engineering), and inference
attacks. Although the data contained in the patient table is not susceptible to HIPPA
violations, it is considered PII. Access to the patient table should be tightly controlled,
allowing only those with a need to know have access to modify the data. Additionally,
patients should only have access to their own information, and healthcare providers
should only have access to the data of patients they are assigned to. The protection of
patient information in the database should be outlined in an Access Control Plan created
and maintained by iTrust and all access should be managed by SysAdmins.
If compromised, the data in the users table would allow an attacker to gain access
to all data contained on the iTrust website because the table contains every user’s
password and security questions and answers. No one should have access to this table,

17. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
17
and even SysAdmins should have limited access to it. Encryption should be implemented
either on the entire table itself or per field. Another option is for iTrust to implement the
use of two factor authentication as described in Section 2.1 as opposed to the current
username/password. This would be a much more secure method of having users access
the system and would significantly reduce the likelihood of either a user with malicious
intent or an attacker from gaining access to the entire system and all data contained in it.
Although the transactionlog table does not contain PII, a user with malicious
intent could infer certain information from the data contained in the table. The user could
parse out all transactions performed by a specific MID and determine various information
based on that person’s transactions. For example, if MID 1 was performing actions that
would be indicative of a SysAdmin, the malicious user could target the user with that
MID in order to gain access to the entire system.
The personnel table also contains very sensitive information about the medical
personnel and SysAdmins using the system. If compromised, an attacker could use the
data to either gain access to patient’s information or target them in a social engineering
campaign. As with the patient table, the personnel table also contains PII about the
medical providers. The data contained in this table should be treated the same as the data
in the patients table to include encryption of data and strict access control rules.
Team Blazer recommends that in order to protect the data contained in each of
these tables, especially the patients and users’ tables, iTrust should encrypt their data in
the database. There should also be privacy and security disclaimers on the website to
ensure anyone using the site is aware of the privacy and security regulations specific to
the data on the website.

18. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
18
An Access Control Plan should be created and managed by iTrust, outlining
specifics about how access control is implemented and what the permissions are for each
table and the specific fields contained within them. The Access Control Plan can be
included as part of the security documentation created by iTrust and should be modified
every time an access control is changed (i.e. new roles or permissions are created).
iTrust should reevaluate their user authentication method in order to ensure access
is more securely controlled and auditable. The use of Public Key Infrastructure (PKI)
can greatly improve the iTrust website’s security. “By managing keys and certificates
through a PKI, an organization establishes and maintains a trustworthy networking
environment” (“Securing Digital”, 2015).
Section 3.0: Recommendations
Team Blazers has developed five recommendations to enhance the security
posture of iTrust.
Section 3.1: Authentication
The first measure iTrust should implement is a strong password management
process. This can be done through various methods. General users of the system (i.e.
patients and medical providers) should be required to create strong passwords and it
should be enforced by the system. SysAdmins should be required to take training
regarding the enforcement and management of passwords. Additionally, no admin
passwords should be shared. iTrust should also consider using a two factor
authentication system, possibly using PKI certs, for user authentication instead of a
username/password model. While this may prove an extra burden to patients, Team
Blazer believes that it is absolutely critical for use amongst emergency responders,

19. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
19
system administers, and medical staff with access to numerous patient records as their
privileged positions make the loss of their accounts more damaging to ePHI.
Section 3.2: Training
iTrust should also provide training to all employees who access, or administer, the
website, specifically training on the handling of PII, patient health, and medical
information; and, what actions should taken in the event of a breach. Training should
also include any penalties for failure to comply with rules and regulations related to PII
and patient medical information. Training for the administrators of the system can be
implemented at a corporate level to include specific training on how PII and patient
health information should be handled and stored. Training can include quarterly and
annual training that is documented and maintained in order to ensure all employees with
access to this type of data is aware of all rules and regulations applied to the various types
of data stored in the iTrust databases.
Section 3.3: Access Control Policy
An Access control policy should be designed and documented to specifically
identify the roles and permissions of every user of the system. iTrust can implement Role
Based Access Control (RBAC) along with Attribute Access Control (ABAC), which
allows for certain discretionary controls outlining specific permissions for each
user. Administrators of the system should be the only users who have access to all data
while other users have access to only data they have been approved for. Tracking of the
roles and permissions should also be included in any security documentation created by
iTrust and reviewed periodically for accuracy. The implementation of access control
should be carefully designed and tested by iTrust before implementing in their production

20. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
20
environment. iTrust should consider using a RBAC/ABAC model in order to ensure
access is strictly controlled. (Edward, 2012). “When combined judiciously, the
combination can provide access control that’s scalable, flexible, auditable, and
understandable” (Coyne & Weil, 2013). The graphic below depicts how the two can be
combined, ensuring each user has access to only the data they are allowed to.
Section 3.4: Encryption
The encryption a of ePHI while in motion and at rest is essential to the security of
iTrust. Given the sensitivity of the nature of the information being handled a symmetric
key system would be recommended, but given the large and distributed nature of the
users Team Blazers recommends an asymmetric encryption scheme. Implementing
encryption could take significant time due to the acquisition of hardware and software as
well as determining what should be encrypted, the level of encryption and training for
those administering the encryption hardware and software. iTrust will need to determine
if the data in all tables should be encrypted or only those with very sensitive data such as
the patients, users and personnel tables.
Section 3.5: Code Review
Team Blazers recommends that a code review of iTrust be implemented to detect
poor scritping language. As iTrust relies on a web application for patients to access an
SQL database the largest number of attacks will most likely come through this low cost
attack vector. As many coders are pressed to complete a production, and are often not
trained in security, it is likely that flawed code writing can be found.

21. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
21
Section 4.0: Implementation
Team Blazers recommends that a phased approach be taken when rolling out each
new requirement should be added one at a time to the iTrust production environment,
with vulnerability testing conducted after each phase to identify security vulnerabilities in
new environment. Security vulnerabilities include software conflicts, new flaws,
invalidated patches, all of which could open new attack vectors.
Ideally, before the first requirement is rolled out the recommendations made in
the previous section would be applied to the existing system, especially the encryption
and ACP as these would prove difficult to modify after the fact when the emergency
responder role is added and the associated mobile architecture is implemented. Only after
the first review for existing vulnerabilities, and noting potential future vulnerabilities
from the next modifications, proceed to the installing the next requirement. Each new roll
out should be accompanied by fresh training iterations, if not for patients, definitely by
medical staff and highly privileged system users.
Team Blazers recommends that the role of Emergency Responder be the last
requirement added. This requirement institutes a fundamental shift in access and has the
greatest potential for creating vulnerabilities from inappropriate implementation. The first
three security reviews will address the learning curve, after the IT staff implements each
new requirement.
Section 5.0: Findings
Team Blazers has determined that the addition of the four new requirements to the
iTrust medical Record System is a classic case study in an inadvertent shifting in security
posture based on what most lay people would consider a simple adaptation of an existing

22. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
22
system. However, each additional user role, medical management capability, and
software update comes with it a shift in the vary nature of how the system works by
altering the means by which entry is gained and by which software objects relate and
communicate with each other. This transformation alters the attack surface of the system
requiring a complete rethinking of the organization’s existing security policies and
postures. While systems should undergo security reviews periodically, at least annually,
these can normally be seen as evaluating the risks collected from software and
application changes/upgrades, patching, failing to patch, or the advancement of the
exploitation tools. The addition of new requirements to the system move the security
review process from looking at the evolutionary shift in a systems resource to a
fundamental change in system architecture, which requires a whole new evaluation.

23. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
23
References
Auger, R. (2010, April). The Cross-Site Request Forgery (CSRF/XSRF) FAQ. CGI
Security. Retrieved from http://www.cgisecurity.com/csrf-faq.html
Biba Model. (2007). Network Dictionary, 64-65.
Coyne, E., & Weil, T. (2013). ABAC and RBAC: Scalable, Flexible, and Auditable
Access Management. IT Professional IT Prof., 14-16. Retrieved November 8,
2015, from http://csrc.nist.gov/groups/SNS/rbac/documents/coyne-weil-13.pdf
Edward, K. (2012, July 2). Attribute based access control (ABAC) for fine grained
access. Retrieved November 8, 2015, from http://blog.empowerid.com/blog-
1/bid/180021/Attribute-based-access-control-ABAC-for-fine-grained-access
Gaudio, N. (2015, January 21). Could an ICD-10 delay threaten national security?
Retrieved November 10, 2015, from http://www.beckershospitalreview.com/icd-
10/could-an-icd-10-delay-threaten-national-security.html
Hazlewood, A. (2003). ICD-9 CM to ICD-10 CM: Implementation Issues and
Challenges. Retrieved November 10, 2015, from
http://library.ahima.org/xpedio/groups/public/documents/ahima/bok3_005426.hcs
p?dDocName=bok3_005426
Helme, S. (2015, March). Hardening your HTTP response headers. Information Security
Consultant. Retrieved from https://scotthelme.co.uk/hardening-your-http-
response-headers/
Hodgson, K. (2014). The 'new' access credential: cost, convenience and security are keys
to credentialing decisions--today and tomorrow. Security Distributing &
Marketing, (10). 79.
ICD-10 Changes from ICD-9. (n.d.). Retrieved from
http://www.medicaid.gov/Medicaid-CHIP-Program-Information/By-Topics/Data-
and-Sysstems/ICD-Coding/ICD-10-Changes-from-CD-9.html
ICD-10/CAC Coding Summit (n.d.). Archieving ICD-10-CM/PCS Compliance in 2015:
Staying the Course for Better Healthcare-A Report from the AHIMA 2014.
Retrieved
ICD-10/CAC Coding Summit. (n.d.). Achieving ICD-10-CM/PCS Compliance in 2015:
Staying the Course for Better Healthcare-A Report from the AHIMA 2014.
Retrieved from http://perspectives.ahima.org/achieving-icd-10-cmpcs-
compliance-in-2015-staying-the-course-for-better-healthcare-a-report-from-the-
ahima-2014-icd-10cac-coding-summit/

24. SECURITY ASSESSMENT OF ADDING REQUIREMENTS TO ITRUST
24
O’Boyle, R. (2012, August). SQL Injection Explained. YouTube.com. Retrieved from
https://www.youtube.com/watch?v=2_XkXgeJxHI
OWASP. (2013, October 29). Types of Cross-site Scripting. Open Web Application
Security Project. Retrieved from
https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting
OWASP, (2015, November). Cross-Site Requesty Forgery (CSRF) Prevention Cheat
Sheet. Open Web Application Security Project. Retrieved from
https://www.owasp.org/index.php/Cross-
Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
Rules and Policies - Protecting PII - Privacy Act. (2014, December 19). Retrieved
November 8, 2015, from http://www.gsa.gov/portal/content/104256
Securing Digital Identities & Information. (2015). Retrieved November 8, 2015, from
https://www.entrust.com/what-is-pki/
Security for wireless instrumentation: keeping wireless field device communications
secure: Protocols for wireless instrumentation and other field devices use
encryption as a key security element. Is it enough?. (2015). Control Engineering,
(8), 22.
Understanding Health Information Privacy. (n.d.). Retrieved November 7, 2015, from
http://www.hhs.gov/ocr/privacy/hipaa/understanding/summary/index.html
U.S. Department of Health & Human Services. (n.d.). Summary of the HIPAA Privacy
Rule. Retrieved from
http://www.hhs.gov/ocr/privacy/hipaa/understanding/summary
VeraCode. (2015). Cross-Site Scripting (XSS) Tutorial: Learn About XSS
Vulnerabilities, Injections and How to Prevent Attacks. VeraCode. Retrieved
from http://www.veracode.com/security/xss
VeraCode. (2015). SQL Injection Cheat Sheet & Tutorial: Vulnerabilities & How to
Prevent SQL Injection Attacks. VeraCode. Retrieved from
http://www.veracode.com/security/sql-injection