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.

What is required in the certificate?

CP 232 is out for ballot right now. This CP is making it clear that implementation should require no specific format or attributes in a certificate. Often times implementors will try to use the DN as the hostname, but this is troublesome when the hostname is dynamic. There are solutions in some of the IETF specifications, but the success is very spotty.

RFC 2818, section 3.1, paragraph 4:

   Matching is performed using the matching rules specified by [RFC2459].
   If more than one identity of a given type is present in the certificate
   (e.g., more than one dNSName name, a match in any one of the set is
   considered acceptable.) Names may contain the wildcard character
   * which is considered to match any single domain name component
   or component fragment. E.g., *.a.com matches foo.a.com but not
   bar.foo.a.com. f*.com matches foo.com but not bar.com.

Though RFC2818 is explicit, handling of wildcard certs depends on the browser/toolkit used. Have a look at http://wiki.cacert.org/wiki/WildcardCertificates?highlight=%28wildcard%29

What type of certificate management is needed?

See the Management of Machine Authentication Certificates white paper by the global NEMA/COCIR/JIRA Security and Privacy Committee on the topic. The major contributors to ATNA are also major contributors to this white paper.

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 UDP 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. Of course this does not mean that a healthcare vendor couldn't take on the Audit Record Repository Actor responsibilities.

IHE profiles existing standards and picks from mature standards that have received industry acceptance. We really liked the capability provided by Reliable Syslog. The Reliable Syslog implementation in the field progressed very slowly, thus IHE had to postpone the use of Reliable Syslog. Thus we are stuck with 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.

Future of ATNA transport

Given the above description of the issues around BSD-Syslog, IHE is waiting for the outcome of ongoing IETF activities. These have resulted in new standard that takes the simplicity from BSD-syslog and pairs it with different transports including TLS/TCP. These new standards are in various states of approval. The details of the standard and it's status can be found at the following links: syslog-protocol, syslog-transport-udp and syslog-transport-tls.

The IHE ITI Technical Committee is strongly supporting these new standards and is very confident that IHE will adopt them as soon as they are normative. At this time (February, 2008) these standards are in the final stable phase, simply awaiting IETF to assign an RFC number to them. Therefore we recommend at this time that they be implemented and used (with caution to expect minor changes).