1. September, 2005What IHE Delivers 1 ITI Security Profiles – ATNA, CT IHE Education Workshop 2007 IHE IT Infrastructure Education John Moehrke GE Healthcare

2. 2 IHE Security Profiles 2004 Consistent Time (CT) Enterprise User Authentication (EUA) 2005 Audit Trail and Note Authentication (ATNA) Personnel White Pages (PWP) 2006 Document Digital Signature (DSG) Basic Patient Privacy Consents (BPPC) 2007 Cross-Enterprise User Assertion (XUA) White Papers Health Information Exchange secured with IHE Risk Management in Profile Development

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

4. 4 ATNA Assets protected Patient and Staff Safety ATNA provides minor protections by restricting network access ATNA provides minor protections by restricting network access Most safety related protection is elsewhere in products. Security activity must not interfere with safety. Most safety related protection is elsewhere in products. Security activity must not interfere with safety. Patient and Staff Health As with Safety, ATNA provides minor health protection and must not interfere. As with Safety, ATNA provides minor health protection and must not interfere. 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.

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

6. 6 ATNA Security Measures (1 of 3) Node Authentication: Establish the system identity of network transactions. How to authenticate network connections. How to protect the integrity of the transaction Optionally: How to protect the confidentiality of the transaction Mutually Authenticated TLS

7. 7 ATNA Security Measures (2 of 3) Authorization and Access control: Establish user’s ability to perform an action, e.g. access to data User Authentication: e.g. Enterprise User Authentication (EUA) or Cross Enterprise User Authentication (XUA).. User Authorizations: e.g. Role-based-access- control System internal mechanisms

8. 8 ATNA Security Measures (3 of 3) Accountability and Audit trail: Establish historical record of user’s or system actions over period of time, answers question: “What have you done?” List of security audit events message format to describe an event and transport protocol

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

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

11. 11 X - 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.

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

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

14. 14 ATNA Node Authentication TLS Encryption options:  IHE mandates a minimum mandatory set to ensure that a compatible pair will exist.  Additional encryption options may be implemented  TLS specifies how the encryption will be selected from the proposed list. It need not be one of the IHE minimum set.  Some environments permit NULL encryption (e.g., internal radiology operations). Others do not (e.g., XDS). ATNA presently specifies mechanisms for using TLS with HTTP, DICOM, and HL7.  DICOM toolkits incorporate TLS support  Some HL7 libraries incorporate TLS support  Some web servers (e.g. Tomcat, Apache) incorporate TLS support.

15. 15 ATNA Auditing System Designed for surveillance rather than forensic use. This is not a substitute for internal product detailed logs. Two audit message formats.  IHE Radiology interim format, for backward compatibility with radiology  IETF/DICOM/HL7/ASTM format, for future growth IETF RFC 3881 Common Audit Message IETF RFC 3881 Common Audit Message DICOM Supplement 95 DICOM Supplement 95 ASTM E.214 ASTM E.214 HL7 Audit Informative documents HL7 Audit Informative documents ISO Standardization in process ISO Standardization in process  New profile work will utilize the new schema for messages, so use the new schema unless there is a product need for compatibility with the Radiology interim format.

16. 16 ATNA Auditing System Both formats are XML encoded messages, permitting extensions using XML standard extension mechanisms.  Do not redefine current attributes or elements  Only extend when existing attributes or elements are insufficient  Document the source schema for extensions and make it freely available because audit repositories will need it. If there might be messages using different schema from a single system, use the source field in the syslog message to distinguish the format. All messages from a specific source must use the same schema.

17. 17 ATNA Record Audit Event BSD Syslog protocol (RFC 3164) will be part of the Connectathon infrastructure.  Support messages up to 32768 bytes long.  Clients should be configurable to send to any port and destination. IETF continues to resolve issues surrounding Reliable Syslog (RFC 3195). There will be no connectathon support of testing Reliable Syslog, but private testing may take place. Possibility is syslog-protocol currently under ballot

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 control of the system PHI-import Patient information is imported into the control of the system Procedure-record-event The patient record is created, modified, or deleted. Query-information Any auditable query not otherwise specified. Security Alert Security alerts, configuration changes, Break-Glass, etc. User Authentication user attempting to log on or log off, whether successful or not. Study-object-event A study is created, modified, or deleted. Study-used A study is viewed, read, or similarly used.

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

22. 22 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  Network communication authenticated  User access controls as applicable External security facilities are the responsibility of the secure node actor:  File system security, etc  Over all system user authentication and access control  Over all security audit event capture

23. 23 Consistent Time (CT) Network Time Protocol ( NTP) version 3 (RFC 1305) for time synchronization Actor must support manual configuration for NTP sources. Required accuracy: 1 second Options:  SNTP (Simple Network Time Protocol)  Secure NTP

24. September, 2005What IHE Delivers 24 Questions?