Audit Trail and Node Authentication / Consistent Time Robert Horn Agfa Healthcare
Mar 27, 2015
Audit Trail and Node Authentication / Consistent Time
Audit Trail and Node Authentication / Consistent Time
Robert HornAgfa Healthcare
June 28-29, 2005 Interoperability Strategy Workshop2
W W W . I H E . N E TW W W . I H E . N E T
Providers and VendorsWorking Together to Deliver
Interoperable Health Information SystemsIn the Enterprise
and Across Care Settings
June 28-29, 2005 Interoperability Strategy Workshop3
IT Infrastructure ProfilesIT Infrastructure Profiles
2004 Patient Identifier Cross-referencing for MPI (PIX) Retrieve Information for Display (RID) Consistent Time (CT) Patient Synchronized Applications (PSA) Enterprise User Authentication (EUA)
2005Patient Demographic Query (PDQ) Cross Enterprise Document Sharing (XDS)Audit Trail and Note Authentication (ATNA)Personnel White Pages (PWP)
2006Cross-Enterprise User Authentication (XUA)Document Digital Signature (DSG) – Notification of Document Availability (NAV)Patient Administration/Management (PAM)
Audit Trail and Node Authentication (ATNA) –
Centralized privacy audit trail and node to node authentication to
create a secured domainConsistent Time (CT) – Coordinate
time across network systems
June 28-29, 2005 Interoperability Strategy Workshop4
IHE and PHI ProtectionIHE and PHI Protection
• User Identity → PWP, EUA• User Authentication → EUA, XUA• Node Authentication → ATNA• Security Audit Trails → ATNA• Data Integrity Controls → CT, ATNA TLS option• Data Confidentiality → ATNA TLS option• Access Controls → Future item in IHE roadmap
June 28-29, 2005 Interoperability Strategy Workshop5
Audit Trail and Node Authentication (ATNA)Audit Trail and Node Authentication (ATNA)Abstract / ScopeAbstract / Scope
• Defines basic security features for an individual system for use as part of the security and privacy environment for a healthcare enterprise.
• Extends the IHE radiology oriented Basic Security profile (defined in 2002) to be applicable to other healthcare uses.
• Provides host level authentication, which is used in conjunction with the user authentication from EUA and XUA.
June 28-29, 2005 Interoperability Strategy Workshop6
ATNAATNAValue PropositionValue Proposition
• Protect Patient Privacy and System Security:– Meet ethical and regulatory requirements
• Enterprise Administrative Convenience:– Unified and uniform auditing system– Common approach from multiple vendors simplifies definition
of enterprise policies and protocols.– Common approach simplifies administration
• Development and support cost reduction through Code Re-use:– Allows vendors to leverage single development effort to
support multiple actors– Allows a single development effort to support the needs of
different security policies and regulatory environments.
June 28-29, 2005 Interoperability Strategy Workshop7
ATNAATNASecurity RequirementsSecurity Requirements
• Reasons: Clinical Use and Privacy– authorized persons must have access to medical data of
patients, and the information must not be disclosed otherwise.– Unauthorized persons should not be able to interfere with
operations or modify data
• By means of procedures and security mechanisms, guarantee:– Confidentiality– Integrity– Availability– Authenticity
June 28-29, 2005 Interoperability Strategy Workshop8
ATNAATNASecurity MeasuresSecurity Measures
• Authentication:Authentication: Establish the user and/or system identity, answers question: “Who are you?”
• ATNA defines: How to authenticate network connections.• ATNA Supports: Authentication mechanisms, e.g. Enterprise User
Authentication (EUA) or Cross Enterprise User Authentication (XUA)..
• Authorization and Access control:Authorization and Access control:Establish user’s ability to perform an action, e.g. access to data, answers question: “Now that I know who you are, what can you do?”
• ATNA defines: How to authorize network connections.• ATNA requires: System internal mechanisms for both local and
network access.
June 28-29, 2005 Interoperability Strategy Workshop9
ATNAATNASecurity MeasuresSecurity Measures
• Accountability and Audit trail:Accountability and Audit trail:Establish historical record of user’s or system actions over period of time, answers question: “What have you done?”
• ATNA Defines: Audit message format and transport protocol
June 28-29, 2005 Interoperability Strategy Workshop10
ATNAATNAIHE GoalIHE Goal
• IHE makes cross-node security management easy:– Only a simple manual certificate installation is needed,
although more sophisticated systems can be used
– Separate the authentication, authorization, and accountability functions to accommodate the needs of different approaches.
– Enforcement driven by ‘a posteriori audits’ and real-time visibility.
June 28-29, 2005 Interoperability Strategy Workshop11
ATNAATNAIntegrating Trusted NodesIntegrating Trusted Nodes
System A System B
Secured SystemSecure network
• Strong authentication of remote node (digital certificates)• network traffic encryption is not required, it is optional
Secured System
• Local access control (authentication of user)
• Audit trail with:• Real-time access • Time synchronization
Central Audit TrailRepository
June 28-29, 2005 Interoperability Strategy Workshop12
ATNAATNASuitable Network EnvironmentsSuitable Network Environments
• Physically secured networks• Explicit physical security preventing access by other nodes, or• VPN and VLAN technologies that provide equivalent network
isolation.
• Protected networks• Physical security that prevents modification or installation of
unauthorized equipment• The network is shared with other authorized nodes within the
enterprise that should not have unrestricted access to patient information.
• Unprotected networks• Not generally supported, although nodes with sufficient node level
security and using encryption may be safe.
June 28-29, 2005 Interoperability Strategy Workshop13
ATNAATNANode SecurityNode Security
• ATNA specifies some of the capabilities that are needed, e.g. access control.
• ATNA does not specify policies• ATNA does not specify mechanisms, although other
IHE protocols like EUA are obvious candidates.
• This permits vendors and enterprises to select technologies and policies that are appropriate to their own purposes without conflicting with the ATNA profile.
June 28-29, 2005 Interoperability Strategy Workshop14
ATNAATNANode AuthenticationNode Authentication
• X.509 certificates for node identity and keys• TCP/IP Transport Layer Security Protocol (TLS) for
node authentication, and optional encryption• Secure handshake protocol of both parties during
Association establishment:– Identify encryption protocol– Exchange session keys
• Actor must be able to configure certificate list of authorized nodes.
• ATNA presently specifies mechanisms for HTTP, DICOM, and HL7
June 28-29, 2005 Interoperability Strategy Workshop15
• Many systems are shared access, e.g. CT systems, where the machine identity is more important than the operator’s identity for security purposes.
• A CT operator is only permitted to update CT records from a CT system.
• Some systems operate autonomously, e.g. PACS archive.• Knowing identity of the PACS administrator on duty is not useful
when monitoring PACS activity. There might be nobody logged in.
• Machine access is usually controlled by the site administration.
• Even authorized users are not permitted to use personal machines.
Why node authentication?Why node authentication?
June 28-29, 2005 Interoperability Strategy Workshop16
ATNAATNAAuditing SystemAuditing System
• Designed for surveillance rather than forensic use.• Two audit message formats
– IHE Radiology interim format, for backward compatibility with radiology
– IETF/DICOM/HL7/ASTM format, for future growth• DICOM Supplement 95• IETF Draft for Common Audit Message• ASTM E.214• HL7 Audit Informative documents
• Both formats are XML encoded messages, permitting extensions using XML standard extension mechanisms.
June 28-29, 2005 Interoperability Strategy Workshop17
ATNAATNAAuditable EventsAuditable Events
Actor-start-stop The starting or stopping of any application or actor.
Audit-log-used Reading or modification of any stored audit log
Begin-storing-instances The storage of any persistent object, e.g. DICOM instances, is begun
Health-service-event Other health service related auditable event.
Images-availability-query The query for instances of persistent objects.
Instances-deleted The deletion of persistent objects.
Instances-stored The storage of persistent objects is completed.
June 28-29, 2005 Interoperability Strategy Workshop18
ATNAATNAAuditable EventsAuditable Events
Medication Medication is prescribed, delivered, etc.
Mobile-machine-event Mobile equipment is relocated, leaves the network, rejoins the network
Node-authentication-failure
An unauthorized or improperly authenticated node attempts communication
Order-record-event An order is created, modified, completed.
Patient-care-assignment Patient care assignments are created, modified, deleted.
Patient-care-episode Auditable patient care episode event that is not specified elsewhere.
Patient-record-event Patient care records are created, modified, deleted.
June 28-29, 2005 Interoperability Strategy Workshop19
ATNAATNAAuditable EventsAuditable Events
PHI-export Patient information is exported outside the enterprise, either on media or electronically
PHI-import Patient information is imported into the enterprise, either on media or electronically
Procedure-record-event The patient record is created, modified, or deleted.
Query-information Any auditable query not otherwise specified.
Security-administration Security alerts, configuration changes, etc.
Study-object-event A study is created, modified, or deleted.
Study-used A study is viewed, read, or similarly used.
June 28-29, 2005 Interoperability Strategy Workshop20
ATNAATNARecord Audit EventRecord Audit Event
• Reliable Syslog (RFC 3195) is the preferred transport for Audit Records, although BSD Syslog protocol (RFC 3164) is permitted for backward compatibility with Radiology Basic Security.
• Audit trail events and content based on IETF, DICOM, HL7, and ASTM standards. Also, Radiology Basic Security audit event format is allowed for backward compatibility.
June 28-29, 2005 Interoperability Strategy Workshop21
What it takes to be a secure nodeWhat it takes to be a secure node
• The entire host must be secured, not just individual actors.
• The entire host must have appropriate user access controls for identification, authentication, and authorization.
• All communications that convey protected information must be authenticated and protected from interception. This means every protocol, not just the IHE transactions.
• All health information activities should generate audit trails, not just the IHE actors.
June 28-29, 2005 Interoperability Strategy Workshop22
What it takes to be a secure nodeWhat it takes to be a secure node
• The Secure node is not a simple add-on of an auditing capability. The complete work effort includes:
• Instrumenting all applications to detect auditable events and generate audit messages.
• Ensuring that all communications connections are protected.• Establishing a local security mechanism to protect all local
resources.• Establishing configuration mechanisms for:
– Time synchronization using Consistent Time (CT) profile– Certificate management– Network configuration
• Implement the audit logging facility
June 28-29, 2005 Interoperability Strategy Workshop23
Consistent Time (CT)Consistent Time (CT)
• Network Time Protocol ( NTP) version 3 (RFC 1305) for time synchronization
• Actor must support manual configuration
• Required accuracy: 1 second
• Optionally Secure NTP may be used
• Required for use of ATNA, EUA, XUA
June 28-29, 2005 Interoperability Strategy Workshop24
More information….More information….
• IHE Web sites: www.ihe.net• Technical Frameworks, Supplements
• ITI V1.0, RAD V5.5, LAB V1.0
• Non-Technical Brochures :• Calls for Participation
• IHE Fact Sheet and FAQ
• IHE Integration Profiles: Guidelines for Buyers
• IHE Connect-a-thon Results
• Vendor Products Integration Statements