New Security Developments in DICOM

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.