1 Challenges for Protecting the Privacy of Health Information: Required Certification Can Leave Common Vulnerabilities Undetected Ben Smith, Andrew Austin, Matt Brown, Jason King, Jerrod Lankford, Andrew Meneely, Laurie Williams

2

Risks and Assets Medical Records –STDs, psych history, anti-depressants Service –Inaccessibility can mean patient death Identity and Financial Information –What’s in your wallet? Authenticity and Audit Trail –Doctor fakes a test result, Insider Threats Legal Fees –Lawsuits cost more than a good EHR 3

Research Questions How do market-ready EHRs perform in an attack scenario? What can attackers achieve by exploiting security weaknesses in existing EHRs? EHR: Electronic Health Record System 4

Agenda Method EHR Certification Processes Results –Implementation Bugs –Design Flaws Recommendations 5

EHR Certification Dominant certification bodies in the US (approved by ONC): –Certification Commission for Healthcare Information Technology (CCHIT) –National Institute of Standards and Technology (NIST). CCHIT Criteria –286 Functional Criteria, 213 Test Scripts (manual) –46 Security Criteria, 112 Test Scripts. –Security consists of encryption, hashing, passwords. 6

EHR Certification (2) NIST Criteria –Similar to CCHIT certification –36 Test Scripts –Security test scripts focus on passwords and hashing. –One exception: VE t-1.05: “The tester shall perform an action not authorized by the assigned permissions.” 7

Method Created attack team from the first six authors Worked in a distributed fashion Held meetings to attack in parallel Used knowledge of software security Two test servers, one for each EHR: contained demo data (no broken laws) One auxiliary server to assist in attacks 8

Method: Target EHRs OpenEMRProprietaryMed LicenseGPLProprietary Popularity1168 downloads/mo21,000 patient records Size (SLOC/Files)305,000 / 1,600120,000 / 900 Version3.2 (2/16/2010)1.0 (3/31/2010) Contributing Developers1812 PlatformPHPASP.NET 9

Security Issue Categories Gary McGraw: Building Security In Implementation Bugs –Not indicated in design –Developer mistake –Code-level Design Flaws –Happened at the design stage –High-level functionality that is risky –Functionality itself is vulnerable 10

OpenEMR: SQL Injection 11

Both EHRs: Cross-site Scripting 12

Design Flaws In OpenEMR, the administrator can read or change another user’s password. In ProprietaryMed, there is no logging of any transaction. In ProprietaryMed, there is no authorization control on patient records. 13

OpenEMR: phpMyAdmin 14

Summary CCHIT and NIST would be ineffective and detecting any of the exploits or design flaws demonstrated in this paper. Security is a crucial aspect of healthcare IT due to HIPAA, and the cost of exploits. Passwords, hashing, encryption are important, but is insufficient! 15

Recommendations Uncover implementation bugs by executing attacks from a list such as CWE/SANS Top 25, simulate attacker behavior. Execute attacks on every component of the system, get some sense of coverage. Examine design flaws as well as implementation bugs. 16

Security as Entry Criteria Currently, docs see “certified” and they assume EHR is secure. Certification is not the best way to ensure the security of a system (security by checklist) Regardless, security testing should be conducted before and as a prerequisite to functional testing for EHRs. 17

Thank you! Any questions? Healthcare Wiki: 18