Difference between revisions of "ATNA Profile FAQ"

Latest revision as of 17:08, 16 February 2011

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?

It no longer does... ATNA does allow for Web-Services to utilize end-to-end security compliant with WS-I Basic Security Profile. However this is not without problems around configuration and performance.

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?

For grouped transactions that are Web-Services, ATNA allows for Web-Services Security to provide end-to-end security according to WS-I Basic Security Profile.

For a well written article on the trade-off of TLS vs Web-Services Security please see

Java Web Services: The High Cost of WS-Security By Dennis Sosnoski, IBM developerWorks, July 7 2009

Why does ATNA default to no encryption?

IHE covers many healthcare domains many of which are very departmental. These departments often have an isolated network and therefore do not have the risks to confidentiality that are common when using the Internet. Thus IHE ATNA sets a minimum secure communications at protecting authenticity, the node-to-node authentication. TLS does not have a setting for authentication only, and SHA1 is not technically difficult.

ATNA recognizes that there are other environments, such as where XDS is used, where the risks to confidentiality are high and thus has a declared option for encryption. Profiles like XDS can require that this encryption option must be available.

An additional factor is import and export restrictions on products that contain encryption. These restrictions only cover encryption and thus by setting the minimum requirement for ATNA without encryption we allow healthcare products to claim ATNA compliance which brings along all of ATNA capability without forcing encryption. This supports provision of healthcare to the people of countries where these import restrictions exist.

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 implementations 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 (interesting article on audit logs and perfect reliability), issues around the syslog message size, 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. Here is another blog entry on the topic Can More Reliable Actually Mean Less

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

Future of ATNA transport

September 2009: CP-ITI-417 has been approved for final text.

February 2010: CP-ITI-477, modifying CP-ITI-417, has been approved for final text.

Syslog-protocol is now an approved IETF RFC and is a normative specification.

replace the Reliable-SYSLOG with SYSLOG-PROTOCOL-TLS, and replace BSD-SYSLOG with SYSLOG-PROTOCOL-UDP.

RFC 5424 The Syslog Protocol
RFC 5425 Transmission of Syslog Messages over TLS
RFC 5426 Transmission of Syslog Messages over UDP

Net Impact of these Changes on Audit Transport

Reading through the RFC for the syslog message, there are minor changes to how the header message is formatted:

<PRI> Mmm dd hh:mm:ss hostname Message
<PRI>1 YYYY-MM-DDThh:mm:ss.SSZ hostname application48 process-id128 message-id32 - Message [http://essaysexperts.com/ buy essays]

This should be a couple of change lines to your code that outputs the message header

While the new syslog specification "requires" a TLS implementation, ATNA only requires that for secure syslog. As originally specified by CP-ITI-417, we wouldn't have been likely to see many of those because RFC 5425 requires TLS 1.2, which almost nobody will be able to support unless they are running Windows 7 or Server 2008, or knows someone with way too much time on their hands. CP-ITI-477, however, removes the requirement for version 1.2 while keeping the requirement for some version of TLS when implementing a TCP-based transport.

Although the changes in CP-ITI-477 make the TCP-based transport more attainable, the IHE ATNA profile still doesn't require use of the TLS implementation, so you can use a UDP connection. That's the same transport as was used previously.

Net impact is that you'll have to change the few lines of code that generate the syslog header, and you have the option of switching to TLS v1.x as your transport.