Difference between revisions of "Audit Trail and Node Authentication"

From IHE Wiki
Jump to navigation Jump to search
(46 intermediate revisions by 7 users not shown)
Line 1: Line 1:
−
Audit Trail and Node Authentication [ATNA] describes certificate-based node authentication and transmitting PHI-related audit events to a repository. This helps sites implement confidentiality policies.
+
__TOC__
  
  
−
__TOC__
+
==Summary==
 +
 
 +
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.
 +
 
 +
==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).
  
  
−
==Summary==
+
==Systems Affected==
  
−
The Audit Trail and Node Authentication (ATNA) Integration Profile establishes security measures which, together with the Security Policy and Procedures of the enterprise, provide patient information confidentiality, data integrity and user accountability. 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, and requires that events concerning PHI use are recorded and transmitted to a repository where they can be monitored to detect indications of inappropriate activity.
+
Systems involved in this profile are:
  
 +
* Any local or enterprise-wide healthcare information systems that manage or process Protected Health Information
  
−
''<Include a simple graphic that, at a glance, gives an impression of what the profile does.  See [[Help:Contents#Tips_.26_Tricks| Help - Tips and Tricks]] for details on including an image/graphic.>''
 
  
−
==Benefits==
+
'''Actors & Transactions:'''
  
 +
[[Image:ATNA-Actor-Transaction.jpg]]
  
−
==Details==
+
==Specification==
−
(From an email by Rob Horn)
 
  
−
ATNA is already integrated into the full ITI Technical
+
'''Profile Status:''' [[Comments| Final Text]]  
−
Framework.  The ATNA core is section 9 of volume 1, and sections 3.16 and
 
−
3.17 of Volume II.  The underlying DICOM standard can be be found at:  
 
−
ftp://medical.nema.org/medical/dicom/supps/sup95_fz.pdf  The underlying
 
−
RFC can be found at a variety of RFC repositories.  ATNA specializes these
 
−
for some purposes, but also invokes their general support so that we don't
 
−
have to redefine ATNA every time a new profile specializes an audit
 
−
message for some new purpose. There are individual profile
 
−
specializations scattered through all the different frameworks. This makes
 
−
it hard for an implementer.  It's easy to pull out the core sections as a
 
−
starting point, but not the individual profile specializations.
 
  
−
You find sections of specializations in some of the other technical
+
'''Documents:'''
−
frameworks. Radiology is probably the most complete for this. This
+
[http://www.ihe.net/Technical_Framework/index.cfm#IT IHE IT Infrastructure Technical Framework Version 2 or later]
−
scattering of requirements  reflects a fundamental conflict of
+
:* [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf#nameddest=30_Cross_Enterprise_Document_Won Vol. 1 - Section 9]
−
documentation uses. From one perspective you would like it all in one
+
:* [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2a.pdf#nameddest=3_19_Authenticate_Node__ITI_19_ Vol. 2a - Sections 3.19],  
−
place, and from another prespective you want it documented in the sections
+
:* [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]
−
that will actually be read by implementers.  
 
  
−
There is also some historical funny business.  Originally HL7 was going to
 
−
issue an HL7 side equivalent to DICOM's Supplement 95, but that lost
 
−
sponsorship and got abandoned.  So DICOM threw together some partial stuff
 
−
to cover the immediate needs of the imaging community.  It deals with only
 
−
those HL7ish things that happen to DICOM equipment (like receiving
 
−
orders).  DICOM didn't attempt to handle the rest of the HL7 world.  So
 
−
the various IHE domains get creative in a variety of ways.
 
  
−
==Systems Affected==
+
'''Underlying Standards:'''
−
''<List (in user terms) systems that would be likely candidates for implementing this profile, e.g. RIS, PACS, HIS, CAD Workstation, etc. >''
+
:* 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/
  
−
==References==
+
===Additional Supplements:===
 +
* [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_RESTful-ATNA.pdf Add RESTful Query to ATNA] - Trial Implementation
  
−
Creating an IHE ATNA-Based Audit Repository, Gregg, B. et al, Journal of Digital Imaging, Vol. 19, Number 4, 2006, pp. 307-315
+
'''Underlying Standards:'''
 +
* HL7 FHIR STU3 http://hl7.org/fhir/STU3
 +
** AuditEvent
 +
** Bundle
  
 
==See Also==
 
==See Also==
−
Profile Status: [[Comments| Final Text]]
 
  
−
The [[Frameworks#IHE IT Infrastructure Technical Framework| IT Infrastructure Technical Framework]] is the official master document for this Profile.  
+
This profile supports the security/privacy model discussed in [[IHE Security and Privacy for HIE]] white paper.
 +
 
 +
See [[ATNA FAQ]] for implementation assistance, and [[ATNA Profile FAQ]] for other random help.
  
−
''<Replace the Template links below with links to the actual pages for the Profile>''
+
The 2008 connectathon tests for XDS related actors can be found at http://ihewiki.wustl.edu/wiki/index.php/XDS_Syslog_testing_requirements#Audit_log_requirements_for_XDS_at_2008_Connectathon
  
−
The [[ATNA Profile FAQ]] answers typical questions about what the Profile does.
+
[http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf NIST SP800-92 Guide to Computer Security Log Management]
  
−
The [[Profile Purchasing Template]] describes considerations when purchasing equipment to deploy this Profile.
+
NEMA White Paper on [http://www.medicalimaging.org/wp-content/uploads/2011/02/CertificateManagement-2007-05-Published.pdf Management of Machine Authentication Certificates]
  
−
[[Audit Trail and Node Authentication Implementation]] provides additional information about implementing this Profile in software.  Specific questions about how to implement this profile can be found in the [[ATNA FAQ]].
+
'''Related Profiles'''
  
 +
* [[Audit Trail and Node Authentication - Radiology Option]] extends ATNA with Radiology-specific audit trail messages.
 +
* [[Consistent_Time | Consistent Time]]
  
 
This page is based on the [[Profile Template]]
 
This page is based on the [[Profile Template]]
  
 +
[[Category:Profiles]]
 +
[[Category:ITI Profile]]
 +
[[Category:FHIR]]
 +
[[Category:Security]]
  
−
[[Category:Profiles]]
+
Current: [[Frameworks#IHE IT Infrastructure Technical Framework| IT Infrastructure Technical Framework]].

Revision as of 09:24, 29 August 2017


Summary

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.

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).


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:

ATNA-Actor-Transaction.jpg

Specification

Profile Status: Final Text

Documents: IHE IT Infrastructure Technical Framework Version 2 or later


Underlying Standards:

Additional Supplements:

Underlying Standards:

See Also

This profile supports the security/privacy model discussed in IHE Security and Privacy for HIE white paper.

See ATNA FAQ for implementation assistance, and ATNA Profile FAQ for other random help.

The 2008 connectathon tests for XDS related actors can be found at http://ihewiki.wustl.edu/wiki/index.php/XDS_Syslog_testing_requirements#Audit_log_requirements_for_XDS_at_2008_Connectathon

NIST SP800-92 Guide to Computer Security Log Management

NEMA White Paper on Management of Machine Authentication Certificates

Related Profiles

This page is based on the Profile Template

Current: IT Infrastructure Technical Framework.

Retrieved from "http://wiki.ihe.net/index.php?title=Audit_Trail_and_Node_Authentication&oldid=104017"