Confidentiality is the assurance that information has not been disclosed to unauthorized entities. This is important given that radiologic images contain protected health information. Confidentiality is protected by encryption (Fig. 4), a mathematic transformation of data to make it unreadable to everyone except its intended recipient. Encryption involves an algorithm and one or more keys. A key is simply a long number, a generalization of the concept of a password. There are two types of encryption: symmetric and asymmetric. Symmetric encryption involves very fast algorithms and a single key shared between the source and recipient of the data. The same key is used for encryption and decryption. Involved parties must find a way to privately share that key before exchanging any encrypted data. Asymmetric encryption involves slower algorithms with two mathematically related keys: a private key kept by a user and a public key shared with the world. Either of the two keys is used for encryption, and the other key is used for decryption. To send confidential data securely to a recipient, the sender encrypts it with the public key of the recipient, and the recipient decrypts it with his or her private key. Symmetric encryption is thousands of times faster than asymmetric encryption.

View larger version (39K)

Fig. 4A —Schematic of implementation of confidentiality by encryption, which involves use of keys for encrypting and decrypting data. Arrows show direction of data transmission. A, Symmetric encryption involves single key used for both encryption and decryption. Sender has copy of key for encryption, and recipient has copy of same key for decryption. They must find way to privately share that key before exchanging any encrypted data.

View larger version (41K)

Fig. 4B —Schematic of implementation of confidentiality by encryption, which involves use of keys for encrypting and decrypting data. Arrows show direction of data transmission. B, Asymmetric encryption involves two mathematically related keys: private key that is not shared and public key that is easily shared with world. To securely send data to recipient, sender encrypts it with widely available recipient's public key and recipient decrypts it with his or her private key. Parties do not need to privately share key before exchanging any encrypted data as recipient's public key is widely available.

Integrity is verification that data have not been altered and that no tampering of an image has occurred. Integrity is confirmed using digital signatures (Fig. 5), which are a combination of a mathematic transformation of data generating a fixed-size long number (i.e., a hash), followed by asymmetric encryption of that hash, which generates a digital signature. Any variations in the data result in a different hash, and any variation in the key used to encrypt it results in a different digital signature. When a sender transmits data to a recipient and the recipient wants to confirm the integrity of the data received, the sender applies the hash function to the data, and the resulting hash is encrypted with the sender's private key to produce a digital signature. This digital signature is transmitted to the recipient, who decrypts it using the sender's public key. The recipient also applies the same hash function to the data received. If the result is identical to the sender's decrypted digital signature, this confirms the integrity of the data.

View larger version (81K)

Fig. 5 —Schematic of implementation of concepts of integrity and authenticity using digital signatures. Sender transmits DICOM object to recipient. Recipient would like to confirm integrity of received object. Sender applies hash function to object, and resulting hash (Hash1) is encrypted with sender's private key to generate digital signature. This digital signature is securely transmitted to recipient, who decrypts it using sender's public key. Recipient also applies same hash function to received DICOM object, producing hash (Hash2). If this hash is same as decrypted digital signature, this confirms integrity of DICOM object. Two different objects have only one chance in 2160 of producing same 160-bit hash illustrated in Figure 3. If hashes are same, digital signature also authenticates sender because sender's public key was correct key capable of decrypting digital signature. Certificates can also be used in tandem with digital signatures for authentication because they confirm whether sender really owns that specific public key. Arrows show directions of data transmission.

The concept of integrity also includes authentication, which is the assurance that information is from the source from which it claims to originate. Authentication uses a digital signature, often in tandem with a digital certificate, which is an endorsed version of the sender's public key from a central certifying authority. The digital signature proves that the owner of the public key is the true source of the data, and the certificate officially confirms who that owner is.

Availability is a guarantee of reliable access to the information by authorized people. For example, access to radiologic images can be blocked by ransomware. Availability is assured by multiple layers of system defenses established to prevent ransomware from taking over these systems and holding the data hostage and by redundancy (e.g., backups).

Protocols for secure transmission have been introduced in the DICOM standard. With time, nearly all have been retired, but one strong protocol remains: transport layer security (TLS) (Fig. 2). TLS involves a combination of slow, asymmetric encryption for negotiating the connection, authenticating the parties, and exchanging a shared key and fast symmetric encryption using the shared key for exchanging the DICOM messages [21]. Certificates for connection guarantee authentication of the involved parties. Encryption is used to maintain confidentiality, and encrypted hashes are used to maintain integrity. TLS was not developed by DICOM WG-14, but it is a standard that is widely used in Internet communications (often when “https://” is used).

Digital signatures described in the previous section have been introduced in the DICOM standard. They are computed for entire or partial DICOM objects to confirm their integrity and identify who created them. This has largely been ignored by manufacturers and has not been implemented.

Basic security for DICOM files on media and in e-mails has been introduced in the DICOM standard. This uses encryption of DICOM files and specifies the proper handling of keys. It has largely been ignored by manufacturers and not implemented.

Security features such as encryption and digital signatures require a system of keys and certificates that are difficult to manage and require substantial overhead and infrastructural complexity. These are the main reasons that such security features have not been implemented by manufacturers. A secure server containing the keys must be deployed, which will maintain the keys in perpetuity. Two sets of organizational problems need to be addressed: how to store, acquire, and recover keys and how to authenticate people requesting keys.

The DICOM standard never enforces security; it only provides for it. Manufacturers are free to implement parts of the standard as they see fit. Once implemented, these parts must be used to be effective. There are parts of DICOM that must be implemented, such as the low-level communications protocol. Most DICOM images contain no inherent security. Instead, they depend on the security of institutional networks and archives for protection from attacks. The security of these networks and archives can fail, opening the door to attacks on DICOM images.

The networks of several hospitals are poorly protected and can be accessed from the outside [22]. In 2017, a group at Massachusetts General Hospital scanned the entire Internet address space (4 billion addresses) in 22 hours to identify unprotected DICOM servers (Pianykh OS, Radiological Society of North America 2017 annual meeting) [23]. They found 2782 unprotected servers across the globe, most of them located in the United States. Of these servers, 821 of these systems were open to a DICOM connection, and 750 were open to discovery of patient information.

In 2018, a researcher from the security company McAfee used an Internet scanning tool known as Shodan to find unprotected DICOM servers all over the world [24]. He found more than 1100 such servers directly connected to the Internet without any protection. Most of them were located in the United States. He was able to retrieve DICOM images and was even able to print a 3D model of someone's pelvic bones by using the accessed data.

Even if a hospital network is well protected from the outside, a hacker can easily enter a hospital and connect a laptop to the hospital network via any standard Ethernet jack. From there, simple queries can be executed to retrieve DICOM files from DICOM servers and archives. Some hospitals restrict such queries to well-identified destinations associated with legitimate users using specific parameters, but these parameters are easy to spoof [25].

In March 2019, a security researcher showed how an attacker can use deep learning to automatically inject or remove abnormal findings on CT and MRI scans in DICOM messages during transfer from the scanner to the PACS [15] (Fig. 6). The attack used two deep neural networks: one for injection and the other for removal. The realism of the altered images fooled 99% of radiologists who reviewed the images. Although deep learning has been used in the past to generate fake videos and imagery, this was the first time it had been used in the medical domain to secretly tamper with 3D DICOM images.

View larger version (247K)

Fig. 6A —Creation of fake lung nodules on DICOM images. A, Original DICOM image (A) and modified DICOM image with fake lung nodules added (B) show result of hijacked transmission of DICOM messages between scanner and PACS. Deep learning was used to either add or remove lung nodules on DICOM images. Almost all radiologists who examined these tampered images were fooled by their altered content.

View larger version (258K)

Fig. 6B —Creation of fake lung nodules on DICOM images. B, Original DICOM image (A) and modified DICOM image with fake lung nodules added (B) show result of hijacked transmission of DICOM messages between scanner and PACS. Deep learning was used to either add or remove lung nodules on DICOM images. Almost all radiologists who examined these tampered images were fooled by their altered content.

In April 2019, a security researcher developed a technique to hide malware within DICOM files [16, 26–28] (Fig. 7). He did this by misusing the DICOM file preamble, which is used to make DICOM images understandable to non-DICOM imaging software [29]. The preamble is a useful feature, but it can be exploited. He created the PEDICOM hybrid format (with “PE” denoting a Windows portable executable file) by replacing the 128-byte preamble with a header capable of executing code and then replacing or creating private attributes in the DICOM file with malware code. The public attributes and the imaging data were untouched. The modified file behaved as a regular DICOM file; it could be read by a PACS and workstation, displaying its imaging data with no evidence of corruption. However, when executed from the Windows command prompt, malware code was executed, leading to compromise of the computer system.

View larger version (331K)

Fig. 7 —Format of PE-DICOM file (with “PE” denoting Windows portable executable file) after injection with malware. Schematic shows formats of original DICOM file (left) and PE-DICOM file (right). In PE-DICOM file, 128-byte preamble is replaced by official DOS header at beginning of every PE file. This header points to actual malware code included in private attributes. Indicator DICM, public attributes, and image pixel data are untouched and are only shifted if necessary.

There are many additional injection vulnerabilities that can affect DICOM objects, DICOM files, and DICOM messages. Identity spoofing involves modification of the public attributes of a DICOM object to change the name and identifiers of a patient and send the file to the wrong record. A denial-of-service attack sends millions of DICOM messages to overwhelm a DICOM server, leading to denial of service. A buffer overflow sends corrupted DICOM messages to overfill the server memory space reserved to receive them, leading to potential well-known buffer overflow attacks [30] that can take full control of a workstation. Finally, there is CD autoload tampering, which modifies autoloading code on a CD with DICOM files to take over a computer when the CD is loaded on a computer in a physician's office.

DICOM WG-14 is well aware of the current vulnerabilities of DICOM messages and DICOM files and is tracking potential future vulnerabilities [31]. It meets monthly to review and triage security reports and suggested improvements, review work on corrections and improvements to the standard, and review work on educational material for implementers and users. Much of the work involves reviewing and adding security considerations for new features in the DICOM standard [32]. WG-14 is currently focusing on two major initiatives.

The first initiative involves management of keys and certificates. All current DICOM security features require keys and certificates to maintain confidentiality and integrity, and their management is a very complex task. This is the main limitation in the widespread adoption of those security features. WG-14 recently proposed using the automatic certificate management environment (ACME) protocol [33], which simplifies distribution and management of keys and certificates.

The second initiative involves management of network security. The National Security Agency proposed a series of milestones that should be met to make an unmanageable, insecure network more secure and more manageable. It is called the National Security Agency Manageable Network Plan [34]. WG-14 is working on adapting this plan for the DICOM standard.

Some security features are already part of the DICOM standard, but most cannot be used because they have not been implemented by the manufacturers. Several tasks are required from the manufacturers.

The first task is to implement current DICOM security features. Secure transmission of DICOM messages has been implemented by some manufacturers and should be extended to all manufacturers. It is mostly implemented for transmission between institutions but should also be implemented for all internal network transmissions. Once WG-14's new features to handle keys and certificates (ACME) have been added to the DICOM standard, they should be used by manufacturers to help implement digital signatures for the integrity and encryption of media and e-mails for confidentiality.

The second task involves implementation of a creator digital signature. A creator digital signature public attribute already exists in the DICOM standard [17] and is to be filled by imaging modalities for a lifetime data integrity check. Once digital signatures are implemented, manufacturers must not only fill that field but must also implement systematic checks for these signatures by all receivers of images and issue warnings if the signature is either missing or cannot be verified.

The third task is to systematically wipe out undesired preambles from DICOM files to prevent execution of embedded malware. File deconstruction and reconstruction techniques have been proposed [14] as a solution. Preambles are always discarded when DICOM messages are transmitted on a network because DICOM messages have no preamble (Fig. 1), so only files stored on servers or media using nonstandard means need to have their preamble wiped out.

Finally, the implementation of DICOM image validators, which verify the internal consistency and bounds of DICOM objects, can help prevent buffer overflows injection and denial-of-service attacks.

Local IT experts should continue to monitor their networks for suspicious activities and periodically review DICOM audit logs for suspicious access patterns. Local IT experts should focus on three important network security areas to mitigate DICOM vulnerabilities: user authentication, access control, and network and device visibility. User authentication involves the ability to accurately identify the user making a request. Multifactor authentication should be used extensively. Access control limits the activity of legitimate users. It does not eliminate the attacks but restricts the scope of the damage of an attack to the access allowed each user. In terms of network and device visibility, every internal network, DICOM server, and DICOM device should be invisible from the outside world. Limited access for DICOM data exchange with outside collaborators or vendors should be highly secured.

The combination of secure transmission, user authentication, and access control is very effective in reducing many data injection vulnerabilities and data access vulnerabilities. In addition to these two areas, the local IT team should set up the following controls to prevent specific injection attacks: rate limiters and the disabling of CD auto-loading. Rate limiters are server controls that are put in place to deal with runaway modalities that send too much data. Rate limiters put a maximum cap on how much data can be sent from a source on the network within a period. The same controls can be used to prevent denial-of-service attacks. Disabling autoloading of CDs on most hospital computers mitigates injections of malware from self-booting CDs.

Radiologists and technologists occasionally face corrupted data, incomplete data, and issues of data origin. There are procedures in place to deal with such problems, and solutions are often provided by technologists or IT experts. The new injection vulnerabilities lead to the same kinds of problems, but they are perhaps multiplied by a factor of 10 or 100. Access controls, audit flags, and workflow alarms can already identify several of these problems, but radiologists must keep the CIA triad in mind.

First, it is important to maintain confidentiality. Any medical image on a laptop or CD should be encrypted or anonymized. One should never remotely view or transmit medical images on a public Wi-Fi network without the use of a virtual private network, which encrypts all communications.

Second, one must verify integrity. As health care moves into a new era of increasing information vulnerability, radiologists should understand that they may be using data that has been altered. If tampering of DICOM image pixels is suspected, it should be confirmed by using redundancy in datasets. Are the same findings present on coronal or sagittal reformatted sequences or on scout images? If tampering of DICOM image attributes is suspected, use any prior imaging and the medical history to determine whether the images belong to that patient and whether the imaging findings make sense.

Third, one must verify authenticity. Are the imaging data coming from a trusted source? Loading a CD from an unfamiliar source to read images on a local computer for a curbside consult is risky because the CD could have been tampered with, enabling it to autoexecute malware. Film libraries have computers that can safely extract DICOM images from CDs and load them into a PACS.

A major responsibility of radiologists and radiology administrators is to include available DICOM security measures in equipment specifications and purchase contracts. If users do not request security features, there is little incentive for manufacturers to include them.