HIT Policy CommitteePrivacy and Security Tiger Team
Deven McGraw, Chair
Paul Egerman, Co-Chair
User Authentication Considerations
March 2, 2011
Objective of Discussion
2
• 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
What is Authentication?
3
Something you knowSomething you have
Something unique to you
IDENTITY
Who am I?
IDENTIFIERS
How is that identity
represented?
AUTHENTICATION
How can I prove who I am?
AUTHORIZATION
What can I do when I've proved
who I am?
Ongoing monitoring, auditing, and enforcement
Authentication Definitions
4
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.
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
5
The HIPAA Security Rule requires implementation of three types of safeguards: 1) administrative, 2) physical and 3) technical
The Security Rule requires:
• 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
The Security Rule does not:
• Mandate a specific implementation framework
• Specify authentication options, assurance levels and verification types
6
Overview of the HIPAA Security Rule: Authentication
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)
7
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 8
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
9
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
10
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
11
Additional Question
• Should the Tiger Team recommendation for remote users also apply to enterprise (in-house) users?
12
Previous Tiger Team Recommendation
13
Previous Tiger Team Recommendation
= Healthcare User
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)
Individual Users of EHR Systems
• Users that are physically at a healthcare organization and access services across a healthcare organization network
BACKUP SLIDES
14
What PCAST Says About Authentication
15
• Except for patient-consumers, all of the users within the health IT system can be authenticated using
1. physical credentials (such as smartcards),
2. biometrics (such as fingerprints), and a
3. secret (such as a password).
• “Two-factor authentication” is a possible design choice
“pcast-health-it-report.pdf,” 2010, http://www.whitehouse.gov/sites/default/files/microsites/ostp/pcast-health-it-report.pdf
Background: Authentication and OMB
16
• 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
Requirements Area
Level 1 Level 2 Level 3 Level 4
Level MajorCharacteristics
Little or no confidence in the asserted identity’s validity
Some confidence in the asserted identity’s validity
High confidence in the asserted identity’s validity
Provides highest practical remote network authentication assurance
Authentication Token
None Single-factor Multi-factor Multi-factor; requires hard cryptographic token
Components for identity proofing
Confirmation of address, telephone number, or email address of applicant
Confirmation of address or telephone number in records with voice recording
In-person presentation of two identifying documents with confirmation; fingerprint or photo taken
Background: NIST E-Authentication Guidelines SP 800-63
17
Note: Other security frameworks have been developed and have been used in the private sector
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) 18
Considerations: Remote Use
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
19
Considerations: Remote Use
We propose that this discussion focus on the authentication of users who remotely access electronic health information via external networks
Considerations: Remote Use
20
• 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
Considerations: Password Authentication
21
• 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
Definitions
22
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.
Considerations When Applying the HIPAA Security Rule
23
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.
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
24
Process Step Implementation Requirements
Identity ProofingThe process of verifying an applicant’s identity prior to credentialing
In-person verification shall be required in front of a designated registration authority with authorization by a designated organizational official.
Require verifiable unique ID's for all types of users
Authentication TokenTechnical components used to electronically prove one’s identity
Ensure password quality and complexity.
Strong authentication methods alternative to passwords, such as cryptographic means, smart cards, tokens or biometric means, shall be used.
Sensitive authentication data shall not be stored after authorization (even if encrypted).
Map the authenticated identity to the user account.