Upload
anurag-deb
View
190
Download
0
Tags:
Embed Size (px)
DESCRIPTION
The Electronic Health Record (EHR) is a longitudinal electronic record of patient health information generated by one or more encounters in any care delivery setting. Included in this information are patient demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data, and radiology reports. The EHR automates and streamlines the clinician's workflow. The EHR has the ability to generate a complete record of a clinical patient encounter, as well as supporting other care-related activities directly or indirectly via interface including evidence-based decision support, quality management, and outcomes reporting.
Citation preview
Electronic Health Records
Introduction
The Electronic Health Record (EHR) is a longitudinal electronic record of patient health
information generated by one or more encounters in any care delivery setting. Included in this
information are patient demographics, progress notes, problems, medications, vital signs, past
medical history, immunizations, laboratory data, and radiology reports. The EHR automates and
streamlines the clinician's workflow. The EHR has the ability to generate a complete record of a
clinical patient encounter, as well as supporting other care-related activities directly or indirectly
via interface including evidence-based decision support, quality management, and outcomes
reporting.
EHR is generated and maintained within an institution, such as a hospital, integrated delivery
network, clinic, or physician office.
Advantages of EHR
Tools for Quality Improvement
Greater Efficiency
Tools to Monitor Population Health
Tools to Monitor Privacy & Security
Since EHR contains important patient records the security of EHR systems is a major concern.
If EHR systems are not secure, patients may get improper health care or have life-shattering or
embarrassing information exposed due to privacy breaches.
The Nationwide Health Information Network (NHIN) is being developed to provide a secure,
nationwide, interoperable health information infrastructure that will connect providers,
consumers, and others involved in supporting health and healthcare.
Goals of NHIN
Developing capabilities for standards-based, secure data exchange nationwide.
Improving the coordination of care information among hospitals, laboratories, physicians
offices, pharmacies, and other providers.
Ensuring appropriate information is available at the time and place of care.
Ensuring that consumers’ health information is secure and confidential.
Giving consumers new capabilities for managing and controlling their personal health
records as well as providing access to their health information from electronic health
records (EHRs) and other sources.
Reducing risks from medical errors and supporting the delivery of appropriate, evidence-
based medical care.
Lowering healthcare costs resulting from inefficiencies, medical errors, and incomplete
patient information.
The American and Reinvestment Act of 2009(ARRA) provides $34 billion of incentives to heath
care providers to deploy EHRs that are certified for meaningful use.
Certification of EHRs began in 2006, conducted primarily by the Certification Commission of
Healthcare IT (CCHIT). The CCHIT Certified program is an independently developed
certification that includes a rigorous inspection of an EHR’s integrated functionality,
interoperability and security using criteria developed by CCHIT’s broadly representative, expert
work groups.
EHR systems contain many assets that are just as valuable to attackers as they are to health care
providers including patient’s health records, the service the EHR system provides, patient
identity, billing information and the audit trail of the transactions that have occurred in the
system.
The goal is to improve the security assessment within EHR system certification processes by
empirically accessing the ability of current security certification criteria to surface a range of
vulnerability types.
This paper performed exploratory security analysis on to web based EHR systems that are
seeking CCHIT certification: OpenEMR, an Open source EHR system and proprietaryMed, a
proprietary EHR system.
The next chapter provides requisite background information on CCHIT, misuse cases and insider
threats.
Relationship to Other Domains
American’s financial institution have recognized the impact of information security threats and,
in lieu of “security checklist” certification, recommend that banks who develop applications
in- house should follow an enterprise-wide effort that incorporates attack models and systematic
application testing.
A similar problem exists in voting machine. Voting machine have no quality control in the
development of their source code, resulting in exploits such as impersonating legitimate voting
terminals and linking voters with their votes.
In the realm of healthcare, many security analysts have studied the security of implantable
pacemakers, and discovered that their wireless communication protocols can be
reverse-engineered and manipulated by someone other than patient’s doctor.
Insider Attacks
An insider attack occurs when employees of an organization with legitimate access to their
organization information systems use these systems to sabotage their organization IT
infrastructure or commit fraud.
Researchers at the Software Engineering Institute at Carnegie Mellon released a comprehensive
study on insider threats that reviewed 49 cases of Insider IT Sabotage between 1996 and 2002. [1]
According to the study:
90% of insider attackers were given administrative or high level privileges to the target
system.
81% of the incidents involved losses to the organization, with dollar amounts estimated
between “five hundred dollars” and “tens of millions of dollars.”
The majority of attackers attacked after they were terminated from the organization.
Lack of access controls facilitated IT sabotage.
Attackers created or used access paths unknown to management to set up their attacks
and conceal their identities.
Use Cases vs. Misuse Cases
Both use cases and misuse cases can be used for software security requirements. A use case is a
“description of the possible sequences of interactions between the system under discussion and
its external actors, related to a particular goal”.
Use cases can be helpful to express functional security, such as the ability to change a user’s
password or the requirement that passwords should be stored using the most up-to-date
cryptographic techniques.
A misuse case specifies a “negative” use case, that is: behavior that is not allowed in the
proposed system.
Like a misuse case might read: “An attacker spoofs another user’s identity” or “An attacker
causes a denial of service by rending the homepage to be blank for all future users,” or “An
attacker executes applications on the client’s computer.” Only misuse cases can specify the
functionality that system should not have.
Software security testing involves creating a plan of attack and attempting to expose
vulnerabilities in software by forcing the system to do what is not allowed by the specification or
requirements. [1]
Certification of EHR Systems
The Office of the National Coordinator for Health Information Technology (ONC) maintains the
standards that certifying bodies must use in evaluating EHR systems. This section presents
information on the leading certification body, CCHIT. Next, we describe the conformance test
methods being developed by NIST in concert with the ONC.
CCHIT Criteria
CCHIT (Certification Commission for Health Information Technology) certified an
independently developed certification that includes a rigorous inspection of an EHR’s integrated
functionality, interoperability and security. Products that are CCHIT Certified are tested against
criteria developed by the Commission’s broadly representative, expert work groups. This
program is intended to serve health care providers looking for greater assurance that a product
will meet their complex needs. As part of this independent evaluation, successful use is verified
at live sites and product usability is rated.
Goals of CCHIT:
Reduce the risk of Healthcare Information Technology (HIT) investment by physicians
and other providers.
Ensure interoperability (compatibility) of HIT products.
Assure payers and purchasers providing incentives for electronic health records (EHR)
adoption that the ROI (Return on Investment) will be improved quality.
Protect the privacy of patients' personal health information.
NIST Meaningful Use Test Methods
NIST Certifications has to do with "verifying that a specific piece of equipment does what it's
supposed to do within the specifications documented by the manufacturer". N.I.S.T. stands for
the "National Institute of Standards and Technology" located in Boulder, CO. This NIST
Certification is acknowledged in many different ways. Other names for NIST Certification
maybe Certificate of Calibration, Traceable Calibration, Certificate of Traceability, etc.
The NIST security criteria are similar to the CCHIT security criteria in that they focus on
functional security aspects such as passwords and hashing. The NIST test scripts, however,
contain a few test scripts that assess whether the EHR system properly enforces its authorization
specifications. The NIST test procedures state that a tester should try to authenticate with a
deleted account and that the authentication attempt should fail. [1]
EHR System Attacker Motivation
An analysis of software system security must consider the motivation of possible attackers. EHR
applications have valuable assets, such as the following:
Health Records, protected by Health Insurance Portability and Accountability Act
(HIPAA, protects health insurance coverage for workers and their families when they change or
lose their jobs), Privacy and Security rules, contain personal and sensitive information
about what procedures and tests a patient has had, as well as diagnoses that a patient has
received from doctors. For example, some medical diagnoses are stigmatized, like a
sexually transmitted disease diagnoses. Other information can be life threatening, such as
allergies. Insurance companies as well as employers are interested in knowing a patient’s
health record to make unethical decisions about whether to cover a patient or whether to
hire a patient, respectively.
The Service provided by the software system is invaluable to the medical practice that
deploys it. Without a working health record system (as in the case of soft denial of
service), a medical practice can be rendered non functional, since much of medicine is
based on prior history. Further, not being able to access a patient health records could
cause serious threats to patient safety.
Identity and Billing Information, including credit card numbers, social security
numbers, home addresses and telephone numbers, make for attractive targets for any
attacker wishing to steal patient’s identities or commit credit card fraud.
The Authenticity and Audit Trail (or repudiation) of the data contained within the health
record system is essential. Just as with the service the system provides by itself, doctors and
healthcare practitioners depend on the accuracy and availability of the data to make critical
decision about patient care. If a patient has an incorrect listing or no listing of a certain allergy
due to a malicious attack, that patient could die by being given the wrong prescription. Further,
patients and doctors alike could forge health records with no chance of getting caught. For
example, a patient would be motivated to alter the record of a disease or doctor's visit to get
worker's compensation or to get access to narcotics. A doctor could retroactively create the
record of the completion of a certain medical procedure to exonerate his or herself from a
medical malpractice charge.
Firebug
Firebug is a web development plug-in for the Mozilla Firefox browser that allows the debugging,
editing, and monitoring of any website's CSS, HTML, DOM, and JavaScript, and provides other
Web development tools. It also allows the tracking and analysis of HTTP traffic. It is a tool that
is used for web security testing and for web site performance analysis. Here, Firebug is used for
examining hidden control fields within web pages and monitoring the progress and status of
various attacks. In addition, it contains a JavaScript debugging utility that executes any script
live that the user enters into the console. This functionality made Firebug a solid choice to add to
our attack arsenal because we could more quickly and easily manipulate HTML components and
test JavaScript attacks without having to compose additional web pages to hold those attacks or
store those attacks on our test servers.
WebScarab
WebScarab is designed to expose the workings of an HTTP(S) based application, whether to
allow the developer to debug or to allow a security specialist to identify vulnerabilities.
WebScarab is a portable framework written in Java for analyzing applications for the
information security that communicate using the HTTP and HTTPS protocols. In its simplest
form, WebScarab records the conversations (requests and responses) that it observes, and allows
the operator to review the conversations (requests and responses) that have passed through
WebScarab. WebScarab is based on a plug-in architecture; Where WebScarab has several modes
of operation, implemented by a number of plug-ins.
Here, the paper configured the browsers to use WebScarab as an HTTP proxy, which allowed
WebScarab to monitor and store any traffic between the computers and the test servers that ran
the target application. In its basic mode of functionality, WebScarab records and then forwards
any HTTP requests and responses that come to and from any browser that is configured to use
WebScarab as a proxy.
Many modern web applications use the POST method for HTTP requests; meaning parameters
that are passed through the URL are ignored. For example, in the request:
http://localhost/script.php?test=abc
The POST parameter test is empty, where as the GET parameter test contains the string abc.
If the web application is using GET parameters to receive user input, then an attacker need only
modify the URL to change the value of the parameter test. However, in a POST request, the
parameter is not included in the URL, and is only accessible from an HTML form or by
examining the HTTP request that is sent to the server.
Both of our targeted applications used JavaScript to disallow certain characters to be input into a
certain field on various form fields, a technique known as Client side filtering.
Attack Environment
Figure1. Detailed Diagram of Network Setup
The above figure shows the detailed view of our testing network setup. Here they deployed
OpenEMR on a Linux server running Ubuntu v8.04.4 and Apache v2.2.8 with 800MB of RAM
and an Intel Premium4 2.40GHz processor. Each team member used WebScarab as a proxy and
Firebug as a JavaScript debugger. They also used a separate server to host various attack scripts
to make them generally accessible to the team. The additional server simplified the process of
saving user’s session cookies. The additional server was hosted on a Linux machine running
Ubuntu v9.10 and Apache v2.2.12 with 512MB of RAM and an Intel Celeron 2.40GHz
processor.
OpenEMR
OpenEMR is an open source EHR web application written in PHP and licensed under the GNU
General Public License (GPL). OpenEMR is actively pursuing CCHIT certification. OpenEMR
is supported and maintained by Open Source Medical Software (OSMS), which is an
all-volunteer medical organization committed to the development of open source EHR
applications can provide equal technological access to people who are typically considered to be
at a socioeconomic disadvantage.
OpenEMR has five user roles:
Accounting
Administrator
Clinician
Front Office
Physician
ProprietaryMed
ProprietaryMed is a web-based EHR created for use in primary care practices. ProprietaryMed
uses the Microsoft ASP.NET15 with JavaScript on the front end.
PropreitaryMed is closed-source, is a paid product, and uses a different architecture of
frameworks than does OpenEMR. Additionally, ProprietaryMed has an install base of 14
physician practices, 17 physicians, and about 80 clinical and non-clinical staff. The practices are
maintaining the electronic health records of over 21,000 patients.
It allows eight distinct user roles:
Medical Assistant,
Practice Administrator
Lab Technician
Doctor
Profile Setup
Office Manager
Nurse Practitioner and
Physician's Assistant.
Successful Exploits
Each of the exploits described here falls into one of two groups :
Implementation bugs
design flaws
Implementation bugs are code-level software problems, such as cross-site scripting.
Design flaws are high-level problems associated with the architecture and design of the
system, such as allowing an administrator to view every user's records.
In the next section, we present seven types discovered implementation bugs.
Implementation Bugs
Implementation bugs are code-level security problems. In the following situations, the
EHRs we examined did not fulfill certain security goals that pertain to keeping patient
records confidential or ensuring the availability of the system.
Cross-Site Scripting
It’s a computer security vulnerability that enables malicious attackers to inject client side
script into web-page viewed by other users.
Phishing
It is an attempt to acquire sensitive information such as user names, passwords etc. by
masking as a trustworthy entity.
SQL Injections
SQL injection is a technique often used to attack a website. This is done by including
portions of SQL statements in a web form entry field in an attempt to get the website to
pass a newly formed rogue SQL command to the database (e.g., dump the database
contents to the attacker).
SQL injection is a code injection technique that exploits security vulnerability in a
website's software. The vulnerability happens when user input is either incorrectly
filtered for string literal escape characters embedded in SQL statements or user input is
not strongly typed and unexpectedly executed. SQL commands are thus injected from
the web form into the database of an application (like queries) to change the database
content or dump the database information like credit card or passwords to the attacker.
SQL injection is mostly known as an attack vector for websites but can be used to attack
any type of SQL database.
Misuse case(s): An Attacker obtains every user's username and password.
Violates CCHIT Criteria: SC 06.12 – The system shall verify that a person or entity
seeking access to electronic health information across a network is the one claimed and is
authorized to access such information.
Exposed by CCHIT Test Script: None.
Vulnerable Application(s): OpenEMR.
When an attacker exploits a lack of input validation to force unintended system behavior
by inserting reserved words or characters into input fields that alter the logical structure
of a SQL statement is known SQL Injection attack.
Conclusion
In this paper a representative set of implementation bugs and design flaws are exploited that
could lead to critical consequences to patient privacy. The paper discusses about the two
major weaknesses of CCHIT certification process. The first is that the CCHIT test script fail
to test for the existence of implementation bugs or security issues that deal with the way the
system achieves security requirements.
Bibliography
1) Research paper from ACM portal
2) http://www.ncrr.nih.gov/publications/informatics/ehr.pdf
3) http://www.hhs.gov/health/healthnetwork/background/
4) Wikipedia.
5) http://mhcc.maryland.gov/electronichealth/mhitr/EHR%20Links/challenges_to_ehr.pdf
6) www.drivencompany.com/nist.cfm
7) http://go4webapps.com/2010/04/24/webscarab-web-security-application-testing-tool/