1. Audit Trail and Node Authentication Audit Trail and Node Authentication Robert Horn Agfa Healthcare

2. June 28-29, 2005Interoperability Strategy Workshop2 IT Infrastructure Security Profiles 2004 Consistent Time (CT) Enterprise User Authentication (EUA) 2005 Audit Trail and Note Authentication (ATNA) 2006 Cross-Enterprise User Authentication (XUA) Document Digital Signature (DSG)

3. June 28-29, 2005Interoperability Strategy Workshop3 Assets being Protected All security systems exist to protect some asset. IHE follows the legal, regulatory, and medical ethics selection of assets: –Patient and staff safety –Patient and staff health –Patient and staff privacy

4. June 28-29, 2005Interoperability Strategy Workshop4 Consistent Time (CT) Network Time Protocol ( NTP) version 3 (RFC 1305) Actor must support manual configuration: –Manual IP address or hostname for time server –preferably 3 or more servers should be supported –Automatic discovery and broadcast will not be tested Required accuracy: 1 second Optional Secure NTP may be tested Required for use of ATNA, EUA, XUA. All time tags must be time synchronized. See http://www.ntp.org for extensive technical details on the protocol, and your vendor documentation for installation and configuration.http://www.ntp.org

5. June 28-29, 2005Interoperability Strategy Workshop5 Compatibility with RadiologyBasic Security But, what if I already have systems that support Basic Security? –ATNA + Radiology Option is backward compatible with Basic Security –Integration Statements should change support claim from Basic Security to Radiology Option for ATNA –For some actors there will be scenario requirements for the connectathon. This emulates having a hospital security office setting a security policy. It is not an official recommendation that these requirements are universally applicable.

6. June 28-29, 2005Interoperability Strategy Workshop6 ATNA IHE Goal IHE makes cross-node security management easy: –Only a simple manual certificate installation is needed, although more sophisticated systems (LDAP, PKI) can be used. –Implementations should separate the authentication, authorization, and accountability functions to accommodate the needs of different locations. –Enforcement is driven by a posteriori audits and real- time visibility, not detailed access controls.

7. June 28-29, 2005Interoperability Strategy Workshop7 ATNA Network Environments Physically secured networks Explicit physical security preventing access by other nodes, or VPN and VLAN technologies that provide equivalent network isolation. Encryption is not required, only host authentication. Protected networks 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. Encryption is required.

8. June 28-29, 2005Interoperability Strategy Workshop8 ATNA Node Security ATNA specifies some of the capabilities that are needed, e.g. access control. But: –ATNA does not specify policies –ATNA does not specify mechanisms, although other IHE protocols like EUA are obvious candidates. Connectathon performs only rudimentary validation of node security functions.

9. June 28-29, 2005Interoperability Strategy Workshop9 ATNA Node Authentication X.509 certificates for node identity and keys These will be provided at the Connectathon and may change during the connectathon. TCP/IP Transport Layer Security Protocol (TLS) for node authentication, and optional encryption Actor must be able to configure certificate list of authorized nodes. The connectathon validates use of an explicit list of certificates for authorized machines. ATNA presently specifies mechanisms for HTTP, DICOM, and HL7

10. June 28-29, 2005Interoperability Strategy Workshop10 Why node authentication? Many systems are shared access, e.g. CT systems, where the machine identity is more important than the operators identity for security purposes. 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. Machine access is usually controlled by the site administration. Even authorized users are not permitted to use personal machines.

11. June 28-29, 2005Interoperability Strategy Workshop11 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 IETF RFC-3881 for Common Audit Message ASTM E.214 HL7 Audit Informative documents Both formats are XML encoded messages, permitting extensions using XML standard extension mechanisms.

12. June 28-29, 2005Interoperability Strategy Workshop12 State of the Message Standards Interim IHE format, mature but limited to only basic radiology uses IETF Audit message format (RFC-3881) Stable, generic See www.xml.org/xml/schema/7f0d86bd/healthcare- security-audit.xsd

13. June 28-29, 2005Interoperability Strategy Workshop13 State of the Message Standards DICOM Supplement 95 –RFC-3881format specialized to cover activities by imaging equipment –Frozen Draft for trial implementation The purpose of frozen draft is to find mistakes through trial implementations like this IHE Connectathon. There have been mistakes found already. More mistakes will be found, please report them as you find them. There is a review scheduled for November 2005 by the DICOM committee to make fixes and assess whether it is ready to publish as a standard.

14. June 28-29, 2005Interoperability Strategy Workshop14 State of the Message Standards IHE Technical Framework First effort at detailing non-imaging activities The purpose of frozen draft is to find mistakes through trial implementations like this IHE Connectathon. There have been mistakes found already. More mistakes will be found, please report them as you find them.

15. June 28-29, 2005Interoperability Strategy Workshop15 First Mistake Both DICOM Supplement 95 and IHE Technical Framework use: EventID –And should have used EventTypeCode

16. June 28-29, 2005Interoperability Strategy Workshop16 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. Instances-deleted The deletion of persistent objects. Instances-stored The storage of persistent objects is completed.

17. June 28-29, 2005Interoperability Strategy Workshop17 ATNA Auditable Events Medication Medication is prescribed, delivered, etc. Mobile-machine-event Mobile equipment is relocated, leaves the network, rejoins the network 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.

18. June 28-29, 2005Interoperability Strategy Workshop18 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 A procedure 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.

19. June 28-29, 2005Interoperability Strategy Workshop19 Audit Events for XDS The primary audit events for XDS transactions are: –PHI Import (e.g., when data is obtained from the Repository/Registry) –PHI Export (e.g., when a submission set is provided to the Repository/Registry) Details of affinity domain organizational boundaries determine which activities are imports and exports. Other audit events, e.g., user login, also must be reported. There is a separate audit repository for each organization. There is not one audit repository for the entire affinity domain.

20. June 28-29, 2005Interoperability Strategy Workshop20 ATNA Record Audit Event Reliable Syslog (RFC 3195) is the new transport for Audit Records, although BSD Syslog protocol (RFC 3164) is permitted for backward compatibility with Radiology Basic Security. RFC 3195 implementations exist, but they are new and limited. Some vendors may to prefer RFC 3164 until there are multiple third party implementations of 3195 available. RFC 3195 may evolve based on industry experience with the new implementations. The primary gain from RFC 3195 is guaranteed reliability and security. RFC 3164 is subject to data loss on overloaded networks and eavesdropping on unprotected networks.

21. June 28-29, 2005Interoperability Strategy Workshop21 An example The following is an example of messages that might be generated during a routine imaging examination. Scenarios are being prepared for some connectathon workflows. Contributions to scenarios are welcomed, especially for the newer IHE disciplines where there is less experience with auditing. Only IHE Radiology has multi-year experience with its use.

22. June 28-29, 2005Interoperability Strategy Workshop22 A Study is Ordered Order Record created: Identify the person and/or process creating the order Identify the patient Note, this is just a security and privacy log so other order details are not needed. XYZ Actor Order Record

23. June 28-29, 2005Interoperability Strategy Workshop23 Modality Activity This is issued only by the DSS/Order Filler, not by the modalities. Shows: Identity of Querying Machine Identity of Local responding process Query description and contents DSS/Order Filler Query

24. June 28-29, 2005Interoperability Strategy Workshop24 Patient Arrives and is Medicated Several events are generated: The patient record is read, The order is read, The procedure record is created, and Medication is given The audit reports indicate the persons and/or processes, and the patient involved. ABC Actor Order Record Procedure Record Medication Event Patient Record

25. June 28-29, 2005Interoperability Strategy Workshop25 The study is performed Evidence Creator Begin Transferring Instances Procedure Record DSS/ Order Filler Image Manager/ Image Archive Instances Transferred Order Record

26. June 28-29, 2005Interoperability Strategy Workshop26 Study Performed The Procedure Records track the progress of the MPPS The Instances audit records track the progress of the data The order record reflects the updated order status on completion of the study

27. June 28-29, 2005Interoperability Strategy Workshop27 The study is read (examine data) Report Creator Begin Transferring Instances Instances Accessed Study Deleted Procedure Record Image Manager/ Image Archive Instances Transferred Query Record

28. June 28-29, 2005Interoperability Strategy Workshop28 The Study is read This shows the DICOM evidence related transactions. The image manager reports the queries to find the patient record (from a person or prefetch process) and the studies sent to the workstation. The workstation reports the studies received, the studies examined, the update to procedure status, and the final deletion of the unneeded copies of the studies. These are at the level of studies examined, not a detailed listing of each image examined.

29. June 28-29, 2005Interoperability Strategy Workshop29 The study is read (deliver report) Report Creator Begin Transferring Instances Procedure Record Report Manager Instances Transferred Order Record

30. June 28-29, 2005Interoperability Strategy Workshop30 The study is read (deliver report) This shows the activity tracking the resulting report: –The report writer reads the procedure schedule, transfers a report to the report manager, and updates the procedure status. –The report manager receives the finished report, and updates the order status.

31. June 28-29, 2005Interoperability Strategy Workshop31 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.

32. June 28-29, 2005Interoperability Strategy Workshop32 What it takes to be a secure node The Secure node is more than add-on auditing capability. The complete work effort includes: Deciding what events should be auditable Instrumenting all applications to detect auditable events and generate audit messages. Ensuring that all communications connections are protected. Establishing a local security mechanism to protect all local resources. Establishing configuration mechanisms for: –Time synchronization using Consistent Time (CT) profile –Certificate management –Network configuration