1. 1 Towards Improved Security Criteria for Certification of Electronic Health Record Systems Andrew Austin Ben Smith Laurie Williams North Carolina State University

2. 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.

3. 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

4. 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

5. 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

6. CCHIT Test Script Example 6

7. 7 ProcedureExpected ResultActual ResultCriteria & Reference Verify 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. 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.

9. Case Study on OpenEMR http://www.oemr.org 9 LanguagePHP Version Evaluated3.1.0 (8/28/2009) Lines of Code (counted by CLOC1.0810) 277,702 Developers Contributed17 Companies Providing Support 11 Average Monthly Downloads1168 Working towards CCHIT certification

10. Process 1.Static Analysis with Fortify 360 v5.7 2.Automated Penetration Testing with IBM Rational AppScan v7.8 3.Identified False Positives 4.Examined Results 5.Compared to CCHIT Criteria 10

11. Static Analysis Results Summary 11 Total Alerts1210 True Positives440 False Positives770 False Positive Rate63.64%

12. Static Analysis Results Common True Positives 12 Cross Site Scripting215 Nonexistent Access Control 129 Dangerous Function24 Path Manipulation20 Error Information Leak19

13. Automated Penetration Testing Summary 13 Total Alerts140 True Positives130* False Positives10 False Positive Rate7.14% * 61 of these true positives were also found by Fortify 360.

14. Automated Penetration Testing Common True Positives 14 Cross Site Scripting50 Phishing Through Frames25 Cross Site Request Forgery 22 Error Information Leak14 SQL Injection4

15. 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. 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. 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. 18 Questions?

19. 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. 20 Misuse Case Example Vulnerability 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.