1 / 20

New Security Developments in DICOM

New Security Developments in DICOM. Lawrence Tarbox, Ph.D Chair, DICOM WG 14 (Security) Siemens Corporate Research. Coming Additions. AES encryption for media and attribute-level encryption Audit Message Exchange Joint work with HL7, IETF, et al Based on previous work at IHE

argyle
Download Presentation

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

  2. Coming Additions • AES encryption for media and attribute-level encryption • Audit Message Exchange • Joint work with HL7, IETF, et al • Based on previous work at IHE • User Credentials Exchange • Joint work with IHE • Enhancements to Digital Signatures

  3. Access Control Activity Audit Message Sent to Repository Securing Access to Data • Access Control • Get permission before allowing action • Suitable for certain situations, e.g. restricting access to authorized medical staff • Audit Control • Allow action without interference, trusting the judgment of the staff. • Monitor behavior to detect and correct errors. • Both have a place in security systems • Local security policies determine what is handled by access control, and what is handled by audit controls.

  4. Existing Audit Message • Interim effort by IHE • Radiology-centric view of events • Demonstrated functional capabilities • Part of the IHE Technical Framework • Provides a basis for evaluating the more general solution being developed by IETF, HL7, DICOM, and ASTM • Will coexist with the more general solution, and gradually be replaced by the more general solution.

  5. Emerging Audit Message • New Effort for IHE IT Infrastructure 2004+ • Informed by DICOM, HL7, ASTM, and IHE • Base message format posted as IETF Internet Draft, leading to RFC • DICOMization in a coming supplement • Anticipates an enterprise audit repository • Supports uniform policy administration • Enables integration of security surveillance • Provides extensibility to accommodates various government regulations plus enterprise and local policies

  6. IETF Common Audit Message • Event Identification • What was done? • Active Participant Identification • Who did it? • Network Access Point Identification • From where? • Audit Source Identification • Using which server/application? • Participant Object Identification • To what records or data?

  7. Event Identification • Event ID Code* • Coded value indicating what event occurred that triggered this audit message • Event Action Code • Type of action, e.g., create, read, update • Event Date/Time* • In UTC, of course • Event Outcome Indicator* • Did it succeed or fail?

  8. Active Participant Identification • User ID* • Identifier unique within Audit Source ID • Alternate User ID • Alternate ID, often used for single sign-on • User Name • Human readable • User Is Requestor • Role ID Often there are more than one Active Participant!

  9. Network Access Point Identification • Network Access Point Type Code • Is it a machine name, an IP address, a telephone number? • Network Access Point ID • The name, address, or number

  10. Audit Source Identification • Audit Enterprise Site ID • Which site within a healthcare network • Audit Source ID* • Which system within that healthcare network • Audit Source Type Code • The category of that system, e.g. end user interface, acquisition device, server

  11. Participant Object Identification • Participant Object Type Code • The type of object, e.g. person, system, organization • Participant Object Type Code Role • The functional role this type of object serves, e.g. • User, Doctor, Patient, Guarantor, etc. for person • Master File, Data Repository, Job, etc. for system object • Subscriber, Guarantor, Resource, etc. for organization • Participant Object Data Life Cycle • What stage in the life of the object when this event happened, e.g., creation, import, amendment, verification, access

  12. Participant Object Identification (continued) • Participant Object ID Type Code* • The type of Object ID, e.g., Patient Number, Report Number, • Participant Object Sensitivity • Institutionally defined strings, e.g. VIP • Participant Object ID* • The unique ID string • Participant Object Name • A description of the object

  13. Participant Object Identification (continued) • Participant Object Query • How the requestor identified the object of interest • Participant Object Detail • Varies between implementations There may be more than one Participant Object!

  14. Emerging Audit Message • Extensibility • Is a fully conformant XML Schema • Direct extension: add elements • Restriction: constrain values • Vocabulary: reference to externally defined nomenclature from any source

  15. DICOMization • IETF message is a blank form that needs to be filled in • Coded Vocabularies for: • Event ID • Audit Event Type • Audit Role ID • Audit Source Type • Participant Object Type • Need definition of • Real world events • Messages that would be generated from those events

  16. Three Components of an Audit System • Description of Real World Events (DICOM) • Audit Policy (Local) • Message Definition (DICOM & IETF) Real World Event Policy Audit Message(s)

  17. User Credentials Exchange • In support of: • Single-user sign-on • Application-level access controls • Alternate User ID for audit messages • Proposed addition to Association Negotiation • Simple User ID (between trusted nodes) • Kerberos ticket • Open to future types of credentials

  18. Additions to Digital Signatures • Add Digital Signature purpose • From types defined by ASTM, e.g., author, reviewer • Add Secure References to SOP Instances • Objects that already have signatures • Objects that do not have signatures • Add rules for adding Digital Signatures in Structured Reports • Address issues raised in Digital Signature demos • Add support for signing a group of objects

  19. Questions?

  20. We welcome your input! Thank you.

More Related