Towards Improved Security Criteria for Certification of Electronic Health Record Systems

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

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

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. CCHIT Test Script Example 7

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

9. Case Study on OpenEMR http://www.oemr.org • Working towards CCHIT certification 9

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

11. Static Analysis Results Summary 11

12. Static Analysis Results Common True Positives 12

13. Automated Penetration Testing Summary * 61 of these true positives were also found by Fortify 360. 13

14. Automated Penetration Testing Common True Positives 14

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

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

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

18. Questions? 18

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 19

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