1
Towards Improved Security Criteria for Certification of Electronic Health Record
SystemsAndrew Austin
Ben SmithLaurie Williams
North Carolina State University
2
Motivation
• American Recovery & Reinvestment Act• Penalties if not using EHR system by 2015
– 2015: 1% 2016: 2% 2017 & beyond: 3%
• Short term financial incentives to providers for Electronic Health Record (EHR) usage– Up to $44,000
• EHR systems must be certified to receive financial incentives.
CCHIT
• Certification Commission for Health Information Technology (CCHIT)
• Existing EHR Certification Body (2004)• Over 200 CCHIT Certified EMRs• Certifies functionality, interoperability, security
• 286 Total Criteria• Sets minimum bar with functional requirements• Primarily focused on functionality and
interoperability
3
CCHIT Security Criteria
• Security Criteria & Test Scripts• Test security features such as encryption &
password storage• 46 Security Criteria• 60 Test Scripts• 52 "self-attestation” tests
– Provide supporting documentation for compliance
4
CCHIT Security Criteria Example
• SC 06.02 - When passwords are used, the system shall not display passwords while being entered.
• SC 03.07 - The system shall provide only limited feedback information to the
user during the authentication.
5
CCHIT Test Script Example
6
CCHIT Test Script Example
7
Procedure Expected Result Actual Result Criteria & ReferenceVerify that the login procedure did not show the password in readable form
Password was not displayed during entry. If SC 06.02 is assigned, see step 7.10. If SC 03.07 is assigned, see step 7.08.
SC 06.02 - When passwords are used, the system shall not display passwords while being entered.
SC 03.07 - The system shall provide only limited feedback information to the user during the authentication.
8
Objective
The goal of our research is to examine the security criteria in certification standards, such as those provided by CCHIT, by evaluating the security of an open source electronic health record system.
Case Study on OpenEMR
http://www.oemr.org
9
Language PHP
Version Evaluated 3.1.0 (8/28/2009)
Lines of Code (counted by CLOC1.0810)
277,702
Developers Contributed 17
Companies Providing Support
11
Average Monthly Downloads 1168
Working towards CCHIT certification
Process
1. Static Analysis with Fortify 360 v5.72. Automated Penetration Testing with IBM
Rational AppScan v7.83. Identified False Positives4. Examined Results5. Compared to CCHIT Criteria
10
Static Analysis Results
Summary
11
Total Alerts 1210
True Positives 440
False Positives 770
False Positive Rate 63.64%
Static Analysis Results
Common True Positives
12
Cross Site Scripting 215
Nonexistent Access Control
129
Dangerous Function 24
Path Manipulation 20
Error Information Leak 19
Automated Penetration Testing
Summary
13
Total Alerts 140
True Positives 130*
False Positives 10
False Positive Rate 7.14%
* 61 of these true positives were also found by Fortify 360.
Automated Penetration Testing
Common True Positives
14
Cross Site Scripting 50
Phishing Through Frames 25
Cross Site Request Forgery
22
Error Information Leak 14
SQL Injection 4
15
Discussion
• All the issues found were implementation bugs.
• These implementation bugs are all behaviors the system should NOT allow.
• Functional requirements have a hard time elaborating on functionality not allowed.
16
Limitations• Misclassification of false positives by
research team.• Issues found were reported by tools, we did
not actually conduct the attacks ourselves.• Our case study is not comprehensive, there
could be many more vulnerabilities.
17
Conclusions• Testing for security features is not enough.• Whole classes of security issues are not
caught by CCHIT criteria.• CCHIT criteria should be augmented with
additional criteria and test cases to better address the implementation bugs we’ve found.
18
Questions?
19
Misuse Cases
Misuse cases specify "negative" use cases, that is: behavior that is not wanted in the proposed system.– Model attack patterns, and double as test cases– Force you to ask questions such as
• "Who should have access to a patient's records?”• "What parts of a doctor's personal information
should be available to patients?”– Aid in the creation of specific and testable
security requirements
20
Misuse Case ExampleVulnerability Found: Lack of access control on
a patient’s demographics.
Misuse Case Summary: A patient attempts to modify another patient’s demographics that he or she is not authorized to view or edit.
Resulting Security Requirement: Pages displaying patient demographic information should contain a user-specific secret, created at runtime, to prevent unauthorized access.
Top Related