1 / 32

Security and DICOM

Security and DICOM. Lawrence Tarbox, Ph.D Chair, DICOM WG 14 (Security) Siemens Corporate Research. Motivation. Regulations protecting patient privacy Primary concern is transmitting confidential data over public networks. Protection against data tampering Liability concerns

catori
Download Presentation

Security and DICOM

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. Security and DICOM Lawrence Tarbox, Ph.D Chair, DICOM WG 14 (Security) Siemens Corporate Research

  2. Motivation • Regulations protecting patient privacy • Primary concern is transmitting confidential data over public networks. • Protection against data tampering • Liability concerns • Governmental regulations • Reimbursement rules in certain countries • Mandates for access control and audit trails

  3. Motivation • Governmental Regulations - for example • Privacy laws (several countries) • HIPAA (Health Insurance Portability and Accountability Act) • EU Directive on Data Protection • MEDIS-DC Online Electronic Storage • Danish Security Regulations • German Digital Signature Laws • More and more every day

  4. Aspects of Security Policy Issuesusually set by regulations or local administrators Technical Issuesusually resolved through standardization Training Issues usually coordinated ateach site individually

  5. Policy Level of privacy Credentials When data should be signed What transactions should be audited Who can access what Technique Type of encryption X.509 certificates Digital signature mechanisms Audit message format and interchange Access control lists Policy versus Technical

  6. Aspects of Security Policy Issuesusually set by regulations or local administrators Technical Issuesusually resolved through standardization Training Issues

  7. DICOM Security Supplements • Supplement 31 • Secure Communication Channels • Supplement 41 • Base Digital Signatures • Supplement 51 • Media Exchange Security • Supplement 55 • De-Identification

  8. Coming additions • AES encryption • CP 338 • Exchange of audit trails • IETF standard plus a DICOM Supplement • Digital Signatures in Structured Reports • DICOM Supplement

  9. Secure Communications (S. 31) • Entity authentication • Data integrity during transit • Confidentiality during transit via encryption • Secure Transport Connection Profiles • TLS 1.0 (derived from SSL) with 3DES • ISCL • TLS 1.0 with AES (proposed) • Secure Use Profiles • Online Electronic Storage

  10. ISCL Secure Transport Based on ISCL standard (from Japan) Symmetric encryption for authentication Specified for Online Electronic Storage standard TLS Secure Transport TLS 1.0 framework RSA based certificates for peer authentication RSA for exchange of master secrets SHA-1 hash as an integrity check Triple DES EDE, CBC encryption Security Communication Profiles

  11. AES Secure Transport (CP 338) • Backwards compatible with the existing profile • Request AES encryption, with fallback to Triple DES • Why AES? • Not proprietary • Expected to be widely available • More efficient that 3DES • 10% to 30% of the computation load • Possible to encrypt and transmit at 100 Mbit/second without special hardware

  12. What about VPN • No DICOM profile at this time • But not excluded for private networks(local policy issue)

  13. File Level Security (S. 51) • Protects entire DICOM files • Includes DICOM directory • Files are held inside an encrypted envelope • Utilizes Cryptographic Message Syntax • An internet standard • Only selected recipients can open the envelope • Data integrity check • Identifies a single file creator • Several Secure Media Storage Profiles

  14. De-Identification (S. 55) Why? • Teaching files, clinical trials, controlled access How? • Simply remove Data Elements that contain patient identifying information? • e.g., per HIPAA’s safe harbor rules But • Many such Data Elements are required So • Instead of remove, replace with a bogus value

  15. Attribute Level Encryption • Since some use cases require controlled access to the original Attribute values: • Original values can be stored in a CMS (Cryptographic Message Syntax) envelope • Embedded in the Data Set • Only selected recipients can open the envelope • Different subsets can be held for different recipients • Full restoration of data not a goal • Attribute Confidentiality Profiles

  16. SOP Instance Attributes (unencrypted) Encrypted Attributes Sequence Item 1 (of n) Encrypted Content Transfer Syntax Encrypted Content Cryptographic Message Syntax envelope CMS attributes encrypted Content Modified Attributes Sequence Item 1 (of only 1) Attributes to be encrypted Item 2 (of n) Encrypted Content Transfer Syntax Encrypted Content CMS envelope Item n (of n) Encrypted Content Transfer Syntax Encrypted Content CMS envelope

  17. Embedded in SOP Instance Lifetime integrity check. Identifies signer Optional secure timestamp Multiple signatures Overlapping subsets Multiple signers Signatures on individual items Digital Signatures (S. 41)

  18. Current Profiles • Digital Signature Profiles • Base RSA (referenced by other profiles) • Creator RSA (typically the equipment) • Authorization RSA (typically the operator) • Structured Report RSA (proposed) • Secure Use Profiles • Base Digital Signatures • For legacy systems • Bit-preserving Digital Signature • Possible future implementations?

  19. Questions Raised about Reports • What portion of the report should we sign? • SOP Instance UID management • How do we deal with amendments? • How do we deal with multiple signers? • How does a report refer securely to other SOP Instances? • That are already signed • That do not have signatures

  20. Proposals for SR (Subject to change) • What is signed? • SOP Class UID • Study and Series Instance UID • All of the SR Document Content Module • Current and Pertinent Evidence Sequence • Once “VERIFIED” • SOP Instance UID • Verification Flag • Amendments are new SOP Instances

  21. Purpose of Digital Signature • Add “Purpose” field to differentiate between signers (from ASTM 1762 standard), e.g. • Author • Verifier • Reviewer • Witness • Event • Identity • Consent • Administrative

  22. Secure References • Objects that are already signed • Include Digital Signature UID and value • Objects that are not signed • Include a secure hash of selected Attributes in the referenced object or • Reference other signed SRs that include secure hashes of the referenced object

  23. Audit Trail Exchange (new) • Transmit audit trail data to a collection site • Simplifies long term storage • Simplifies monitoring and analysis • Need goes beyond DICOM • Joint work HL7, DICOM, ASTM, IHE, NEMA, COCIR, JIRA, others? • Common base format • Specializations as needed

  24. Participating Groups • HL7 Security & Accountability SIG • DICOM WG 14 • IHE • Joint JIRA/NEMA/COCIR Security and Privacy Committee • ASTM E31 • …

  25. Current Proposals • Define a common XML payload • General organization of content • XML schema • To become a draft internet standard (RFC) • Application-specific Vocabularies • DICOM • HL7 • Transport Mechanism Blind • Reliable Syslog (RFC-3195) most likely candidate

  26. Audit Trail Standards in HealthcareA Proposed Model Application Specific Trigger/Content Security Admin Audit Trail Mgt User Generated Events Audit Trail Records TransferSession and Transport : Reliable SYSLOG or ebXML ? HL7 Security SIG Driven – DICOM references DICOM WG14 Security Driven – HL7 References Common DICOM/HL7 infrastructure

  27. Background on RFC-3195 • Reliable replacement for BSD Syslog • Provides BEEP message structure, store and forward transport, common mandatory fields, and an XML payload. • Options for encryption and signatures.

  28. Level of detail • Surveillance • Detail on the study level, not individual Attributes • Designed to detect intrusions • Forensic • Could be very detailed • Determine how it happened

  29. Status of Audit Trail Work Item • Derived from, but not the same as IHE Year 4 work • Current draft of the common payload on the IETF web sitehttp://www.ietf.org/internet-drafts/draft-marshall-security-audit-00.txt • DICOM Supplement being developed • References the common payload document • Specifies the transport mechanism • Identifies DICOM-specific vocabulary

  30. Future Plans This page should not be intentionally left blank!

  31. Potential Future Security Topics • Full user authentication between nodes, key management • More sophisticated access control support • Role-based access • Institutional versus personal access • Patient authorization • List of intended recipients • Support for new technology and algorithms

  32. We welcome your input! Thank you.

More Related