1 / 24

ITI Security Profiles – ATNA, CT

ITI Security Profiles – ATNA, CT. IHE Education Workshop 2007 IHE IT Infrastructure Education John Moehrke GE Healthcare. IHE Security Profiles. 2004 Consistent Time (CT) Enterprise User Authentication (EUA) 2005 Audit Trail and Note Authentication (ATNA) Personnel White Pages (PWP)

cstacey
Télécharger la présentation

ITI Security Profiles – ATNA, CT

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ITI Security Profiles – ATNA, CT IHE Education Workshop 2007 IHE IT Infrastructure Education John Moehrke GE Healthcare

  2. IHE Security Profiles 2004 Consistent Time (CT) Enterprise User Authentication (EUA) 2005 Audit Trail and Note Authentication (ATNA) Personnel White Pages (PWP) 2006 Document Digital Signature (DSG) Basic Patient Privacy Consents (BPPC) 2007 Cross-Enterprise User Assertion (XUA) White Papers Health Information Exchange secured with IHE Risk Management in Profile Development

  3. IHE and PHI Protection • User Identity → PWP, EUA • User Authentication → EUA, XUA • Node Authentication → ATNA • Security Audit Trails → ATNA • Data Integrity Controls → CT, ATNA, DSG • Data Confidentiality → ATNA, BPPC • Access Controls → Future item in IHE roadmap

  4. ATNA Assets protected • Patient and Staff Safety • ATNA provides minor protections by restricting network access • Most safety related protection is elsewhere in products. Security activity must not interfere with safety. • Patient and Staff Health • As with Safety, ATNA provides minor health protection and must not interfere. • Patient and Staff Privacy • Access Control at the node level can be enforced. • Audit Controls at the personal level are supported. • Note that in Europe there are significant staff privacy protections, not just patient privacy protections, in the laws.

  5. ATNA Security 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

  6. ATNA Security Measures (1 of 3) Node Authentication: Establish the system identity of network transactions. How to authenticate network connections. How to protect the integrity of the transaction Optionally: How to protect the confidentiality of the transaction Mutually Authenticated TLS

  7. ATNA Security Measures (2 of 3) Authorization and Access control: Establish user’s ability to perform an action, e.g. access to data User Authentication: e.g. Enterprise User Authentication (EUA) or Cross Enterprise User Authentication (XUA).. User Authorizations: e.g. Role-based-access-control System internal mechanisms

  8. ATNA Security Measures (3 of 3) Accountability and Audit trail:Establish historical record of user’s or system actions over period of time, answers question: “What have you done?” List of security audit events message format to describe an event and transport protocol

  9. ATNA Node 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.

  10. Why Node Authentication • 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.

  11. X - ATNA IHE 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.

  12. Local access control (authentication of user) • Strong authentication of remote node (digital certificates) • network traffic encryption is not required, it is optional • Audit trail with: • Real-time access • Time synchronization Secured System Secured System Secure network System B System A Central Audit TrailRepository ATNA Integrating Trusted Nodes

  13. ATNA Node 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

  14. ATNA Node Authentication • TLS Encryption options: • IHE mandates a minimum mandatory set to ensure that a compatible pair will exist. • Additional encryption options may be implemented • TLS specifies how the encryption will be selected from the proposed list. It need not be one of the IHE minimum set. • Some environments permit NULL encryption (e.g., internal radiology operations). Others do not (e.g., XDS). • ATNA presently specifies mechanisms for using TLS with HTTP, DICOM, and HL7. • DICOM toolkits incorporate TLS support • Some HL7 libraries incorporate TLS support • Some web servers (e.g. Tomcat, Apache) incorporate TLS support.

  15. ATNA Auditing System • Designed for surveillance rather than forensic use. This is not a substitute for internal product detailed logs. • Two audit message formats. • IHE Radiology interim format, for backward compatibility with radiology • IETF/DICOM/HL7/ASTM format, for future growth • IETF RFC 3881 Common Audit Message • DICOM Supplement 95 • ASTM E.214 • HL7 Audit Informative documents • ISO Standardization in process • New profile work will utilize the new schema for messages, so use the new schema unless there is a product need for compatibility with the Radiology interim format.

  16. ATNA Auditing System • Both formats are XML encoded messages, permitting extensions using XML standard extension mechanisms. • Do not redefine current attributes or elements • Only extend when existing attributes or elements are insufficient • Document the source schema for extensions and make it freely available because audit repositories will need it. • If there might be messages using different schema from a single system, use the source field in the syslog message to distinguish the format. All messages from a specific source must use the same schema.

  17. ATNA Record Audit Event • BSD Syslog protocol (RFC 3164) will be part of the Connectathon infrastructure. • Support messages up to 32768 bytes long. • Clients should be configurable to send to any port and destination. • IETF continues to resolve issues surrounding Reliable Syslog (RFC 3195). There will be no connectathon support of testing Reliable Syslog, but private testing may take place. • Possibility is syslog-protocol currently under ballot

  18. ATNA Auditable Events

  19. ATNA Auditable Events

  20. ATNA Auditable Events

  21. EHR System Physician Office XDS Document Repository XDSDocument Repository ATNA Audit record repository CT Time server ATNA Audit record repository XDS Affinity Domain (NHIN sub-network) Accountability PMS ED Application XDS Document Registry PACS Query Query Document Register Document EHR System PACS Retrieve Document Provide & Register Docs Maintain Time Lab Info. System Maintain Time Teaching Hospital Maintain Time Query Export Export Export Community Clinic Import Import

  22. Secure Node vs Application • IHE uses the grouping mechanism to state that in the finished system or environment both the application and the secure node must be present. • It is possible to be an application supporting ATNA transactions without being a Secure Node: • Server applications • Plug-in applications • Those security facilities that are within the scope of the application must be provided: • ATNA logging of relevant events • Network communication authenticated • User access controls as applicable • External security facilities are the responsibility of the secure node actor: • File system security, etc • Over all system user authentication and access control • Over all security audit event capture

  23. Consistent Time (CT) • Network Time Protocol ( NTP) version 3 (RFC 1305) for time synchronization • Actor must support manual configuration for NTP sources. • Required accuracy: 1 second • Options: • SNTP (Simple Network Time Protocol) • Secure NTP

  24. Questions?

More Related