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.