Audit Trail and
This presentation is the property of its rightful owner.
Sponsored Links
1 / 32

Audit Trail and Node Authentication PowerPoint PPT Presentation


  • 66 Views
  • Uploaded on
  • Presentation posted in: General

Audit Trail and Node Authentication. Robert Horn Agfa Healthcare. 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)

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Audit trail and node authentication

Audit Trail and

Node Authentication

Robert Horn

Agfa Healthcare


It infrastructure security profiles

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


Assets being protected

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


Consistent time ct

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


Compatibility with radiologybasic security

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


Atna ihe goal

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


Atna network environments

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


    Atna node security

    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


    Atna node authentication

    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


    Why node authentication

    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


    Atna auditing system

    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


    State of the message standards

    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


    State of the message standards1

    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


    State of the message standards2

    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


    First mistake

    First Mistake

    • Both DICOM Supplement 95 and IHE Technical Framework use:

      • EventID

    • And should have used

      • EventTypeCode

    Interoperability Strategy Workshop


    Atna auditable events

    ATNAAuditable Events

    Interoperability Strategy Workshop


    Atna auditable events1

    ATNAAuditable Events

    Interoperability Strategy Workshop


    Atna auditable events2

    ATNAAuditable Events

    Interoperability Strategy Workshop


    Audit events for xds

    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


    Atna record audit event

    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


    An example

    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


    A study is ordered

    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


    Modality activity

    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


    Patient arrives and is medicated

    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


    The study is performed

    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


    Study performed

    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


    The study is read examine data

    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


    The study is read

    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


    The study is read deliver report

    The study is read (deliver report)

    “Begin Transferring Instances”

    Report

    Creator

    “Procedure Record”

    “Order Record”

    Report

    Manager

    “Instances Transferred”

    Interoperability Strategy Workshop


    The study is read deliver report1

    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


    What it takes to be a secure node

    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


    What it takes to be a secure node1

    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


  • Login