Difference between revisions of "Audit Trail and Node Authentication"

Latest revision as of 11:46, 19 November 2021

Basic security through (a) functional access controls, (b) defined security audit logging and (c) secure network communications

Formal Specification

ATNA (html) specification

Final Text

Additional Supplements:

Add RESTful Query and Feed to ATNA - Trial Implementation

@@ Line 1: / Line 1: @@
+Basic security through (a) functional access controls, (b) defined security audit logging and (c) secure network communications
 __TOC__
+==Formal Specification==
-==Summary==
+===[https://profiles.ihe.net/ITI/TF/Volume1/ch-9.html ATNA (html) specification]===
+* [https://profiles.ihe.net/ITI/TF/Volume1/ch-9.html Final Text]
-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.
-Note Trial Implementation addition of FHIR support in [[Add RESTful Query and Feed to ATNA]] -- [https://youtu.be/dGIgCLU91Go Youtube introduction to this supplement]
-==Benefits==
-'''Assistance to sites in implementing security and confidentiality policies'''
-* This model is partially driven by the underlying assumption that there will be situations where documents are being exchanged between machines and stored on the recipient. This is partly driven by the need for healthcare systems to operate in disasters and overload situations, where the network operation is limited or destroyed. It is not safe to assume that clients are display only. So there will be semi-permanent copies of most information kept. Even in normal operation, healthcare providers may have only 15 minutes per patient. Good healthcare system design recognizes the need to not waste any of those seconds searching and transferring documents over a network. The documents are transferred in advance, and are kept locally until it is determined that they are no longer needed. There are thin client display only applications in healthcare, but they are limited to uses that can fail without introducing risks to safety or patient health, but a complete security/privacy design requires handling situations where data is stored after retrieval.
-==Details==
-The '''Audit Trail and Node Authentication (ATNA) Integration Profile''':
-contributes to access control by limiting network access between nodes and limiting access to each node to authorized users. Network communications between secure nodes in a secure domain are restricted to only other secure nodes in that domain. Secure nodes limit access to authorized users as specified by the local authentication and access control policy.
-* User Authentication
-The Audit Trail and Node Authentication Integration Profile requires only local user authentication. The profile allows each secure node to use the access control technology of its choice to authenticate users. The use of Enterprise User Authentication is one such choice, but it is not necessary to use this profile.
-* Connection Authentication
-The Audit Trail and Node Authentication Integration Profile requires the use of bi-directional certificate-based node authentication for connections to and from each node. The DICOM, HL7, and HTML protocols all have certificate-based authentication mechanisms defined. These authenticate the nodes, rather than the user. Connections to these machines that are not bi-directionally node-authenticated shall either be prohibited, or be designed and verified to prevent access to PHI.
-* Audit Trails
-User Accountability is provided through Audit Trail. The Audit Trail needs to allow a security officer in an institution to audit activities, to assess compliance with a secure domain’s policies, to detect instances of non-compliant behavior, and to facilitate detection of improper creation, access, modification and deletion of Protected Health Information (PHI).
-===Options===
-====Secure Transport Options====
-Update in 2019 by [https://gazelle.ihe.net/files/CP-ITI-1151-04-ballot54.pdf CP-ITI-1151] adds a set of comprehensive secure transport (STX) options :
-* STX: No Secure Transport Option
-* STX: TLS 1.0 Floor with AES Option
-* STX: TLS 1.0 Floor using BCP195 Option
-* STX: TLS 1.2 Floor using BCP195 Option
-* STX: S/MIME
-* STX: WS-Security
-a 'system' must choose at least one of the "STX" options, but is expected to declare in the [[Integration Statement]] as many configurations as the system can support. The specific configuration used in a deployed environment will be a policy choice.
-Historically these alternatives have not been clear. A system could have had no secure transport as they expected it to be used on a secure network (a configuration often found in Imaging devices), however many Cross-Enterprise systems were expected to support TLS 1.0 with AES. Thus now an [[Integration Statement]] must declare transparently what it can support.
-====Audit Record Options====
-In the [[Add RESTful Query and Feed to ATNA]] supplement has options for the Secure Node, Secure Application, Audit Record Repository, and Audit Record Forwarded to enable those actors to more precisely specify the Audit Transport (ie "ATX") that they use to send audit messages.  These actors must support one or more of these options:
-* ATX: FHIR Feed Option
-* ATX: TLS Syslog Option
-* ATX: UDP Syslog Option
-====Other====
-* FQDN Validation of Server Certificate Option
-==Systems Affected==
-Systems involved in this profile are:
-* Any local or enterprise-wide healthcare information systems that manage or process Protected Health Information
-'''Actors & Transactions:'''
-[[Image:ATNA-Actors.png]]
-==Specification==
-'''Profile Status:''' [[Comments| Final Text]]
-'''Formal Specification:'''
-[http://www.ihe.net/Technical_Framework/index.cfm#IT IHE IT Infrastructure Technical Framework Version 2 or later]
-:* [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf#nameddest=9__Audit_Trail_and_Node_Authent Vol. 1 - Section 9 - Audit Trail and Node Authentication (ATNA) Profile]
-:* [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2a.pdf#nameddest=3_19_Authenticate_Node__ITI_19_ Vol. 2a - Sections 3.19 - Authenticate Node],
-:* [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2a.pdf#nameddest=3_20_Record_Audit_Event__ITI_20 Vol. 2a - Sections 3.20 - Record Audit Event]
-'''Underlying Standards:'''
-:* Secure Communications
-:** [http://www.ietf.org/rfc/rfc2246.txt RFC 2246 Transport Layer Security (TLS) 1.0]
-:** [http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html WS-I Basic Security Profile 1.1]
-:** [http://www.ietf.org/rfc/rfc3851.txt RFC 3851 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification]
-:** Encryption at least AES
-:** Integrity at least SHA1 (HMAC or CBC)
-:** Authentication at least RSA X.509
-:** Certificate encoded using at least BER and DER
-:** Certificate validation required with support of both Direct Certificate and Chain of Trust to certificate Authority
-:** Management of Trust is not further automated (see PWP and HPD profiles)
-:* Audit Log Transport
-:** RFC 5424 The Syslog Protocol
-:** RFC 5425 Transmission of Syslog Messages over TLS
-:** RFC 5426 Transmission of Syslog Messages over UDP
-:** former -- IETF: The BSD Syslog Protocol. (RFC 3164)
-:* Audit Log Message
-:** Normative Specification for the Audit Log Message including Schema [http://medical.nema.org/medical/dicom/current/output/html/part15.html#sect_A.5 DICOM PS3.15 A.5]
-:** Old Resources for historic reference
-:*** Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications (RFC 3881).
-:*** Currently being moved into ISO through TC 215 as (ISO/WD 27789)
-:*** RFC 3881 schema http://www.xml.org/xml/schema/7f0d86bd/healthcare-security-audit.xsd  --- REMOVED BY XML.ORG
-:*** [http://medical.nema.org/standard.html DICOM - 2011  PS 3.15 (Part 15), Annex A.5 (ISO 12052)] ([ftp://medical.nema.org/medical/dicom/2011/ ftp]) -- Originally described by [[DICOM Supplement 95 | Supplement 95]]
-:** DICOM OIDs for codeSystems used https://www.dabsoft.ch/dicom/6/A/
 ===Additional Supplements:===
 * [[Add RESTful Query and Feed to ATNA]] - Trial Implementation
-'''Underlying Standards:'''
-* HL7 FHIR R4 http://hl7.org/fhir/R4
-** AuditEvent
-** Bundle
 ==See Also==

Difference between revisions of "Audit Trail and Node Authentication"

Latest revision as of 11:46, 19 November 2021

Contents

Formal Specification

ATNA (html) specification

Additional Supplements:

See Also

Navigation menu

Search