1 / 52

IHE Security and Privacy

IHE Security and Privacy. John Moehrke GE Healthcare IHE ITI Technical Committee Member March 6, 2011. Agenda. Overall Security and Privacy controls ATNA EUA XUA Access Control BPPC Gaps Conclusion . What Is IHE?. TBD. Examples. OECD Guidelines On Transborder Flows US-HIPAA

bayard
Télécharger la présentation

IHE Security and Privacy

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IHE Security and Privacy John Moehrke GE Healthcare IHE ITI Technical Committee Member March 6, 2011

  2. Agenda • Overall Security and Privacy controls • ATNA • EUA • XUA • Access Control • BPPC • Gaps • Conclusion

  3. What Is IHE? • TBD

  4. Examples OECD Guidelines On Transborder Flows US-HIPAA EU-EC95/46 JP-Act 57 - 2003 Medical Professional Societies Backup & Recovery International Policies Country-Specific Policies Horizontal Industry Policies Enterprise Policies IHE – leverages/profiles Layers of Policies

  5. Security Mis-Use-Cases • Prevent Indiscriminate attacks (worms, DOS) • Normal Patient that accepts XDS participation • Patient asks for Accounting of Disclosures • Protect against malicious neighbor doctor • Patient that retracts consent to publish • Provider Privacy • Malicious Data Mining • Access to Emergency data set • VIP (movie star, sports figure) • Domestic violence victim • Daughter with sensitive tests hidden from Parent • Sensitive topics: mental health, sexual health • Legal Guardian (cooperative) • Care-Giver (assists w/ care)

  6. Security Models • Risk Assessment • Asset is the information in Registry & all Repositories • Confidentiality, Integrity, and Availability • Patient Safety overrides privacy (most of the time) • Accountability • Access Control model -- Prevention • Audit Control model -- Reaction • Policy Enforcement • Mutually agree to enforce Policies • Enforcement of policies centrally

  7. Audit Trail and Node Authentication (ATNA)

  8. ATNA: Audit Trail and Node Authentication Profile • Secure Node or Secure Application • Access Controls • Functional – can be shown to enforce policies • Audit Controls • SYSLOG + IHE/DICOM/RFC3881 Audit Message • Auditable Events • Network Controls • Mutually Authenticated TLS • Or S/MIME or WS-Security or physical isolation

  9. Secured Node Dual Authenticated Links EHR System ED Application Secured Node Physician Office PACS EHR System PACS Lab Info. System Teaching Hospital Community Clinic Secured Node Secured Node ATNA Security Model(1) PMS XDS Document Repository XDS Document Registry XDS Document Repository XDSDocument Repository Provide & Register Docs

  10. Audit Log - Accountability • Mitigation against unauthorized use • Investigate Audit log for patterns and behavior outside policy. Enforce policy • Secure Node requires appropriate Access Controls to enforce at the enterprise by XDS Source and Consumers • Investigation of patient complaints • Investigate Audit log for specific evidence • ATNA Audit Repositories can filter and auto-forward • Support an Accounting of Disclosures • ATNA Report: XDS-Export + XDS-Import

  11. EHR System Physician Office XDS Document Repository XDSDocument Repository ATNA Audit record repository CT Time server RHIO boundary Centralized Accountability PMS ED Application XDS Document Registry PACS Query Document Register Document EHR System PACS Retrieve Document Provide & Register Docs Maintain Time Lab Info. System Maintain Time Teaching Hospital Maintain Time Community Clinic

  12. EHR System Physician Office XDS Document Repository XDSDocument Repository ATNA Audit record repository CT Time server ATNA Audit record repository ATNA Audit record repository RHIO boundary Distributed Accountability Teaching Hospital State run RHIO PMS ED Application XDS Document Registry PACS Query Document Register Document EHR System PACS Retrieve Document Provide & Register Docs Maintain Time Lab Info. System Maintain Time Maintain Time Community Clinic

  13. Example: Audit Log Cascade Clinic A • Inform Disclosure Reports • Detect unusual behavior  Follow chain back EMR Sjfldjlsdj a Kdjldsj Lsjldjl jfjfjlslkjln Lslasdjj;ask;sls Sflksdjfl;saf Salasaska Faslskf;sf Slsjlsdjlsdjf Lsjflsdjldsjfs Slkfjsdlfjldsf lsjfldsjfldsfj HIE Infrastructure Audit Sjfldjlsdj a Lslasdjj;ask;sls Faslskf;sf lsjfldsjfldsfj Audit

  14. Enterprise User Authentication

  15. Enterprise User AuthenticationScope • Support a single enterprise governed by a single set of security policies and having a common network domain. • Establish one name per user to be used for all IT applications and devices. • Facilitate centralized user authentication management. • Provide users with single sign-on.

  16. IHE Interoperability Workshop Enterprise User AuthenticationValue Proposition • Meet a basic security requirement • User authentication is necessary for most applications and data access operations. • Achieve cost savings/containment • Centralize user authentication management • Simplify multi-vendor implementations • Provide workflow improvement for users • Increase user acceptance through simplicity • Decrease user task-switching time. • More effective security protection • Consistency and simplicity yields greater assurance.

  17. IHE Interoperability Workshop Consistent TimeScope and Value Proposition • Meet a basic security requirement • System clocks and time stamps of the many computers in a network must be synchronized. • Lack of consistent time creates a “security hole” for attackers. • Synchronization ±1 second is generally sufficient. • Achieve cost savings/containment • Use the Network Time Protocol (NTP) standard defined in RFC 1305. • Leverage exisisting Internet NTP services, a set-up option for mainstream operating systems.

  18. IHE Interoperability Workshop Enterprise User AuthenticationKey Attributes • Limited network overhead • Kerberos is network-efficient, developed at a time when high-speed networks were rare. • Kerberos work with any user authentication technology • Tokens, biometric technologies, smart cards, … • Specific implementations require some proprietary components, e.g., biometric devices. • Once user authentication is complete, network transactions are the same for all technologies.

  19. IHE Interoperability Workshop EUA and CTKey Technical Properties • Standards Used • Kerberos v5 (RFC 1510) • Stable since 1993, • Widely implemented on current operating system platforms • Successfully withstood attacks in its 10-year history • Fully interoperable among all platforms • Network Time Protocol (RFC 1305) • Minimal Application Changes • Eliminate application-specific, non-interoperable authentication • Replace less secure proprietary security techniques • Leverage NTP interfaces built-into operating systems

  20. IHE Interoperability Workshop Enterprise User AuthenticationTransaction Diagram

  21. IHE Interoperability Workshop Consistent TimeTransaction Diagram Time Server Maintain Time [ITI-1]↑ Time Client

  22. IHE Interoperability Workshop Communication Initiated Enterprise User Authentication Kerberos Authentication Initial username, password Request TGT “kinit” Kerberos Server Response (contains TGT) TGT Cache Request Service ticket TGT Response with Service Ticket application Application server Protocol specific communication, using Service Ticket as authenticator Single System Environment

  23. IHE Interoperability Workshop Enterprise User Authentication HTTP Authentication Client Authentication Agent HTTP Client Kerberos Authentication Server HTTP KerberizedServer HTTP Get – with no authentication. Start HTTP Session 401 response (WWW Authenticate: Negotiate) Get Kerberos Service Ticket Service Ticket HTTP Get – Kerberized Communication HTTP Response

  24. Cross-Enterprise User Assertion (XUA)

  25. Cross-Enterprise User AssertionValue Proposition • Extend User Identity to Affinity Domain • Users include Providers, Patients, Clerical, etc • Must supports cross-enterprise transactions, can be used inside enterprise • Distributed or Centralized Identity management (Directories) • Provide information necessary so that receiving actors can make Access Control decisions • Authentication mechanism used • Attributes about the user (roles) • Does not include Access Control mechanism • Provide information necessary so that receiving actors can produce detailed and accurate Security Audit Trail

  26. Cross-Enterprise User AssertionTechnical Solution • Initial scope to XDS.b Stored Query and Retrieve • Relies on Web-Services • Easily extended to any Web-Services transactions • Leverage WS-I Basic Security Profile 1.1 • Use SAML 2.0 Identity Assertions • Does not constrain ‘how’ the Assertion was obtained • Supporting Liberty Alliance, WS-Trust, and SAML • Define grouping behavior with EUA and ATNA

  27. XUA encoded in Web-Services

  28. OMB E-Authentication Guidance establishes four assurance levels for consistent application of E-Authentication across gov’t Level 1 Level 2 Level 3 Level 4 Little or no confidence in asserted identity (e.g. self identified user/password) Some confidence in asserted identity (e.g. PIN/Password) High confidence in asserted identity (e.g. digital cert) Very high confidence in the asserted identity (e.g. Smart Card) Four Identity Assurance Levels E-RA tool assists agencies in defining authentication requirements & mapping them to the appropriate assurance level NIST SP800-63 Electronic Authentication technical guidance matches technology to each assurance level

  29. Security Considerations:Four Identity Assurance Levels Increased $ Cost Multi - Factor Token PKI/ Digital Signature Knowledge - Based Very Strong Password High High - PIN/User ID Medium Low Remote Clinical Entry Access to Local EHR/EMR Verification Of Data Transcription Access to Summary of Clinical research Increased Need for Identity Assurance

  30. XUA Actors

  31. X-Service User Audit X-Identity Provider XUA = Web-Services Security + SAML Assertions XUA Assertion Cross-Enterprise User AssertionImplementation Example EHR (ATNA Secure Node) XDS Registry (ATNA Secure Node) XDS Consumer Patient Data user auth provider User Auth Audit Log Key: Original Transaction TLS Protections

  32. Access Controls - Security

  33. Role-Based-Access-Control

  34. Distributed Access Control – enabled by XUA A XDS Registry XDS Document Consumer Access Control B XDS Registry XDS Document Consumer Access Control Access Control C XDS Registry XDS Document Consumer Access Control Access Control Access Control

  35. Basic Patient Privacy Consent (BPPC)

  36. Basic Patient Privacy ConsentsAbstract • The Basic Patient Privacy Consents (BPPC) profile provide mechanisms to: • Record the patient privacy consent(s), • Mark documents published to XDS with the choice of patient privacy consent that was used to authorize the publication, • Enforce the privacy consent appropriate to the use. • Builds upon the ATNA security infrastructure

  37. Basic Patient Privacy ConsentsValue Proposition • A Privacy Domain (e.g. XDS Affinity Domain) • develop privacy policies, • and implement them with role-based or other access control mechanisms supported by edge/EHR systems. • A patient can • Be made aware of an institution privacy policies. • Have an opportunity to selectively control access to their healthcare information.

  38. Basic Patient Privacy ConsentsStandards and Profiles Used • Key Properties • Human Readable Consents • Machine Processable • Support for standards-based Role-Based Access Control • Standards • CDA Release 2.0 • XDS Scanned Documents • Document Digital Signature • Cross Enterprise Document Sharing (XDS.a, XDS.b, XDR, and XDM)

  39. OPT-IN  Share normally

  40. OPT-OUT Only Direct Care * Only in case of risk to Life-or-Limb == Break-Glass

  41. RBAC with Basic Consent

  42. Basic Consent – Multiple Consents on file Normal HIE Opt-In Enable Specific Research Study

  43. BPPC Enables • Basic Opt-In or Basic Opt-Out • Specific cases  authorize a specific use • Control Use or Publication • Existence of Opt-Out could forbid publication • Typically Normal data is always published and control is on use of the data • Time based Consent  Episodic Consent • Site specific Consent

  44. Etcetera

  45. Other Profiles of Interest • Document Digital Signature (DSG) • Non-Repudiation of Document • Personnel White Pages (PWP) • Organizational Directory of Users • Healthcare Provider Directory (HPD) • External Directory of Individuals and Organizations • Document Encryption (DEC) • Encryption of Documents

  46. Conclusion

  47. Supported Security Mis-Use-Cases • Prevent Indiscriminate attacks  Mutual Auth TLS • Normal Patient that accepts XDS participation • Patient asks for Accounting of Disclosures  informed by ATNA log • Protect against malicious neighbor doctor  informed by ATNA log • Patient that retracts consent to publish  Repository is local, manual • Provider Privacy  User identity is not exposed • Malicious Data Mining  queries are all patient based • Access to Emergency data set  BPPC policy • VIP  XDR/M, BPPC (Local enforcement) • Domestic violence victim  BPPC policy (Local enforcement) • Daughter with sensitive tests  XDR/M BPPC policy • Sensitive topics  Don’t publish, BPPC policy • Legal Guardian (cooperative)  BPPC policy (Local enforcement) • Care Giver (assists w/ care)  BPPC policy (Local enforcement)

  48. Gaps for potential future development • Better coded vocabulary for confidentiality codes • Complex policies on a document by document basis • Extension to objects other than XDS (e.g. DICOM) • Patient Access to • Sensitive health topics (you are going to die) • Low sensitivity (scheduling) • Self monitoring (blood sugar) • Authoritative updates / amendments / removal • Complex Privacy ‘consent’ Policy capabilities • Supporting Inclusion Lists • Supporting Exclusion Lists • Exceptions, and Obligations • Supporting functional role language • Access Control Service • Centralized Policies • Policy Decision Point / Policy Enforcement Points • Accounting of Disclosures reports, alerts, messaging • To support reporting to the ‘consumer’ when their data is accessed • Un-Safe Client machine (home-computer)

More Related