Overview

The Audit Trail and Node Authentication (ATNA) Profile specifies the foundational elements needed by all forms of secure systems: node authentication, user authentication, event logging (audit), and telecommunications encryption. It is also used to indicate that other internal security properties such as access control, configuration control, and privilege restrictions are provided.

For details, see IHE Audit Trail and Node Authentication (ATNA) profile and RESTful ATNA Supplement.

Actors and Transactions

The following diagram provides an overview of the ATNA profile Actors, Transactions and their interactions. 

The table below lists the transactions for each actor directly involved in the ATNA profile. To claim compliance with ATNA, an actor shall support all required transactions (labeled “R”) and may support the optional transactions (labeled “O”).

Transactions

• Authenticate Node [ITI-19] – In the Authenticate Node transaction, the local Secure Node presents its identity to a remote Secure Node and authenticates the identity of the remote node. After this mutual authentication, other secure transactions may take place through this secure pipe between the two nodes. Uses RFC5246 - Transport Layer Security (TLS) Protocol Version 1.2 and RFC3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification protocols.
• Record Audit Event [ITI-20] – This transaction is used to report auditable events to an Audit Record Repository. Uses RFC5424 – Syslog over TLS 1.2 or UDP protocols.
• Retrieve ATNA Audit Event [ITI-81] – This transaction is used to search ATNA events recorded in an ATNA Audit Record Repository. The result is a FHIR bundle of AuditEvent Resources that match a set of search parameters.
• Retrieve Syslog Event [ITI-82] – This transaction is used to retrieve syslog messages from the Audit Record Repository subject to parameters that limit the retrieval.

Sequence Diagram

Canadian Implementation Guidance for ATNA - CA:Sec and CA:Aud

The ATNA profile addresses two main concerns: Security and Event Logging for the purpose of Auditing. Given the fact that Security and Auditing are tightly coupled, along with the multiple options offered for both aspects, ATNA is a complex profile with extensive documentation.

CA:Sec and CA:Aud implementation guidance were introduced to allow for a lightweight ATNA, bring improvements by decoupling the two main aspects of ATNA: Security and Audit, and focus on a few options for modern formats and technologies. This guidance is not replacing ATNA. An implementation that is already compliant with ATNA will be able to pass ATNA tests. 

The following diagram presents how the Canadian implementation guidance has segmented the key components of ATNA.

The section below provides comparison tables between the full ATNA profile and the options selected for CA:Sec and CA:Aud.

The following notation definitions are used throughout this section:

Optionality notation is defined as:

Transport Protocol notation is defined as:

Actors/Transactions

ATNA

CA:Sec

CA:Aud

Note 1: The audit events must be recorded using the IHE Record Audit Event [ITI-20] with FHIR Feed option or other (IHE or non-IHE) methods.

Note 2: This transaction is required if the Audit Record Repository is central.

Notes

• ATNA defines two actors with similar role: Secure Node and Secure Application, that fulfill roles in both Security and Audit aspects via mandatory transaction requirements. This causes Security and Audit to be tightly coupled, meaning that to exchange secure communication, auditing also must be implemented as defined by ATNA.

  The audit messages must be recorded by means defined by ATNA.

• CA:Sec defines a single actor and a single transaction for secure communication.

• CA:Aud defines actors that are responsible for auditing only. Secure communication is recommended to be achieved via actor grouping with the CA:Sec actor.

  The audit messages can be recorded by any means, using either IHE transaction ITI-20 with FHIR option or any other (IHE or non-IHE) methods. The messages must be made available for retrieval in FHIR format via IHE transaction ITI-81.

Actor Options

ATNA

CA:Sec

Note 1: The Secure Application shall support one of the following options: Mutual TLS or Server-side TLS.

CA:Aud

Note 1: The audit events must be recorded using the IHE Record Audit Event [ITI-20] with FHIR Feed option or other (IHE or non-IHE) methods.

Note 2: This transaction is required if the Audit Record Repository is central.

Notes:

• ATNA offers many actor options
• CA:Sec and CA:Aud are focusing on a small subset of the ATNA options.
• CA:Sec options also improve security with recommendations for higher versions of TLS protocol and stronger cipher suites

Required Actor Groupings

ATNA

CA:Sec and CA:Aud

None

Notes:

• ATNA requires multiple mandatory actor groupings.

• CA:Sec and CA:Aud do not require mandatory actor groupings.

Actor grouping is optional and is recommended to achieve additional functionality such as System Time Synchronization or Security and Auditing.