1. s 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 Issues usually set by regulations or local administrators Technical Issues usually resolved through standardization Training Issues usually coordinated at each site individually

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

6. Aspects of Security Policy Issues usually set by regulations or local administrators Technical Issues usually 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. Security Communication Profiles  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

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. Attributes to be encrypted Item 1 (of only 1) Modified Attributes Sequence Cryptographic Message Syntax envelope CMS attributes Encrypted Content Transfer Syntax Encrypted Content encrypted Content Item 1 (of n) Encrypted Content Transfer Syntax Encrypted Content Item 2 (of n) CMS envelope Encrypted Content Transfer Syntax Encrypted Content Item n (of n) CMS envelope Encrypted Attributes Sequence Attributes (unencrypted) SOP Instance

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

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 Healthcare A Proposed Model Application Specific Trigger/Content Security AdminAudit Trail Mgt User Generated Events HL7 Security SIG Driven – DICOM references DICOM WG14 Security Driven – HL7 References Audit Trail Records Transfer Session and Transport : Reliable SYSLOG or ebXML ? 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 site http://www.ietf.org/internet-drafts/draft-marshall-security-audit-00.txt http://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. s We welcome your input! Thank you.