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

Audit Trail and Node AuthenticationAudit Trail and Node Authentication

Robert HornAgfa Healthcare

June 28-29, 2005 Interoperability Strategy Workshop2

IT Infrastructure Security IT Infrastructure Security ProfilesProfiles

2004 Consistent Time (CT) Enterprise User Authentication (EUA)

2005Audit Trail and Note Authentication (ATNA)

2006Cross-Enterprise User Authentication (XUA)Document Digital Signature (DSG)


Assets being ProtectedAssets 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


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.

http://www.ntp.org/


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.


ATNAATNAIHE GoalIHE 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.


ATNAATNANetwork EnvironmentsNetwork 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.


ATNAATNANode SecurityNode 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.


ATNAATNANode AuthenticationNode 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


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.


ATNAATNAAuditing SystemAuditing 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.


State of the Message StandardsState 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



• 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.



• 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.


First MistakeFirst Mistake

• Both DICOM Supplement 95 and IHE Technical Framework use:

• EventID

– And should have used• EventTypeCode


ATNAATNAAuditable EventsAuditable 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.



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.



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.


Audit Events for XDSAudit 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.


ATNAATNARecord Audit EventRecord 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.


An exampleAn 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.


A Study is OrderedA 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”


Modality ActivityModality 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/OrderFiller

“Query”


Patient Arrives and is MedicatedPatient 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”


The study is performedThe study is performed

EvidenceCreator

“Begin Transferring Instances”


“Procedure Record”DSS/

Order Filler

Image Manager/Image Archive

“Instances Transferred”

“Order Record”


Study PerformedStudy 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


The study is read (examine data)The study is read (examine data)

ReportCreator


“Instances Accessed”

“Study Deleted”


Image Manager/Image Archive


“Query Record”


The Study is readThe 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.


The study is read (deliver report)The study is read (deliver report)

ReportCreator



Report Manager


“Order Record”


The study is read (deliver report)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.


What it takes to be a secure nodeWhat 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.


What it takes to be a secure nodeWhat 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

Documents

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