HIT Policy Committee Privacy and Security Tiger Team

1. HIT Policy CommitteePrivacy and Security Tiger Team Deven McGraw, Chair Paul Egerman, Co-Chair User Authentication Considerations March 2, 2011

2. Objective of Discussion • To determine whether the Tiger Team should recommend specific policies regarding the authentication of users (providers and staff within a provider) accessing identifiable electronic health information • Initially looking at following use case: people gaining access to EHRs across a network such as the Internet, possibly with mobile devices • Also reconsidering whether any such recommendations would also apply to users internal to an enterprise • Topic of authentication of patients seeking to access an EHR (such as through a portal) is reserved for a separate discussion

3. What is Authentication? Who am I? How is that identity represented? How can I prove who I am? What can I do when I've proved who I am? IDENTITY IDENTIFIERS AUTHENTICATION AUTHORIZATION Something you know Something you have Something unique to you Ongoing monitoring, auditing, and enforcement

4. Authentication Definitions Authentication is verification that a person or entity seeking access to electronic protected health information is the one claimed A Token is something that a user possesses and controls that is used to authenticate his/her identity • Typically a secret password • Other tokens may include physical credentials such as SecureID keys or biometrics Two-Factor Authentication is a form of authentication that requires the claimant to prove possession of two tokens, e.g., a password and a biometric.

5. Assumptions • Provider entity has issued EHR credentials • Entity is following HIPAA Security Rule (has put in place administrative, technical and physical safeguards) • Authorization is a critical part of an overall security plan but it should never be the sole measure of security

6. Overview of the HIPAA Security Rule: Authentication The HIPAA Security Rule requires implementation of three types of safeguards: 1) administrative, 2) physical and 3) technical The Security Rule requires: The Security Rule does not: Mandate a specific implementation framework Specify authentication options, assurance levels and verification types • Protecting against any reasonably anticipated uses or disclosures of electronic Protected Health Information (ePHI) not permitted or required under the Privacy Rule • Implementing procedures to verify that a person or entity seeking access to ePHI is the one claimed

7. NIST E-Authentication Levels of Assurance (SP 800-63) • E-Authentication includes a tool to select an appropriate level of assurance based on impacts due to authentication errors • Levels of Assurance are suitable to different portions of the user community • Level 1 aligned with the general public (e.g., Facebook, Yahoo! Email) • Level 2 aligned with the general public, but with motivation (e.g. PayPal, 401k) • Level 3 aligned with affiliated access (e.g. Patent Examiners, Census Workers) • Level 4 aligned with employee access (e.g. Data Center operations)

8. DEA Electronic Prescription Authentication* • Modeled after SP 800-63 (Draft) with adaptation – level 3 • Requires two-factor authentication chosen from: • Hard token • Cryptographic token • One time password token • Must be validated at FIPS 140-2 Level 1 • Knowledge token (password) • Biometric • Differs from 800-63 where direct use of biometrics is not considered a factor • Stringent identity proofing requirements • e.g., requires use of federally approved credential service providers (CSPs) or certification authorities (Cas) *Details: Federal Register, March 31, 2010

9. Previous Tiger Team Discussions • In general, Tiger Team felt that remote access raised heightened security risks for access to identifiable health information • Looking to NIST assurance levels (SP 800-63), Team felt that a minimum of Level 3 assurance made sense in this context • Achieving Level 3 means that there is a high degree of confidence that a claimant in an authentication process is actually who they claim to be

10. Previous Tiger Team Discussions (cont.) • Tiger Team generally felt that more than log-in and password should be required for this use case – i.e., two- or multi-factor • Consistent with NIST guidance for Level 3 • However, no consensus yet on a specific baseline requirement re: factors – seeking Policy Committee input

11. Questions Raised • Should 2-factor authentication of remote EHR users be required? If so, should we specify the types of factors to be considered? • Endorse DEA approach for other access use cases? • Use approach similar to that used by banks? (more than log-in and password but second factor can also be knowledge-based) • Or begin with this as a baseline and study impact of DEA requirement to see if standard can be increased in future • Is single factor authentication adequate in combination with a rigorous password management program? • Allow log-in and password to suffice, as long as password is required to be strong • Should one size fit all – or should baseline requirements vary by level of risk of access? • E.g., issue guidance and best practices that accommodate different use cases, resource differences

12. Additional Question • Should the Tiger Team recommendation for remote users also apply to enterprise (in-house) users?

13. Previous Tiger Team Recommendation Previous Tiger Team Recommendation • Individual Users of EHR Systems • Users that are physically at a healthcare organization and access services across a healthcare organization network The Tiger Team previously commented on individual users… With respect to individual users, provider entities and organizations must develop and implement policies to identity proof and authenticate their individual users (already required under HIPAA Security Rule) = Healthcare User

14. Backup Slides

15. What PCAST Says About Authentication “pcast-health-it-report.pdf,” 2010, http://www.whitehouse.gov/sites/default/files/microsites/ostp/pcast-health-it-report.pdf • Except for patient-consumers, all of the users within the health IT system can be authenticated using • physical credentials (such as smartcards), • biometrics (such as fingerprints), and a • secret (such as a password). • “Two-factor authentication” is a possible design choice

16. Background: Authentication and OMB • In addition to using the NIST checklist for protection of remote access, OMB recommends all departments and agencies take the following actions in regards to authentication: • Allow remote access only with two-factor authentication • one of the factors is provided by a device separate from the computer gaining access • Use a “time-out” function for remote access and mobile devices requiring user re-authentication after 30 minutes inactivity “m06-16.pdf,” 2006, http://www.whitehouse.gov/sites/default/files/omb/memoranda/fy2006/m06-16.pdf

17. Background: NIST E-Authentication Guidelines SP 800-63 Note: Other security frameworks have been developed and have been used in the private sector

18. Reaching Level 3 – Factors from 800-63 Draft • Knowledge Tokens • Memorized Secret Token (password) • Pre-registered Knowledge Token (favorite ice cream flavor) • Look-up Secret Token (card with number in cells) • Out of Band Token (text message to cell phone) • Hard Tokens • Single Factor (SF) One Time Password (OTP) Device (SecureID fob) • Multi Factor (MF) OTP Device (OTP w/biometric unlock mechanism) • SF Cryptographic Device (FIPS verified crypto software) • MF Software Cryptographic Token (crypto software activated by password or biometric) • MF Cryptographic Device (crypto device activated by password or biometric) • The computer being used is not by itself a factor • A biometric adds to the factor count when activating a device but not when used directly (different from DEA rule)

19. Considerations: Remote Use Considerations: Remote Use We propose that this discussion focus on the authentication of users who remotely access electronic health information via external networks • Remote Use Description: Users typically gain access by one of these three methods: • VPN: remote user can access home base network use with minimal restrictions • Web Server: remote user has access to web application; all internal access is mediated by servers • Proxy: remote user has access to some internal network services; all internal access is mediated by servers

20. Considerations: Remote Use • Authenticating users who are remote introduces additional potential vulnerabilities beyond the “base case” • User credentials and tokens have to travel from the remote location across the Internet to one or more IT systems • The user’s computer, for example a laptop, might not have the same electronic security controls or the internet may not be as secure as at the clinic or hospital • The controls limiting physical access to the computer are likely much stronger at the hospital or clinic than in a home or other remote location

21. Considerations: Password Authentication • Use of passwords for authentication may or may not be inherently weak – strength comes with policies that address password strength (length and composition) and the total number of times a password is used • A standard suggestion to overcome the perceived weaknesses of password use, particularly remote password use, is to use a second “factor” in authentication • Adding a second factor to authentication can be an inexpensive and easy way to boost authentication strength • Adding a second factor to authentication can also be viewed as inconvenient, so it use should probably be limited to those situations where additional authentication protection is actually needed

22. Definitions Authentication is verification that a person or entity seeking access to electronic protected health information is the one claimed. Level of assurance is the degree of confidence in the results of an authentication attempt. A Token is something that the claimant possesses and controls (typically a key or password) used to authenticate the claimant’s identity. Two-Factor Authentication is a form of authentication that requires the claimant to prove possession of two tokens, e.g., a password and a biometric. Remote Access refers to users (or information systems) communicating external to an information system security perimeter, e.g., the network perimeter of a health care organization. A Virtual Private Network is a logical network that is established over a physical network that can selectively exclude entities with access to the physical network.

23. Considerations When Applying the HIPAA Security Rule Excerpt from National Institute of Standards and Technology (NIST) Special Publications 800-66: An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule Note: as a practical matter these Standards may be implemented almost entirely by the software package(s) that a Provider uses.

24. HITRUST Alliance Common Security Framework: Authentication Guidelines • The Common Security Framework (CSF) incorporates the requirements of applicable standards and regulations including ISO, PCI, COBIT, HIPAA, HITECH, and NIST