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.