1. s 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. Securing Access to Data  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. Access Control Activity Audit Message Sent to Repository  Access Control –Get permission before allowing action –Suitable for certain situations, e.g. restricting access to authorized medical staff

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. s We welcome your input! Thank you.