ATNA format - IHE Product Registry

advertisement
Audit Trail and Node
Authentication
G. Claeys, Agfa Healthcare
(geert.claeys@agfa.com)
September, 2005
1
What IHE Delivers
Scope
Defines basic security features for a system in a
healthcare enterprise in order to guarantee :
 Only authorized persons have access to PHI (Protected
Health Information)
 Protect PHI against alteration, destruction and loss
 Comply existing Privacy & Security regulations
Extends the IHE radiology oriented Basic Security
profile (2002) to be applicable to other healthcare
uses.
2
Security Mechanism
Authentication (user and device)
ATNA, EUA
Authorization
Accountability (audit trails)
ATNA
Confidentiality
ATNA
Integrity
ATNA
3
IHE ATNA- Architecture
• Local authentication of user
• Strong authentication of remote node (digital certificates)
• Audit trail that logs privacy&security related operations
Secured System
Secured System
Secure network
System B
System A
Central
Audit Trail
Repository
4
IHE ATNA – Actor and Transactions
All existing IHE actors need to be grouped with a Secure
Node actor.
Time Server
Audit Record
Repository
Maintain Time
Record Audit Event
Secure Node
Authenticate Node
Secure Node
“Any”
IHE actor
5
Secure Node
Local user authentication
 Only needed at “client” node
 Authentication mechanism
•
•
User name and password (minimum)
Biometrics, smart card
 Secure nodes maintain list of authorized users :
local or central (using EUA)
 Security policy of hospital defines the relation
between user and user id
6
Secure Node (cont.)
Mutual device authentication
 Establish a trust relationship between 2 network nodes
 Strong authentication by exchanging X.509 certificates
 Actor must be able to configure certificate list of trusted nodes.
TCP/IP Transport Layer Security Protocol (TLS)
 Used with DICOM/HL7/HTTP messages
 Secure handshake protocol during Association establishment:
 Encryption :
•
Intra-muros (default): no encryption
•
Extra-muros : AES128
TLS/SSL negotiations problems were detected at
connectathon 2006 USA
 Caused by incorrect configuration of SSL/TLS packages (e.g.
STunnel)
 Guidelines will follow
7
Secure node – additional effort
Instrument all applications to detect auditable
events and generate audit messages.
Ensure that all communications connections are
protected (system hardening).
Establish a local security mechanism to protect
all local resources
Establish configuration mechanisms for:
 Time synchronization
 Certificate management
 Network configuration
8
Certificate Management
Certificates can be signed by device (self-signing)
or via a CA (e.g. hospital)
 Use self-signed certificates for testing interoperability
 Connectathon has a CA
Support at least direct comparison of certificates
 Import certificate of each trusted peer device
 Compare each received certificate with list of trusted
certificate
Certificate management white paper
 from NEMA’s Security&Privacy committee
 www.nema.org/prod/med/security
9
Auditing System
Auditing system consists of
 List of events that generate audit messages
 Audit message format
 Transport mechanism
Designed for surveillance rather than
forensic use.
10
Audit Events
Audit triggers are defined for every
operation that access PHI (create, delete,
modify, import/export)
IHE TF describes the supported Audit
Trigger per Actor
Audit triggers are grouped on transaction/
study level to minimize overhead
11
Audit Message Format
XML encoded message
IHE Radiology Provisional format
 for backward compatibility with radiology
ATNA format
 Preferred format
 Joint effort of IETF/DICOM/HL7/ASTM
 XML schema (rfc3881) :
www.xml.org/xml/schema/7f0d86bd/healthcare-securityaudit.xsd
XSLT transformation is provided to convert
“Provisional scheme” to “ATNA” scheme
12
Audit Transport Mechanism
Reliable Syslog – cooked mode
 RFC 3195
 Connection oriented
 Support certificate based authentication,
encryption
 But limited industry support
BSD Syslog protocol (RFC 3164)
 Preferred transport mechanism for the time being
13
Backward compatibility
ATNA is backward compatible with Basic Security
(IHE Radiology)
 Basic security = Provisional XML scheme + BSD syslog
 Applications, supporting Basic Security are ATNA compliant
Basic security is deprecated
 Basic Security Profile being deprecated by Radiology Option
for ATNA
 No further extensions
 New applications are encouraged to use new message
format
14
Audit system - lessons learned
BSD Syslog
 Ensure that the BSD header format is correct, otherwise the
messages may get trashed.
 BSD Syslog messages longer than 1k may get truncated
•
-> keep the messages short
Date/Time : UTC format
 EventDateTime="2006-01-17T17:01:25-06:00“ or
 EventDateTime="2006-01-17T17:01:25-06:00Z“
Patient ID
 Use either the MRN (preferred) or a properly defined local
Patient ID.
 Patient Names can be arbitrary format.
15
Audit system - lessons learned (cont.)
Active Participant Identification
 Use one ActiveParticipant per event
 Use an identifiable user as ActiveParticipant
 If not possible then use the node/process as
ActiveParticipant
Node names
 Use host names instead of ip addresses
Audit Source Id :
 hostname or stationName
16
Audit system - lessons learned (cont.)
Event Identification (EventID):
 use DCM code set (DICOM supplement 95) or IHE
code set (ATNA)
 avoid proprietary values.
Schema checking
 Ensure that the messages conform to the schema
defined in RFC3881
 Do not include schema items with null contents.
17
www.ihe-europe.org
Frequently Asked Questions
Integration Profiles in Technical Frameworks:





Cardiology
IT Infrastructure
Laboratory
Patient Care Coordination
Radiology
Connectathon Results
Vendor Products Integration Statements
Participation in Committees & Connectathons
18
Download