1 / 18

Audit Trail and Node Authentication

Audit Trail and Node Authentication. G. Claeys, Agfa Healthcare (geert.claeys@agfa.com). 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)

mariel
Download Presentation

Audit Trail and Node Authentication

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related