STARTTLS | DICOM and PACS | 128-Byte Preamble |Whitepaper on US Executive Order on Zero Trust | Further Reading

DICOM is the international standard for medical imaging. It has been developed since the early nineties and has roots that go back even further. How does a mature standard hold itself in the modern world of IT, with data in the clouds, hackers accessing our systems, ransomware in hospitals, etc.? DICOM is up to its task in the areas of security and privacy, and the actual security and privacy depends entirely on the implementation of the standard: both in the products as well as in the deployment of these products in the field.

The DICOM Security Workgroup welcomes efforts to strengthen systems against cybersecurity attacks, to raise awareness of potential attack vectors, and to help users and developers understand how to guard against them.

DICOM is not a software package; rather, it is specifications for information exchange. It is similar to the NEMA specifications for electrical power plugs and sockets. A product development team uses these specifications when creating a product.

Security and privacy mechanisms

Most DICOM objects contain images and associated demographic and medical information about the patient, which need to be kept confidential. Encryption is one way to keep these data confidential. DICOM does not specify the encryption in detail (it refers to other Standards for that), but several the DICOM Standard can facilitate encryption, including the transfer of encrypted DICOM objects, and reading of encrypted DICOM objects on the receiver’s end.

• When sending those objects in an email, DICOM defines how to encrypt the files using CMS encryption methods for email.
• When sending those objects using traditional DICOM transfer mechanism (the DIMSE protocol), DICOM defines how to use an encrypted TLS connection.
• When sending those objects using the new DICOM transfer mechanism (DICOM web services), DICOM defines how to use an encrypted HTTPS connection.

It is important to note that DICOM merely facilitates the use of encryption but does not mandate it. It defines how encryption is to be used in a DICOM context. Whether to employ encryption is a policy choice of the health facility and an implementation choice of the product vendor. If the vendors have chosen not to implement encryption, or even if they do, health facilities can choose to set up a VPN encrypted network and use unencrypted DICOM. This is actually quite common between sites, but may, from a cybersecurity point of view, not be advisable.

STARTTLS

DICOM is not affected by the vulnerabilities revealed in August 2021 in the STARTTLS mechanism.  STARTTLS was introduced as a transition mechanism for retrofitting TLS onto older legacy protocols, such as the email protocols IMAP and POP.  It has been found to have multiple vulnerabilities.  These vulnerabilities are not present in the direct TLS connections.

When DICOM added support for TLS (in 1999) it used the direct TLS negotiation method and did not use the STARTTLS mechanism.  All DICOM DIMSE transactions using TLS make use of the recommended direct  negotiation.

It is possible that some very old DICOM WADO implementations might be vulnerable to STARTTLS, because some of the early HTTP toolkit and library implementations used STARTTLS.  HTTP toolkits, browsers, and servers have switched to direct negotiation.  The major browsers and servers do not permit use of STARTTLS.

It is unlikely that DICOM Web is affected because the HTTP toolkits, browsers, and servers transitioned prior to the release of DICOM Web.

DICOM and PACS

We encourage health delivery organizations (HDOs) to evaluate the security documentation provided with their PACS system—such as the Manufacturer Disclosure Statement for Medical Device Security (MDS2)—to determine how best to deploy their equipment in a safe and secure way. PACS systems are just one component that should be considered within an overall organizational cybersecurity strategy

Remote access to PACS systems requires consideration of protections, risk assessment, and mitigation strategies by an HDO. HDO should also take insider threats and the benefits of a zero-trust policy into account when evaluating cybersecurity protections. Finally, programs processing DICOM media files should continue to take precautions such as scanning the files with anti-virus software and not assuming they are safe.  Import systems should disable file execution when reading CDs or DVDs. 

An HDO that suspects its PACS systems may be vulnerable should contact their original equipment manufacturer’s service department, even if the system has been re-manufactured in the aftermarket.

128-Byte Preamble

This vulnerability could allow DICOM files stored on media to have executable malware inserted. The DICOM Network Communications protocol between modalities, PACS, and display systems does not transmit a preamble and is not subject to this vulnerability.

Further Information on risk and mitigation of the 128-byte preamble vulnerability is available here.  It has been assigned CVE-2019-11687.

Conclusion

The security and privacy capabilities of the DICOM Standard are only a small piece of the total protection of the privacy and protection against intrusion and hijacking of medical data. The CIOs (Chief Information Officers of the hospitals, health care systems and other health care providers) are responsible for protecting the medical data of their customers, i.e. the patients. Ultimately these CIOs have the capability and the responsibility for implementing and maintaining the protective mechanisms within their own systems and the interfaces towards these systems. DICOM is ready to facilitate this.