User Authentication for by liamei12345


									HIT Policy Committee
Privacy and Security Tiger Team

Deven McGraw, Chair
Paul Egerman, Co-Chair

User Authentication Considerations
March 2, 2011
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
   – 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
What is Authentication?

 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

Two-Factor Authentication is a form of authentication that requires the
  claimant to prove possession of two tokens, e.g., a password and a


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

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:
• Protecting against any             • Mandate a specific
  reasonably anticipated uses or       implementation framework
  disclosures of electronic
                                     • Specify authentication options,
  Protected Health Information
                                       assurance levels and
  (ePHI) not permitted or required
                                       verification types
  under the Privacy Rule
• Implementing procedures to
  verify that a person or entity
  seeking access to ePHI is the
  one claimed
    NIST E-Authentication Levels of Assurance (SP
•   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
       –    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)
    Potential Impact Categories for        Assurance Level    Assurance Level    Assurance Level    Assurance Level
    Authentication Errors                  Impact Profile 1   Impact Profile 2   Impact Profile 3   Impact Profile 4
    Inconvenience, distress or damage to   Low                Mod                Mod                High
    standing or reputation
    Financial loss or agency liability     Low                Mod                Mod                High

    Harm to agency programs or public      N/A                Low                Mod                High
    Unauthorized release of sensitive      N/A                Low                Mod                High
    Personal Safety                        N/A                N/A                Low                Mod
    Civil or criminal violations           N/A                Low                Mod                High
DEA Electronic Prescription Authentication*

• Modeled after SP 800-63 (Draft) with adaptation – level
• 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

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

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
• 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

Additional Question

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

Previous Tiger Team Recommendation
                                     Individual Users of EHR Systems
                                      •   Users that are physically at a
                                          healthcare organization and access
The Tiger Team previously
                                          services across a healthcare
commented on individual users…            organization network

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)


What PCAST Says About Authentication

• 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,
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
        – 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

“m06-16.pdf,” 2006,   16
 Background: NIST E-Authentication Guidelines SP
Requirements          Level 1                 Level 2               Level 3               Level 4
Level Major       Little or no          Some confidence in     High confidence in    Provides highest
Characteristics   confidence in         the asserted           the asserted          practical remote
                  the asserted          identity’s validity    identity’s validity   network
                  identity’s validity                                                authentication

Authentication    None                  Single-factor          Multi-factor          Multi-factor;
Token                                                                                requires hard
Components                              Confirmation of        Confirmation of       In-person
for identity                            address, telephone     address or            presentation of two
proofing                                number, or email       telephone number      identifying
                                        address of applicant   in records with       documents with
                                                               voice recording       confirmation;
                                                                                     fingerprint or photo

Note: Other security frameworks have been developed and have been used
in the private sector                                                  17
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
• 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

We propose that this
discussion focus on
the authentication of
users who remotely
access electronic
health information
via external

    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
Considerations: Remote Use

• Authenticating users who are remote introduces
  additional potential vulnerabilities beyond the “base
   – 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

• 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

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

Person or Entity Authentication (§ 164.312(d))111
                HIPAA Standard: Implement procedures to verify that a person or entity seeking access to electronic protected health information
is the one claimed.

   Key Activities      Description                                                       Sample Questions
   1. Determine        •Identify methods available for authentication. Under the         •What authentication methods are available?
   Authentication      HIPAA Security Rule, authentication is the corroboration that     •What are the advantages and disadvantages of each method?
   Applicability to    a person is the one claimed. (45 CFR § 164.304).                  •What will it cost to implement the available methods in our environment?
   Current             •Authentication requires establishing the validity of a           •Do we have trained staff who can maintain the system or do we need to
   Systems/Applicati   transmission source and/or verifying an individual’s claim that   consider outsourcing some of the support?
   ons                 he or she has been authorized for specific access privileges to   •Are passwords being used?
                       information and information systems.                              •If so, are they unique by individual?

   2. Evaluate         •Weigh the relative advantages and disadvantages of               •What are the strengths and weaknesses of each available option?
   Authentication      commonly used authentication approaches.                          •Which can be best supported with assigned resources (budget/staffing)?
   Options Available   •There are four commonly used authentication approaches           •What level of authentication is appropriate based on our assessment of risk
                       available:                                                        to the information/systems?
                       •Something a person knows, such as a password,                    •Do we need to acquire outside vendor support to implement the process?
                       •Something a person has or is in possession of, such as a
                       token (smart card, ATM card, etc.),
                       •Some type of biometric identification a person provides, such
                       as a fingerprint, or
                       •A combination of two or more of the above approaches.
   3. Select and       •Consider the results of the analysis conducted under Key         •Has necessary user and support staff training been completed?
   Implement           Activity 2, above, and select appropriate authentication          •Have formal authentication policy and procedures been established and
   Authentication      methods.                                                          communicated?
   Option              •Implement the methods selected into your operations and          •Has necessary testing been completed to ensure that the authentication
                       activities.                                                       system is working as prescribed?
                                                                                         •Do the procedures include ongoing system maintenance and updates?
                                                                                         •Is the process implemented in such a way that it does not compromise the
                                                                                         authentication information (password file encryption, etc.)?

Note: as a practical matter these Standards may be implemented almost entirely by the software package(s) that a Provider uses.
111 See also Section 4.14, HIPAA Standard: Access Control and Section 4.15, HIPAA Standard: Audit Controls.
 HITRUST Alliance Common Security Framework:
 Authentication Guidelines

  • The Common Security Framework (CSF) incorporates the
    requirements of applicable standards and regulations including
Process Step                                             Implementation Requirements
Identity Proofing                                        In-person verification shall be required in front of a
The process of verifying an applicant’s identity prior   designated registration authority with authorization
to credentialing
                                                         by a designated organizational official.

                                                         Require verifiable unique ID's for all types of users

Authentication Token                                     Ensure password quality and complexity.
Technical components used to electronically prove
one’s identity
                                                         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.      24

To top