1. September, 2005What IHE Delivers 1 ITI Security Profiles – ATNA, CT, EUA, PWP, DSIG IHE Vendors Workshop 2006 IHE IT Infrastructure Education Robert Horn, Agfa Healthcare

2. 2 IT Infrastructure Profiles 2004 Patient Identifier Cross-referencing for MPI (PIX) Retrieve Information for Display (RID) Consistent Time (CT) Patient Synchronized Applications (PSA) Enterprise User Authentication (EUA) 2005 Patient Demographic Query (PDQ) Cross Enterprise Document Sharing (XDS) Audit Trail and Note Authentication (ATNA) Personnel White Pages (PWP) 2006 Document Digital Signature (DSG) – Notification of Document Availability (NAV) Patient Administration/Management (PAM)

3. 3 IHE and PHI Protection User Identity → PWP, EUA User Authentication → EUA Node Authentication → ATNA Security Audit Trails → ATNA Data Integrity Controls → CT, ATNA TLS option Data Confidentiality → ATNA TLS option Access Controls → Future item in IHE roadmap

4. 4 Audit Trail and Node Authentication (ATNA) Defines basic security features for an individual system for use as part of the security and privacy environment for a healthcare enterprise. Extends the IHE radiology oriented Basic Security profile (defined in 2002) to be applicable to other healthcare uses. Provides host level authentication, which is used in conjunction with the user authentication from EUA.

5. 5 ATNA Value Proposition Protect Patient Privacy and System Security:  Meet ethical and regulatory requirements Enterprise Administrative Convenience:  Unified and uniform auditing system  Common approach from multiple vendors simplifies definition of enterprise policies and protocols.  Common approach simplifies administration Development and support cost reduction through Code Re-use:  Allows vendors to leverage single development effort to support multiple actors  Allows a single development effort to support the needs of different security policies and regulatory environments.

6. 6 ATNA Assets protected Patient and Staff Safety ATNA provides minor protections by restricted network access ATNA provides minor protections by restricted network access Most safety related protection is elsewhere in products Most safety related protection is elsewhere in products Patient and Staff Health As with Health, ATNA provides minor protection As with Health, ATNA provides minor protection Patient and Staff Privacy Access Control at the node level can be enforced. Access Control at the node level can be enforced. Audit Controls at the personal level are supported. Audit Controls at the personal level are supported. Note that in Europe there are significant staff privacy protections, not just patient privacy protections in the laws. Note that in Europe there are significant staff privacy protections, not just patient privacy protections in the laws.

7. 7 ATNA Security Requirements Reasons: Clinical Use and Privacy  authorized persons must have access to medical data of patients, and the information must not be disclosed otherwise.  Unauthorized persons should not be able to interfere with operations or modify data By means of procedures and security mechanisms, guarantee:  Confidentiality  Integrity  Availability  Authenticity

8. 8 ATNA Security Measures Authentication: Establish the user and/or system identity, answers question: “Who are you?” ATNA defines: How to authenticate network connections. ATNA defines: How to authenticate network connections. ATNA Supports: Authentication mechanisms, e.g. Enterprise User Authentication (EUA) or Cross Enterprise User Authentication (XUA).. ATNA Supports: Authentication mechanisms, e.g. Enterprise User Authentication (EUA) or Cross Enterprise User Authentication (XUA).. Authorization and Access control: Establish user’s ability to perform an action, e.g. access to data, answers question: “Now that I know who you are, what can you do?” ATNA defines: How to authorize network connections. ATNA defines: How to authorize network connections. ATNA requires: System internal mechanisms for both local and network access. ATNA requires: System internal mechanisms for both local and network access.

9. 9 ATNA Security Measures Accountability and Audit trail: Establish historical record of user’s or system actions over period of time, answers question: “What have you done?” ATNA Defines: Audit message format and transport protocol ATNA Defines: Audit message format and transport protocol

10. 10 ATNA IHE Goal IHE makes cross-node security management easy:  Only a simple manual certificate installation is needed, although more sophisticated systems can be used  Separate the authentication, authorization, and accountability functions to accommodate the needs of different approaches.  Enforcement driven by ‘a posteriori audits’ and real-time visibility.

11. 11 ATNA Integrating Trusted Nodes System A System B Secured System Secure network Strong authentication of remote node (digital certificates) network traffic encryption is not required, it is optional Secured System Local access control (authentication of user) Audit trail with: Real-time access Time synchronization Central Audit Trail Repository

12. 12 ATNA Suitable Network Environments Physically secured networks Explicit physical security preventing access by other nodes, or Explicit physical security preventing access by other nodes, or VPN and VLAN technologies that provide equivalent network isolation. VPN and VLAN technologies that provide equivalent network isolation. Protected networks Physical security that prevents modification or installation of unauthorized equipment Physical security that prevents modification or installation of unauthorized equipment The network is shared with other authorized nodes within the enterprise that should not have unrestricted access to patient information. The network is shared with other authorized nodes within the enterprise that should not have unrestricted access to patient information. Unprotected networks Not generally supported, although nodes with sufficient node level security and using encryption may be safe. Not generally supported, although nodes with sufficient node level security and using encryption may be safe.

13. 13 ATNA Node Security ATNA specifies some of the capabilities that are needed, e.g. access control. ATNA does not specify policies ATNA does not specify mechanisms, although other IHE protocols like EUA are obvious candidates. This permits vendors and enterprises to select technologies and policies that are appropriate to their own purposes without conflicting with the ATNA profile.

14. 14 ATNA Node Authentication X.509 certificates for node identity and keys TCP/IP Transport Layer Security Protocol (TLS) for node authentication, and optional encryption Secure handshake protocol of both parties during Association establishment:  Identify encryption protocol  Exchange session keys Actor must be able to configure certificate list of authorized nodes. ATNA presently specifies mechanisms for HTTP, DICOM, and HL7

15. 15 Why Node Authentication Many systems are shared access, e.g. CT systems, where the machine identity is more important than the operator’s identity for security purposes. A CT operator is only permitted to update CT records from a CT system. A CT operator is only permitted to update CT records from a CT system. Some systems operate autonomously, e.g. PACS archive. Knowing identity of the PACS administrator on duty is not useful when monitoring PACS activity. There might be nobody logged in. Knowing identity of the PACS administrator on duty is not useful when monitoring PACS activity. There might be nobody logged in. Machine access is usually controlled by the site administration. Even authorized users are not permitted to use personal machines. Even authorized users are not permitted to use personal machines.

16. 16 Secure Node vs Application IHE uses the grouping mechanism to state that in the finished system or environment both the application and the secure node must be present. It is possible to be an application supporting ATNA transactions without being a Secure Node:  Server applications  Plug-in applications Those security facilities that are within the scope of the application must be provided:  ATNA logging of relevant events  Within application authentication, signature, etc. External security facilities are the responsibility of the secure node actor:  File system security, etc

17. 17 ATNA Auditing System Designed for surveillance rather than forensic use. Two audit message formats  IHE Radiology interim format, for backward compatibility with radiology  IETF/DICOM/HL7/ASTM format, for future growth DICOM Supplement 95 DICOM Supplement 95 IETF Draft for Common Audit Message IETF Draft for Common Audit Message ASTM E.214 ASTM E.214 HL7 Audit Informative documents HL7 Audit Informative documents Both formats are XML encoded messages, permitting extensions using XML standard extension mechanisms.

18. 18 ATNA Auditable Events Actor-start-stop The starting or stopping of any application or actor. Audit-log-used Reading or modification of any stored audit log Begin-storing-instances The storage of any persistent object, e.g. DICOM instances, is begun Health-service-event Other health service related auditable event. Images-availability-query The query for instances of persistent objects. Instances-deleted The deletion of persistent objects. Instances-stored The storage of persistent objects is completed.

19. 19 ATNA Auditable Events Medication Medication is prescribed, delivered, etc. Mobile-machine-event Mobile equipment is relocated, leaves the network, rejoins the network Node-authentication- failure An unauthorized or improperly authenticated node attempts communication Order-record-event An order is created, modified, completed. Patient-care-assignment Patient care assignments are created, modified, deleted. Patient-care-episode Auditable patient care episode event that is not specified elsewhere. Patient-record-event Patient care records are created, modified, deleted.

20. 20 ATNA Auditable Events PHI-export Patient information is exported outside the enterprise, either on media or electronically PHI-import Patient information is imported into the enterprise, either on media or electronically Procedure-record-event The patient record is created, modified, or deleted. Query-information Any auditable query not otherwise specified. Security-administration Security alerts, configuration changes, etc. Study-object-event A study is created, modified, or deleted. Study-used A study is viewed, read, or similarly used.

21. 21 ATNA Record Audit Event BSD Syslog protocol (RFC 3164) is the interim approach while the IETF continues to resolve issues surrounding Reliable Syslog (RFC 3195). Audit trail events and content based on IETF, DICOM, HL7, and ASTM standards. Also, Radiology Basic Security audit event format is allowed for backward compatibility.

22. 22 XDS Affinity Domain (NHIN sub-network) Community Clinic Lab Info. System PACS Teaching Hospital PACS ED Application EHR System Physician Office EHR System Accountability PMS Retrieve Document Register Document Query Document XDS Document Registry ATNA Audit record repository CT Time server MaintainTime MaintainTime Maintain Time Provide & Register Docs XDS Document Repository ATNA Audit record repository ExportExport Query Query Import Import Export

23. 23 Consistent Time (CT) Network Time Protocol ( NTP) version 3 (RFC 1305) for time synchronization Actor must support manual configuration Required accuracy: 1 second Optionally Secure NTP may be used Required for use of ATNA, EUA, XUA

24. 24 Enterprise User Authentication - EUA 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.

25. 25 EUA – Transaction Diagram

26. 26 Personnel White Pages (PWP) Provide access to basic information about the human workforce members  Does not include Patients Defines method for finding the PWP Defines query/access method Defines attributes of interest

27. 27 PWP - Transactions Personnel White Pages Consumer Query for Healthcare Workforce Member Info Personnel White Pages Directory DNS Server Find Personnel White Pages

28. 28 What it takes to be a secure node The Secure node is not a simple add-on of an auditing capability. The complete work effort includes: Instrumenting all applications to detect auditable events and generate audit messages. Instrumenting all applications to detect auditable events and generate audit messages. Ensuring that all communications connections are protected. Ensuring that all communications connections are protected. Establishing a local security mechanism to protect all local resources. Establishing a local security mechanism to protect all local resources. Establishing configuration mechanisms for: Establishing configuration mechanisms for: –Time synchronization using Consistent Time (CT) profile –Certificate management –Network configuration Implement the audit logging facility

29. 29 What it takes to be a secure node The entire host must be secured, not just individual actors. The entire host must have appropriate user access controls for identification, authentication, and authorization. All communications that convey protected information must be authenticated and protected from interception. This means every protocol, not just the IHE transactions. All health information activities should generate audit trails, not just the IHE actors.

30. 30 Document Digital Signature (DSG) Provide signature mechanism Provide verification/validation mechanism Provide signature attributes XDS manages document and signature Allows direct access to document (XDS)

31. 31 Document Digital Signature (DSG) Digital Signature Document format Leverages XDS for signature by reference New document type in XDS – Linkage forward and back. Profiles single / multiple signatures Profiles nested signatures Provide signature integrity across intermediary processing