9 Audit Trail and Node Authentication (ATNA) Profile

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.

Many other IHE profiles require or recommend grouping with ATNA actors as part of their security considerations.

This Profile has been updated by the RESTful ATNA Supplement.

9.1 ATNA Actors/Transactions

This section defines the actors, transactions, and/or content modules in this profile. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A at http://ihe.net/TF_Intro_Appendices.

Figure 9.1-1 shows the actors directly involved in the ATNA Profile and the relevant transactions between them.

Note: In Figure 9.1-1, the Node Authentication [ITI-19] transaction is shown between the Secure Application and Secure Node actors. It may also occur between two Secure Node actors, or between two Secure Application actors.

Table 9.1-1 lists the transactions for each actor directly involved in the ATNA Profile. To claim compliance with this profile, an actor shall support all required transactions (labeled “R”) and may support the optional transactions (labeled “O”).

Table 9.1-1: Audit Trail and Node Authentication Integration Profile - Actors and Transactions

Actor	Transactions	Optionality	Section
Audit Record Repository	Record Audit Event [ITI-20]	R	ITI TF-2: 3.20
Audit Record Forwarder	Record Audit Event [ITI-20]	R	ITI TF-2: 3.20
Secure Node	Authenticate Node [ITI-19]	R	ITI TF-2: 3.19
	Record Audit Event [ITI-20]	R	ITI TF-2: 3.20
Secure Application	Authenticate Node [ITI-19]	R	ITI TF-2: 3.19
	Record Audit Event [ITI-20]	R	ITI TF-2: 3.20

9.1.1 Actor Descriptions and Actor Profile Requirements

9.1.1.1 Secure Node

A Secure Node is a system that provides security and privacy services (user authentication, secure communications, security audit recording, and security policy enforcement) for all software and services on that system. An ultrasound machine is an example of a Secure Node.

Security services apply to all aspects of the system from the hardware up to the user interface and external communication. A Secure Node has control over this entire stack, and ensures that all aspects are covered by the security and privacy services. A Secure Node vendor does not need to invent its own disk drives or write its own operating system. Contractual control over security is sufficient. A short list of exceptions may exist if the risk analysis indicates that these are not significant and the full list of exceptions is documented.

This permits cloud-based and other system architectures to claim to be a Secure Node when there are sufficient contractual controls to ensure that security and privacy services cover the entire relevant hardware and software stack. This includes any non-IHE applications that process PHI in that environment, such as database services.

When a system claims conformance to Secure Node, then the ATNA requirements apply to all actors in that system. The Secure Node shall:

1. Use the Authenticate Node transaction for all network connections to or from the node that may expose private information as specified in ITI TF-2: 3.19 .

2. Provide sufficient authentication methods, based on risk assessment, to ensure that only authorized users access the Secure Node. See Section 9.4.1.2.1.
3. Detect and report a Record Audit Event as specified in ITI TF-2: 3.20 for:

• all of the activity-related events for the Secure Node
• all transaction-related events for the Secure Node

9.1.1.2 Secure Application

A Secure Application provides security and privacy services (user authentication, secure communications, security audit recording, and security policy enforcement) for both grouped IHE actors and for functionality provided by related software and services within control of the Secure Application. A Secure Application is not responsible for security of its environment, e.g., the operating system and database outside of its control the way that a Secure Node is. A smartphone app is an example of a Secure Application that has control over the security for the application, but not the rest of the mobile device software or hardware security.

The Secure Application does not have complete control over the full stack from hardware to user interface and external communications. It only has security services control over the actors with which it is grouped.

When a system claims conformance to Secure Application, then the ATNA requirements apply to all actors in that system. The Secure Application shall:

1. Use the Authenticate Node transaction for all network connections to or from the application that may expose private information as specified in ITI TF-2: 3.19 .

2. Provide sufficient authentication methods to ensure that only authorized users access the Secure Application See Section 9.4.1.2.1.
3. Detect and report a Record Audit Event as specified in ITI TF-2: 3.20 for:

• all of the activity-related events for the Secure Application
• all transaction-related events for the Secure Application

9.1.1.3 Audit Record Repository

The Audit Record Repository receives event audit reports and stores them. It may be part of a federated network of repositories. It is expected to have analysis and reporting capabilities, but those capabilities are not specified as part of this profile. This profile also does not specify the capacity of an Audit Record Repository, because the variety of deployment needs makes it impractical to set requirements for the event report volume or capacity needed.

The Audit Repository shall support:

1. At least one of the audit transport mechanisms specified in ITI TF-2: 3.20 . (See Table 9.2-1.)

2. Receipt of at least one of the IHE-specified audit message formats. Note that the message format is extensible to include both future IHE specifications (e.g., audit requirements for new IHE transactions) and private extensions.
3. Local security and privacy service protections and user access controls.

The Audit Record Repository may ignore or process messages in non-IHE message formats. This may be for backwards compatibility or other reasons.

The Audit Record Repository shall be grouped with a Secure Node or Secure Application.

9.1.1.4 Audit Record Forwarder

The Audit Record Forwarder is grouped with an Audit Record Repository, and forwards selected audit messages that are received by the Audit Record Repository. It may filter these messages and forward them selectively. It may forward to multiple different Audit Record Repositories.

The Audit Record Forwarder shall:

1. Be grouped with a Secure Node or Secure Application.

2. Be grouped with an Audit Record Repository.
3. Filter and forward Syslog messages as they arrive. Filter and forward is described in ITI TF-2: 3.20 and Syslog RFC5424.
4. Be configurable to forward messages to destination Audit Record Repositories.

9.2 ATNA Actor Options

Options that may be selected for this Integration Profile are listed in the Table 9.2-1 along with the actors to which they apply. Dependencies between options when applicable are specified in notes.

Note: The “ATX” prefix in option names below marks alternatives for audit transport protocol, and the “STX” prefix marks alternatives for secure transport protocol, as defined in the Record Audit Event [ITI-20] transaction.

Table 9.2-1: ATNA - Actors and Options

Actor	Options	Vol. & Section
Audit Record Repository (Note 4)	ATX: TLS Syslog	ITI TF-1: 9.2.7.2
	ATX: UDP Syslog	ITI TF-1: 9.2.7.3
Audit Record Forwarder (Note 4)	ATX: TLS Syslog	ITI TF-1: 9.2.7.2
	ATX: UDP Syslog	ITI TF-1: 9.2.7.3
Secure Node (Note 1) (Note 4)	Radiology Audit Trail	ITI TF-1: 9.2.2 RAD TF-3: 5.1
	FQDN Validation of Server Certificate (Note 2)	ITI TF-1: 9.2.5 ITI TF-2: 3.19.6.1.4
	STX: No Secure Transport	ITI TF-1: 9.2.6.1
	STX: TLS 1.2 Floor using BCP195	ITI TF-1: 9.2.6.4
	STX: S/MIME	ITI TF-1: 9.2.6.5
	STX: WS-Security	ITI TF-1: 9.2.6.6
	ATX: TLS Syslog	ITI TF-1: 9.2.7.2
	ATX: UDP Syslog	ITI TF-1: 9.2.7.3
Secure Application (Note 1) (Note 4)	Radiology Audit Trail	ITI TF-1: 9.2.2 RAD TF-3: 5.1
	FQDN Validation of Server Certificate (Note 2)	ITI TF-1: 9.2.5 ITI TF-2: 3.19.6.1.4
	STX: No Secure Transport	ITI TF-1: 9.2.6.1
	STX: TLS 1.2 Floor using BCP195	ITI TF-1: 9.2.6.4
	STX: S/MIME	ITI TF-1: 9.2.6.5
	STX: WS-Security	ITI TF-1: 9.2.6.6
	ATX: TLS Syslog	ITI TF-1: 9.2.7.2
	ATX: UDP Syslog	ITI TF-1: 9.2.7.3

Note 1: Secure Node and Secure Application shall support at least one of the “STX” (Secure Transport) options.

Note 2: The “FQDN Validation of Server Certificate” Option is only applicable to TLS-based Secure Transports.

Note 3: Intentionally left blank.

Note 4: This actor shall support at least one of the “ATX” (Audit Transport) options. If a product’s IHE Integration Statement does not declare one of these options, the reader should assume that the product supports the TLS or UDP Syslog Option.

9.2.1 ATNA Encryption Option (retired)

The ATNA Encryption Option is now retired because the Node Authentication [ITI-19] transaction requires support for Encryption.

9.2.2 Radiology Audit Trail Option

The Radiology Audit Trail Option provides specific audit requirements for actors in IHE Radiology domain profiles. Actors that support this option shall audit trigger events applicable to its implementation. RAD TF-3: Table 5.1-1 and Table 5.1-2 detail audit events based on the Radiology actor.

9.2.3 This section intentionally (temporarily) left blank

9.2.4 This section intentionally (temporarily) left blank

9.2.5 FQDN Validation of Server Certificate Option

The FQDN Validation of Server Certificate Option applies the rules presented in RFC6125 when a client authenticates the server using an X.509 certificate in the context of Transport Layer Security (TLS).

In an environment where clients have implemented this option, a server’s X.509 certificate shall contain a subjectAltName entry of type DNS-ID, per RFC6125 Section 4.

See ITI TF-1: 9.4.1.2.2 and ITI TF-2: 3.19.6.1.4 .

Note: IETF Best Current Practice BCP195 recommends, but does not require, FQDN validation.

When an actor implements this option, it need not be capable of functioning without this validation.

9.2.6 Secure Transport (STX) Options

At least one of the STX options shall be supported. A system may support many options, for which the system must then be configurable to enable each option.

Whether a particular network configuration is secure, or not, is a local policy decision, which should consider an ever-evolving risk landscape. A deploying organization will decide for themselves the best use of technology to enable secure and authenticated communications.

The following sections contain the requirements when a system is configured to utilize each option.

9.2.6.1 STX: No Secure Transport Option

The system must be used on a network that provides secure transport, such as a physically isolated network, Virtual Private Network (VPN), or some other method.

9.2.6.2 STX: TLS 1.0 Floor with AES Option (retired)

This option has been retired due to an update in RFC8996 in March 2021.

9.2.6.3 STX: TLS 1.0 Floor using BCP195 Option (retired)

This option has been retired due to an update in RFC8996 in March 2021.

9.2.6.4 STX: TLS 1.2 Floor using BCP195 Option

Actors that support this option have the ability to both:

• Operate with the highest level of cyber protection for the TLS-protected communication channel per the IETF Best Current Practice (BCP195 with TLS 1.2 and selected cipher suites), and
• Restrict to the use of TLS version 1.2 [RFC5246] or higher.

This option adopts valuable recommendations from the IETF BCP195 and prohibits less secure behavior. It is well suited for ensuring a high level of cyber protection.

Note: The STX: TLS 1.2 Floor using BCP195 Option is equivalent to the DICOM “Non-Downgrading BCP 195 TLS Secure Transport Connection Profile”. See DICOM PS3.15 Section B.10.

An actor that supports the STX: TLS 1.2 Floor using BCP195 Option shall be able to comply with BCP195 with the additional restrictions enumerated in ITI TF-2: 3.19.6.2.3 .

9.2.6.5 STX: S/MIME Option

The system will utilize S/MIME to protect the message for authentication of sender, restriction to specific recipients, encryption, and integrity protection. See ITI TF-2: 3.19.6.5 .

9.2.6.6 STX: WS-Security Option

The system will utilize WS-Security WS-I Basic Security Profile 1.1 to protect the message for authentication of sender, restriction to specific recipients, encryption, and integrity protection. See ITI TF-2: 3.19.6.4 .

9.2.7 Audit Transport (ATX) Options

At least one of these options shall be supported. Many can be declared, for which the product must then be configurable to enable each of the supported Audit Transport Options.

9.2.7.1This section intentionally (temporarily) left blank

9.2.7.2 ATX: TLS Syslog Option

The ATX: TLS Syslog Option enables sending ATNA audit records using Syslog protocol over TLS.

An actor that supports this option shall implement the Syslog interaction defined in the Record Audit Event [ITI-20] transaction, using TLS as a transport layer. See ITI TF-2: 3.20.4.1 .

9.2.7.3 ATX: UDP Syslog Option

The ATX: UDP Syslog Option enables sending ATNA audit records using Syslog protocol over UDP.

An actor that supports this option shall implement the Syslog interaction defined in the Record Audit Event [ITI-20] transaction, using UDP as a transport layer. See ITI TF-2: 3.20.4.1 .

9.3 ATNA Required Actor Groupings

An actor from this profile (Column 1) shall implement all of the required transactions and/or content modules in this profile in addition to all of the transactions required for the grouped actor (Column 2).

Table 9.3-1: ATNA - Required Actor Groupings

ATNA Actor	Actor to be grouped with	Reference	Content Bindings Reference
Audit Record Repository	Consistent Time / Time Client	ITI TF-1:7	N/A
	ATNA / Secure Node or Secure Application	ITI TF-1:9	N/A
Audit Record Forwarder	Consistent Time / Time Client	ITI TF-1:7	N/A
	ATNA / Secure Node or Secure Application	ITI TF-1:9	N/A
	ATNA / Audit Record Repository	ITI TF-1:9	N/A
Secure Node	Consistent Time / Time Client	ITI TF-1:7	N/A
Secure Application	Consistent Time / Time Client	ITI TF-1:7	N/A

9.4 ATNA Overview

The Audit Trail and Node Authentication (ATNA) Profile specifies foundational components that are part of an overall privacy and security system. These are:

• Node Authentication
• Access Control
• Event Logging (Audit)
• Secure Communications

Successful implementation of ATNA also depends on the existence and support of:

• System Security Services
• Privacy and Security Governance.

Node authentication enables communications participants to:

• Confirm that the server is indeed the authorized server system.
• Confirm that the client is indeed an authorized client.

This enables the use of system or machine-level access controls that limit access to only authorized and authenticated machines. The local governance policies will determine whether machine level access control rules are used.

ATNA requires user AccessControl. User Access Control determines whether the user has access to particular information or system services. ATNA also requires that some form of user authentication be performed. It allows the system and deployment to choose an appropriate method, but all users shall be identified and authenticated. It uses these identities in the event audit log to identify users. It requires that access control use these identities (and other information) to determine what data and services are available to that user. Other system security services may also use the user identities.

IHE offers several profiles for different methods of user authentication. ATNA expects that local governance determines which methods of user authentication will be used. Use of the IHE profile methods such as XUA or EUA are not required. Other approaches are permitted.

For event audit logging, ATNA specifies:

• A standard schema for encoding a reported event
• Standard events to be reported:

• Events that are related to system activities, e.g., “Login Failure”.
• Events that are related to IHE transactions. These are described in the technical framework sections that describe the transaction.

• Two alternatives for transport of the event report from the reporting system to an Audit Record Repository.
• An Audit Record Repository for collecting and reporting on the event audit logs.

Secure Communications are provided by the use of TLS. TLS provides mutual authentication, reliable message transport and private communication through data encryption. Different forms of encryption can be negotiated to protect the data in transit. ATNA permits the negotiation of no encryption to accommodate sites that prefer to use a different form of protection.

ATNA does not restrict implementations and deployments to only use the ATNA specified methods. For interoperability reasons, TLS must be implemented and available to be configured. The RFC7525 “Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)” covers many configuration options. Deployments often follow these recommendations and make them part of their security policies. A deployment’s security analysis may lead to different choices. Therefore, it is important that implementations allow configuring different protocol versions, algorithms, etc.

Other equivalent methods may be chosen by deployments.

9.4.1 Concepts

Cybersecurity activities include a variety of operational, technical, and administrative activities. These are specified in some areas by law or regulation. All of the laws and regulations are consistent in requiring an overall governance model, various technical tools, and operational behaviors. The technical tool requirements always include system authentication, user authentication, event logging (audit), and telecommunications encryption. They also include many other technical features regarding access control, confidentiality, user administration, backups, etc. There are typically also significant operational and administrative requirements.

This profile specifies node authentication, user authentication, event logging (audit), and telecommunications encryption. It assumes that the ATNA actors will be installed into an environment that complies with all the other governance requirements. Compliance with the ATNA Profile alone, without also performing the other cybersecurity activities, is not sufficient to provide adequate cybersecurity.

9.4.1.1 Governance

The specific requirements for cybersecurity vary for different locations and purposes. The overall goals always include protecting confidentiality of data, integrity of data and systems, and availability of systems. The requirements affect:

• administrative policies, such as the policies to be used when authenticating and provisioning a new user,
• technical capabilities, such as performing real time access control, and
• operational activities, such as maintaining backup facilities and having continuity of service plans.

It is not practical or reasonable for IHE to profile those requirements. They are too varied, and cover much more than just interoperability of systems.

The ATNA Profile assumes that governance is established that is similar to the recommendations found in the NIST 500, 800, and 1800 series of publications on computer security and cybersecurity practices. These can be found at http://csrc.nist.gov/publications/PubsSPs.html .

9.4.1.2 Authentication

ATNA requires that both users and machines be authenticated.

9.4.1.2.1 Users

The specific method for user authentication is not specified by ATNA. IHE has profiles that specify particular kinds of user authentication. These can be used, as can other non-IHE methods for user authentication. What is important is that the authenticated identity of each user be available for purposes such as access control and event audit logging.

9.4.1.2.2 Machine to Machine Connections

ATNA specifies that connections between machines be authenticated and use TLS. Some sites prefer to use an alternative, so products can be configurable to use an equivalent alternative for those sites. The TLS machine authentication is based upon the use of public and private certificates. This is the method used to authenticate many financial transactions on the Internet.

Unlike the typical Internet browser setup, within a healthcare setting:

• Individual direct comparison for validation of certificates can be practical and appropriate. For example, it can be reasonable to use direct comparison and provide the public certificate for an Image Archive directly to each of the authorized users of the Image Archive.
• Chain of trust signed certificates can be practical and appropriate. It can be reasonable to have a hospital security system provide the trusted root authority for authenticating that a particular machine is an authenticated member of the hospital network.
• The commonly used root certificate authorities for browsers are much less likely to be appropriate for a chain of trust method. Their certificate policies are designed for financial risk reduction, not healthcare system authentication.

A means must be provided to install the required certificates to any ATNA implementation so that the systems can be configured to match the local governance. The common browser root certificate list is not sufficient.

9.4.1.3 Event Logging

ATNA event audit logging is intended to provide a surveillance logging function. This means that it captures:

• All security events that are detected.
• A full set of activity and transaction events describing ongoing operations. These are used to establish a baseline for what is normal operation, and are monitored for deviations from that baseline. The level of detail is subject to judgment. Details that do not matter in terms of establishing what is normal are left out, especially if they would reveal PHI.

The event logging is not designed for:

• Detailed forensic analysis, such as will be performed when surveillance reveals suspicious activity or after a security event is detected. This often needs to be at a level of detail that involves specific design aspects of specific products. ATNA expects that there is a forensic level log for products, and that those products document the design and specific details of their event reports. The forensic log may also use the ATNA schema and transactions, or it may be different.
• Workflow performance analysis log, such as is typical in tightly coordinated system controls. The ATNA events were chosen for privacy and security surveillance, not for system or staff performance purposes. A workflow analysis log may also use the ATNA schema and transactions, or it may be different.

9.4.1.3.1 Events

9.4.1.3.1.1 Activity

The ATNA Profile defines events related to activities of the IHE actors and system components that are grouped with a secure actor. These include events such as system startup, user login (both success and failure), access control violation, etc. ATNA requires that these be detected and reported.

These events are described in ITI TF-2: 3.20 . Further event description information may also be found in DICOM PS3.15 Annex A.5.

9.4.1.3.1.2 Transaction

IHE profiles that define transactions may define events and specify the event reporting structure for those events. These definitions are found in the Security Considerations section of transaction specifications in Volume 2 of the ITI Technical Framework and technical frameworks in other IHE domains

9.4.1.3.1.3 Product Specific

Individual products are permitted to report other events and use the DICOM event structure for this purpose. Audit Report Repositories shall accept any such reports into the repository.

9.4.1.3.2 Encoding

Events are encoded in accordance with DICOM PS3.15 Annex A.5. This is an extensible XML schema definition.

9.4.1.3.3 Transport

The ATNA Profile specifies the use of transports from DICOM PS3.15 Annex A.5. It specifies Syslog Protocols as the mechanism for logging audit record messages to the audit record repository.

There are two standard transports specified in ITI TF-2: 3.20 . The Audit Record Repository shall support both transports. The Secure Node and Secure Application implementations can choose either transport.

The choice of transport can be made to fit the needs of individual deployments and nodes. Both transports are widely used in the IT industry.

9.4.2 Use Cases

The security measures in the Audit Trail and Node Authentication Integration Profile are user authentication, node authentication, and generation of audit records. Node authentication and user authentication define a number of transactions that establish the concept of a Secure Node and a collection of connected Secure Nodes in a secure domain. Generation of audit records requires a set of audit trigger events and a definition of the content of the audit records. This profile specifies two acceptable message formats:

1. Messages formatted in accordance with the IHE Audit Message format. This is a combination of the DICOM Audit Messages format and IHE extensions.
2. The predecessor IHE Provisional Audit Message format. This format is preserved to provide backwards compatibility for older systems.

In the following paragraphs three typical process flows are described for situations in which authorized users, unauthorized users, and unauthorized nodes attempt to gain access to protected health information (PHI).

9.4.2.1 Normal Node Process Flow

The following scenario shows how the IHE security measures operate for authorized access to PHI from an authorized node in the network:

1. Time synchronization occurs independently. These transactions may take place at any time. Correct time is needed to generate audit records with a correct timestamp.
2. A user logs on to Image Display.
   The user enters valid credentials and is authorized to access the node.
3. The Image Display generates audit records.
4. The user wants to query/retrieve and view some images.
   Before image transactions can take place, an authentication process between the Image Display and the Image Manager takes place.
5. Following node authentication, the Image Display initiates the query/retrieve transactions.
6. The Image Display and Image Manager generate audit records.

9.4.2.2 Unauthorized Node Process Flow

The following scenario shows how the IHE security measures help to prevent unauthorized access to PHI from an unauthorized node in the network:

1. An unauthorized node tries to query the Lab Automation Manager/Secure Node for information. This fails because no authentication has taken place, and an audit record is generated.
2. The unauthorized node tries an authentication process with the Lab Automation Manager/Secure Node. This fails because the Lab Automation Manager/Secure Node will not trust the certificate presented by the Malicious Node, and an audit record is generated.

Note that the sequencing of the transactions is just one example. Transactions from an unauthorized node are totally unpredictable and may happen in any order.

9.4.2.3 Unauthorized User Process Flow

The following scenario shows how the IHE security measures help to prevent unauthorized access to PHI from an unauthorized user in the healthcare enterprise:

1. An unauthorized user tries an authentication process with the ECG Display/Secure Node Actor. This fails because the ECG Display/Secure Node detects that the user name and credentials presented are not valid at this secure node, and an audit record is generated.

9.5 ATNA Security Considerations

See Section 9.4.

9.6 ATNA Cross Profile Considerations

The ITI Technical Framework includes a variety of profiles for other security related purposes. There are also security related aspects of other profiles. For example, the SOAP transport can convey user identification and authentication information.

These profiles may depend upon the underlying system being a Secure Node or a Secure Applications.