- Use (and perhaps profile) security standards from IT industry
- (old) Provide options, with minimal requirements
Provide explicit threat model assumptions, e.g., IT primary is �protect client from malicious servers�. Is the DICOM primary �protect the server from malicious clients�.
- Borrow or steal ideas from OT cybersecurity strategies
- Look at MDS2 for ideas, require MDS2 or equivalent in conformance claim?
- Be sure that both IT oriented and OT oriented operations needs are met
- Configuration validation, review, automation, updating.
- Key, token, and certificate management
Identify Major classes of people affected and describe how changes would benefit or suffer from changes
- Encryption
- Data signatures To provide:
- Data at rest backup/ recovery/ integrity protection
- Data in motion confidentiality/ integrity protection
- Data de-identification
- Data element sensitivity management
##Breach/ Restoration/ Detection support
Data provenance management
Transition support, i.e., what to do with a $10+million machine that still works fine but cannot be upgraded to use the current protocols and security features. Organizational factors:
- Small deployments
- Personal devices (e.g., Norwegian tele-dermatology)
- Large deployments
- Multi-site, single controller
- Multi-site, partnerships (e.g., US-India shared radiology reading)
- Responsible internal organization (IT, OT, shared, contracted) Authentication/Authorization systems
- For devices
- For persons
- For teams
- For delegation Forward pointers to IHE, other standards? Forward pointers to Vendor documentation from Vendor Conformance claims. Threat model for medical imaging environment (and project out 20 years, not just today�s threats).
- What are the HL7 <-> DICOM security issues. E.g., image enabled office. Both control and data flow. Some sort of cyber security certification (here be dragons). IHE do this?
Template for DICOM Page 15
Template for DICOM
Page 3