ATNA Profile FAQ

The Audit Trail and Node Authentication (ATNA) Integration Profile establishes security measures which, together with the Security Policy and Procedures, provide patient information confidentiality, data integrity and user accountability. This environment is considered the Security Domain and can scale from a department, to enterprise or affinity domain

This FAQ answers questions about what this Profile does and how it is used. For FAQs about Implementing the Profile, see the link in the See Also section below.

Hosts Information for HIMSS 2007 Interoperability Showcase

All Showcase participants received security certificates at the 2007 Connectathon. These certificates are linked to the hostnames, which were also assigned to each system at the Connectathon. This information is still available in Kudu.

We will use the same certificates for the Virtual Connectathon, and for the Showcase as well. In order to do that each participating system will need to associate their Connectathon host name with their current IP address, and every participant will have to use a local 'hosts' file to use all these association. This applies both to infrastructure participants, as well as any other participant using TLS for mutual authentication in any of the Showcase scenarios. If you are unsure what this means, a more detailed explanation can be found here

In the sections below, please enter this information for your system(s) in the format shown. Note that for the Virtual Connectathon some hosts may have a different IP address every day.

Virtual Connectathon hosts

216.165.132.250 epic3
198.81.193.31 ibm1 ibm6 ibm7
198.81.193.235 ibm5

Showcase hosts

10.242.0.43 epic3

Why does ATNA only use TLS?

ATNA "Node Authentication" requirements are setting a minimum-interoperability specification. TLS is a mature, well understood, and widely implemented standard that meets the requirements of mutual authentication with optional confidentiality protections.

Why doesn't ATNA use Web-Services Security?

As is stated, the requirements in ATNA are a floor. At this time the best interoperability that provides protections for Confidentiality, Integrity, and Authenticity is through TLS. The Web-Services Security standard have been implemented, but at this time there is poor interoperability. This is the experience of the general industry using Web-Services as well as for healthcare.

The ATNA profile does not restrict an implementation from using Web-Services Security, but does simply require that at a minimum TLS be available.

Why does ATNA require AES?

AES is the replacement standard for 3DES. AES was selected by an extensive encryption standards discovery process in November 2001. It is designed to be harder to break than previous encryption algorithms yet also be appropriate for a wide variety of platforms including very low power embedded systems.

To show this I would like to direct you to a unofficial profiling of the different algorithms done by Michal Trojnara who used OpenSSL to give these Performance Numbers.

Why do we continue to accept 3DES for Connectathon and HIMSS 2007?

Because Microsoft platform (XP, 2000, 2003) has not yet provided the AES algorithm for their TLS implementation. AES is available in the Microsoft Crypto library, but not available in the TLS implementation. AES is available in the TLS implementation in Vista.

How would a Healthcare Provider use ATNA Audit Logging?

• the VHA Audit Profile shows how the VHA plans to use ATNA. July, 2006
• NIST Draft pub 800-92 Guide to Computer Security Log Management

What is Emergency Mode Access and how does it affect Audit Logs?

Emergency mode access is typically used to refer to cases where a clinical professional needs urgent access to information that he/she would not normally have access to. A good discussion of this can be found in an VHA paper on Emergency Access. As this paper points out, Emergency Mode is not an uncontrolled environment. The privilege elevations are well understood and predetermined. Emergency mode can not be used by the janitor to gain access to clinical documents.

The most likely case for Emergency Mode is where a patient has placed privacy restrictions on their records, but an emergency situation (heart attack) for which a restricted clinician is now the only one that can assist. In this case, emergency mode may have previously been defined as allowing this behavior.

Emergency mode is not used by a visiting doctor. The quick provisioning of users should be handled through expedited procedures.

When Emergency Mode is used, audit logging is relied upon more heavily and thus needs to be recorded at the highest fidelity possible. ATNA Includes an Emergency Mode event (DCM 110127 Emergency Override), but does not include the end-of-emergency-mode event. There will be a change proposal on this topic, but in the mean time one should assume that when a user that has declared emergency mode logs out, that the emergency mode has elapsed.

Why does ATNA use SYSLOG?

The purpose of ATNA is to get the auditable events captured, well described, and over to another system for processing. This allows for a good division of tasks, as the clinical system can quickly create the ATNA Audit Message, send it, and continue to focus on the clinical function. While the Audit Record Repository focuses on protecting the audit log, filtering, sorting, searching, reporting, and alerting. These tasks on a security audit log are not usually the core competence of a healthcare vendor, while there is an industry that does focus on this. This audit analysis industry is today focused on analyzing operating system and database logs.

The Reliable Syslog implementation in the field has progressed very slowly. The IHE is waiting for the outcome of ongoing IETF activities. These may result in confirming the original IETF decision to promulgate Reliable Syslog “cooked”, may result in modifications to that protocol, or may result in its replacement. IHE implementations may chose to proceed with this protocol to establish evidence for the IETF that it does perform as needed, but should be aware that it may be changed.

Due to this limited support for Reliable Syslog we are going to focus Connectathon 2007 on RFC 3164 -- BSD Syslog. Although BSD Syslog is based on UDP, and suffers from the packet loss inherit in UDP, there is evidence that this theoretic packet loss problem doesn't often come up, and when it does the log analysis fails in a deterministic way.

As always with IHE profiles, products may choose to support alternatives beyond the minimum defined by IHE.

See Also

The ITI Technical Framework is the official master document for this Profile.

The updated version of the Technical Framework with all of the Change Proposals as of Summer 2006 can be found at TF with CPs

For assistance with implementing ATNA see the ATNA FAQ.

DICOM supplement 95 contains MOST of the Audit Trail stuff

RFC 3881 contains the base data model.

AES

Listing of Reliable Syslog implementations

IHE and the syslog message size

This page is based on the Profile FAQ Template