Presentation is loading. Please wait.

Presentation is loading. Please wait.

Privacy and Security Tiger Team Meeting Discussion Materials Today’s Topic Recommendations on Trusted Identities for Providers in Cyberspace August 20,

Similar presentations


Presentation on theme: "Privacy and Security Tiger Team Meeting Discussion Materials Today’s Topic Recommendations on Trusted Identities for Providers in Cyberspace August 20,"— Presentation transcript:

1 Privacy and Security Tiger Team Meeting Discussion Materials Today’s Topic Recommendations on Trusted Identities for Providers in Cyberspace August 20, 2012

2 Overview of Today’s Discussion Review straw recommendation defining “riskier” transactions and outstanding issues Presentations from entities using two-factor authentication in provider settings Finalize recommendations on provider authentication Refinements, if any, to be done via email 2

3 Revised Straw Recommendation (1of 2) The Tiger Team believes that ONC should move toward individual-user level credentials to meet NIST Level of Assurance (LoA) 3 for riskier exchange transactions, ideally by Meaningful Use Stage 3. Such riskier transactions are those: –that will travel across a network any part of which is or could be unsecured, such as across the open Internet or an unsecured wireless connection –where a person is logging in from outside of the physical confines of the organization (where the individual cannot be observed by others) ? 3 Note: Related recommendations on this subject are included in the backup slides 7 and 8.

4 Revised Straw Recommendation (2of 2) Such riskier transactions should be identified by each organization as part of its required security risk analysis Low risk activity, such as on-site, intra-organizational access to systems/data (where users can be observed by others) should not require LoA 3. 4

5 Outstanding Issues Are additional refinements needed to the definition of “riskier” transactions? What, if any, burden issues are associated with the use of two-factor authentication and how are they being managed? –Informed by today’s presentations Does this recommendation implicate a MU Stage 3 requirement for certified EHR systems? If so, how would such a requirement be articulated? What are the implications of setting the bar above what DEA requires (re: ID proofing) for institutional practitioners for e-prescribing controlled substances? 5

6 Backup slides Backup Slides 6

7 Recommendations to the HIT Policy Committee 2.As an interim step, the ONC could require baseline two-factor authentication (per NIST 800-63-1) with existing organization-driven identity proofing (LOA “2.5”) –Two-factor authentication provides additional assurance –Entities not yet required to implement more robust identity proofing per NIST 800-63-1 3.Should extend to all clinical users accessing/exchanging data in the riskier exchange transactions. 7

8 Recommendations 4.ONC’s work to implement this recommendation should be informed by NSTIC and aim to establish trust within the health care system, taking into account provider workflow needs and the impact of approaches to trusted identity on health care on health care quality and safety. For example, NSTIC also will focus on the capability to pass along key attributes that can be attached to identity. The capability to pass key attributes – e.g., valid professional license – may be critical to facilitating access to data. 5.ONC should consult with NIST about future iterations of NIST 800-63-1 to identify any unique needs in the healthcare environment that must be specifically addressed. 8

9 800-63 Authentication Requirements LOA2LOA3 Single factorMulti-factor NIST LOA2 Identity Proofing (or higher) NIST LOA3 Identity proofing (or higher) Approved cryptographic techniques required Approved cryptographic required for all operations Eaves dropper, on-line guessing prevented Eavesdropper, replay, on-line guessing, verifier impersonation and man-in-the- middle attacks prevented LOA3/LOA 4 Multi-factor may be usedMinimum of two factors required; 3 token types may be used: “soft” cryptographic tokens, “hard” cryptographic tokens and “one-time password” device tokens. Examples: shared secret, mobile one- time- password (OTP) application, PKI, USB token, credit card password tokens, RFID or blue tooth token 9

10 LOA2/LOA3 Identity Proofing Required Information Level 2Level 3 In person Possession of valid current primary Government Picture ID applicant’s picture, and either address of record or nationality of record (e.g. driver’s license or passport) Level 2 plus ID must be verified Remote Possession of a valid Government ID (e.g. a driver’s license or passport) number and Financial account number (e.g., checking account, savings account, loan or credit card) with confirmation via records of either number. Same as Level 2 but confirmation via records of both numbers. 10

11 Level 2Level 3 Inspects photo-ID, compare picture to applicant, record ID number, address and DoB. If ID appears valid and photo matches applicant then: a) If ID confirms address of record, authorize or issue credentials and send notice to address of record, or; b) If ID does not confirm address of record, issue credentials in a manner that confirms address of record. Essentially same as Level 2 plus Verify via the issuing government agency or through credit bureaus or similar databases. Confirm that: name, DoB, address and other personal information in record are consistent with the application. LOA2/LOA3 Identity Proofing Registration Authority (RA) In Person Process Person 11

12 LOA2/LOA3 Identity Proofing Registration Authority (RA) Remote Process Level 2Level 3 Verifies information provided by applicant including ID number or account number through record checks either with the applicable agency or institution or through credit bureaus or similar databases, and confirms that: name, DoB, address other personal information in records are on balance consistent with the application and sufficient to identify a unique individual. Address confirmation and notification: a) Sends notice to an address of record confirmed in the records check or; b) Issues credentials in a manner that confirms the address of record supplied by the applicant; or c) Issues credentials in a manner that confirms the ability of the applicant to receive telephone communications or e-mail at number or e-mail address associated with the applicant in records. Verifies information provided by applicant including ID number and account number through record checks either with the applicable agency or institution or through credit bureaus or similar databases, and confirms that: name, DoB, address and other personal information in records are consistent with the application and sufficient to identify a unique individual. Address confirmation: a) Issue credentials in a manner that confirms the address of record supplied by the applicant; or b) Issue credentials in a manner that confirms the ability of the applicant to receive telephone communications at a number associated with the applicant in records, while recording the applicant’s voice. 12

13 Privacy and Security Tiger Team DEA E-Prescribing for Controlled Substances: Identity Proofing & Authentication Requirements August 10, 2012 13

14 Background DEA’s Interim Final Rule for Electronic Prescriptions for Controlled Substances (EPCS) was published on March 31, 2010 (75 FR 16236-16319) and authorizes e-prescriptions for controlled substancesDEA’s Interim Final Rule for Electronic Prescriptions for Controlled Substances The rule became effective on June 1, 2010 The IFR establishes requirements for e-prescribing applications, which must: –Undergo a third-party audit or –Be reviewed and certified by an approved certification body. NIST and GSA approved this process based on the reasoning that it was consistent with NIST 800-63 (and now must align with 800-63-1) 14

15 EPCS Interim Final Rule Individual practitioners in private practice (i.e., those practitioners not seeking access to an institutional practitioner's applications), must use approved certification authorities (CAs) and similar credential service providers (CSPs) for identity proofing and credentialing ID proofing must meet NIST SP 800-63-1 Assurance Level 3 although a CA or CSP may impose higher standards For practitioners obtaining a two-factor authentication credential that does not include a digital certificate, DEA requires the authentication credential to come from a CSP approved by the GSA Office of Technology Strategy/Division of Identity Management –Note the GSA office as been renamed to the GSA Office of Information Integrity and Access/Identity Assurance and Trusted Access Division. This Division will rely on credentials that have been approved by Federally approved trust framework providers. 15

16 EPCS Interim Final Rule For practitioners obtaining a digital certificate, DEA requires the digital certificate come from a CA that is cross-certified with the Federal Bridge Certification Authority (FBCA) at a basic assurance level or higher Institutional practitioners are permitted, but not required, to do their own in-house, in-person (not remote) identity proofing –DEA does NOT require these practitioners to meet the requirements of LoA3 for identity proofing because "these institutions already conduct extensive checks before they credential a practitioner" –These practitioners may also obtain identify proofing from an approved CA or CSP –These practitioners may issue authentication credentials themselves or obtain them from an approved CA or CSP –They may also decide to have each practitioner obtain identity proofing and the authentication credential on their own. 16

17 EPCS Interim Final Rule For both individual and institutional practitioners, two-factor authentication is required –Permissible factors are: a biometric, a knowledge factor (e.g., a password), or a hard token –No biometric second factors have been approved by any of the Federally approved Trust Framework Providers 17

18 Use of Biometrics for Authentication NIST 800-63-1 is for remote applications, i.e., when no attendant is watching the users trying to log on to a system Security/privacy issues with biometrics –Biometrics are not secrets and may be spoofed relatively easily and inexpensively –Anti-spoofing techniques are not mature enough to write a spec for or test for performance –Data at rest can be encrypted but traditional cryptography cannot be used to protect patient's data to do matching, in the same way that password authentication is done Although ONC and other NIST-assisted efforts are underway to address these issues, solutions may be some time off 18


Download ppt "Privacy and Security Tiger Team Meeting Discussion Materials Today’s Topic Recommendations on Trusted Identities for Providers in Cyberspace August 20,"

Similar presentations


Ads by Google