180 likes | 365 Views
Privacy and Security Tiger Team Meeting. Discussion Materials Today’s Topic Recommendations on Trusted Identities for Providers in Cyberspace August 20, 2012. Overview of Today’s Discussion. Review straw recommendation defining “riskier” transactions and outstanding issues
E N D
Privacy and Security Tiger Team Meeting Discussion Materials Today’s Topic Recommendations on Trusted Identities for Providers in Cyberspace August 20, 2012
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
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) ? Note: Related recommendations on this subject are included in the backup slides 7 and 8.
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.
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?
Backup slides Backup Slides
Recommendations to the HIT Policy Committee • 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 • Should extend to all clinical users accessing/exchanging data in the riskier exchange transactions.
Recommendations • 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. • 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.
LOA2/LOA3 Identity ProofingRegistration Authority (RA) In Person Process Person
LOA2/LOA3 Identity Proofing Registration Authority (RA) Remote Process
Privacy and Security Tiger Team DEA E-Prescribing for Controlled Substances: Identity Proofing & Authentication Requirements August 10, 2012 13
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 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)
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.
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.
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
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