Audit Trail and Node Authentication

1. Audit Trail and Node Authentication Robert Horn Agfa Healthcare

2. 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) Interoperability Strategy Workshop

3. 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 Interoperability Strategy Workshop

4. 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. Interoperability Strategy Workshop

5. 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. Interoperability Strategy Workshop

6. ATNAIHE 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. Interoperability Strategy Workshop

7. ATNANetwork 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. Interoperability Strategy Workshop

8. ATNANode 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. Interoperability Strategy Workshop

9. ATNANode 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 Interoperability Strategy Workshop

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. • 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. Interoperability Strategy Workshop

11. ATNAAuditing 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. Interoperability Strategy Workshop

12. 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 Interoperability Strategy Workshop

13. 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. Interoperability Strategy Workshop

14. 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. Interoperability Strategy Workshop

15. First Mistake • Both DICOM Supplement 95 and IHE Technical Framework use: • EventID • And should have used • EventTypeCode Interoperability Strategy Workshop

16. ATNAAuditable Events Interoperability Strategy Workshop

17. ATNAAuditable Events Interoperability Strategy Workshop

18. ATNAAuditable Events Interoperability Strategy Workshop

19. 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. Interoperability Strategy Workshop

20. ATNARecord 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. Interoperability Strategy Workshop

21. 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. Interoperability Strategy Workshop

22. A Study is Ordered “Order Record” XYZ Actor 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. Interoperability Strategy Workshop

23. Modality Activity “Query” DSS/Order Filler • 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 Interoperability Strategy Workshop

24. Patient Arrives and is Medicated “Patient Record” ABC Actor “Order Record” • 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. “Procedure Record” “Medication Event” Interoperability Strategy Workshop

25. The study is performed “Begin Transferring Instances” Evidence Creator “Procedure Record” DSS/ Order Filler “Procedure Record” “Order Record” Image Manager/ Image Archive “Instances Transferred” Interoperability Strategy Workshop

26. 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 Interoperability Strategy Workshop

27. The study is read (examine data) “Instances Transferred” Report Creator “Procedure Record” “Instances Accessed” “Study Deleted” “Query Record” Image Manager/ Image Archive “Begin Transferring Instances” Interoperability Strategy Workshop

28. 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. Interoperability Strategy Workshop

29. The study is read (deliver report) “Begin Transferring Instances” Report Creator “Procedure Record” “Order Record” Report Manager “Instances Transferred” Interoperability Strategy Workshop

30. 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. Interoperability Strategy Workshop

31. 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. Interoperability Strategy Workshop

32. 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 Interoperability Strategy Workshop