Audit Trail and Node Authentication

1. Audit Trail and Node Authentication G. Claeys, Agfa Healthcare (geert.claeys@agfa.com)

2. Scope • Defines basic security features for a system in a healthcare enterprise in order to guarantee : • Only authorized persons have access to PHI (Protected Health Information) • Protect PHI against alteration, destruction and loss • Comply existing Privacy & Security regulations • Extends the IHE radiology oriented Basic Security profile (2002) to be applicable to other healthcare uses.

3. Security Mechanism • Authentication (user and device) • Authorization • Accountability (audit trails) • Confidentiality • Integrity ATNA, EUA ATNA ATNA ATNA

4. Local authentication of user • Strong authentication of remote node (digital certificates) • Audit trail that logs privacy&security related operations Secured System Secure network Central Audit TrailRepository IHE ATNA- Architecture Secured System Secure network System B System A

5. IHE ATNA – Actor and Transactions All existing IHE actors need to be grouped with a Secure Node actor. Audit Record Repository Time Server Maintain Time Record Audit Event Secure Node Authenticate Node “Any” IHE actor Secure Node

6. Secure Node • Local user authentication • Only needed at “client” node • Authentication mechanism • User name and password (minimum) • Biometrics, smart card • Secure nodes maintain list of authorized users : local or central (using EUA) • Security policy of hospital defines the relation between user and user id

7. Secure Node (cont.) • Mutual device authentication • Establish a trust relationship between 2 network nodes • Strong authentication by exchanging X.509 certificates • Actor must be able to configure certificate list of trusted nodes. • TCP/IP Transport Layer Security Protocol (TLS) • Used with DICOM/HL7/HTTP messages • Secure handshake protocol during Association establishment: • Encryption : • Intra-muros (default): no encryption • Extra-muros : AES128 • TLS/SSL negotiations problems were detected at connectathon 2006 USA • Caused by incorrect configuration of SSL/TLS packages (e.g. STunnel) • Guidelines will follow

8. Secure node – additional effort • Instrument all applications to detect auditable events and generate audit messages. • Ensure that all communications connections are protected (system hardening). • Establish a local security mechanism to protect all local resources • Establish configuration mechanisms for: • Time synchronization • Certificate management • Network configuration

9. Certificate Management • Certificates can be signed by device (self-signing) or via a CA (e.g. hospital) • Use self-signed certificates for testing interoperability • Connectathon has a CA • Support at least direct comparison of certificates • Import certificate of each trusted peer device • Compare each received certificate with list of trusted certificate • Certificate management white paper • from NEMA’s Security&Privacy committee • www.nema.org/prod/med/security

10. Auditing System • Auditing system consists of • List of events that generate audit messages • Audit message format • Transport mechanism • Designed for surveillance rather than forensic use.

11. Audit Events • Audit triggers are defined for every operation that access PHI (create, delete, modify, import/export) • IHE TF describes the supported Audit Trigger per Actor • Audit triggers are grouped on transaction/ study level to minimize overhead

12. Audit Message Format • XML encoded message • IHE Radiology Provisional format • for backward compatibility with radiology • ATNA format • Preferred format • Joint effort of IETF/DICOM/HL7/ASTM • XML schema (rfc3881) : www.xml.org/xml/schema/7f0d86bd/healthcare-security-audit.xsd • XSLT transformation is provided to convert “Provisional scheme” to “ATNA” scheme

13. Audit Transport Mechanism • Reliable Syslog – cooked mode • RFC 3195 • Connection oriented • Support certificate based authentication, encryption • But limited industry support • BSD Syslog protocol (RFC 3164) • Preferred transport mechanism for the time being

14. Backward compatibility • ATNA is backward compatible with Basic Security (IHE Radiology) • Basic security = Provisional XML scheme + BSD syslog • Applications, supporting Basic Security are ATNA compliant • Basic security is deprecated • Basic Security Profile being deprecated by Radiology Option for ATNA • No further extensions • New applications are encouraged to use new message format

15. Audit system - lessons learned • BSD Syslog • Ensure that the BSD header format is correct, otherwise the messages may get trashed. • BSD Syslog messages longer than 1k may get truncated • -> keep the messages short • Date/Time : UTC format • EventDateTime="2006-01-17T17:01:25-06:00“ or • EventDateTime="2006-01-17T17:01:25-06:00Z“ • Patient ID • Use either the MRN (preferred) or a properly defined local Patient ID. • Patient Names can be arbitrary format.

16. Audit system - lessons learned (cont.) • Active Participant Identification • Use one ActiveParticipant per event • Use an identifiable user as ActiveParticipant • If not possible then use the node/process as ActiveParticipant • Node names • Use host names instead of ip addresses • Audit Source Id : • hostname or stationName

17. Audit system - lessons learned (cont.) • Event Identification (EventID): • use DCM code set (DICOM supplement 95) or IHE code set (ATNA) • avoid proprietary values. • Schema checking • Ensure that the messages conform to the schema defined in RFC3881 • Do not include schema items with null contents.

18. www.ihe-europe.org • Frequently Asked Questions • Integration Profiles in Technical Frameworks: • Cardiology • IT Infrastructure • Laboratory • Patient Care Coordination • Radiology • Connectathon Results • Vendor Products Integration Statements • Participation in Committees & Connectathons