Do you need DICOM TLS? 🔗
DICOM is the standard for the communication and management of medical imaging information and related data. It specifies the protocol and format for storing and transmitting digital medical images.
If your medical device or software already speaks venerable, unsecured DICOM, you may be wondering: Do we need to support secure DICOM TLS (Transport Layer Security)?
An option in the standard 🔗
The easiest way to answer this is whether you need to interoperate with devices on port 2762, which is reserved for DICOM TLS. Any device or application using port 2762 expects standard transport security; and while this only presently common at the PACS/MIMPS, it’s likely what brought you to this article. Unsecured DICOM is working without the benefit of an optional security specification. Secure DICOM, first added in 1999 and hardened later when ransomware became a widely-publicized threat, provides data integrity and security. As a connection is negotiated, secret keys on both ends protect against impersonation. In fact, TLS deploys the same encryption that protects online banking in your browser for the transmittal of application entity fields and PHI/PII for your medical device. The role of TLS in Internet security is a detailed best-practice, and Part 15 of the DICOM standard wisely relies on it. A device’s implementation details are answered in its DICOM Conformance Statement’s support for security profiles.
Where does this matter? 🔗
Cost of ransomware 🔗
Ransomware costs hospitals about $40,000 per minute, and even the first recorded ransomware attack was against a medical research network in 1989. While hospital IT is responsible for OS-level intrusions carrying ransomware, MDM are responsible for securing device-to-device links across network segments. Here's how DICOM is sensitive to ransomware: Authentication between two machines (based on IP address) begins when one side requests an association by title. Over unsecured DICOM, this is "in the clear" and exposed across the network. After the association, PHI including the patient name, ID, and treatment data are also in the clear. Most troubling is the inability to detect and reverse the injection of malicious DICOM onto the network by automated malware. You may not know your device is participating, since clear networking has no protection against this. If both ends of a connection support encryption, hospital IT can prepare to isolate or discard unsecured devices instead of yours.
Procurement 🔗
Do your customers use something like MDS$^2$ during procurement? With larger hospitals come larger networks — in the era of destructive and expensive ransomware — both regulators and hospital IT can justifiably ask whether your software fails to implement DICOM securely, which makes for an easy victim. For the last five years, medical devices falling victim to ransomware have been either patched or discarded. The addition of encryption helps. You can rely on TLS to authenticate a connection, ensure eavesdroppers cannot extract credentials or PHI/PII, and prevent tampering with the DICOM stream. Each of these is important — your customer’s IT will appreciate this line of defense against malware, and regulators will appreciate that the right answer to their question is a brief “yes”.
Labeling 🔗
The FDA takes labeling seriously, and recent guidance extends this to cybersecurity. A label with DICOM TLS indicates that your product can operate on a network currently under attack, or compromised in the past. We do not yet know if the amount of infrastructure supporting DICOM TLS has reached a mark where regulators seek a rationale for submissions failing to support it.
Conclusion 🔗
If your device could interface with DICOM across network domains or segments, the answer is “yes,” you need to secure DICOM like other protocols. On-premise, the best practice is to inform IT which devices are unsuitable for a network under attack. If you need to get caught-up on this, you’re not alone. Ransomware pop-ups on the screens of big-name contrast dosing machines revealed the problem to clinical, perhaps shocking hospitals that standardized on a single vendor. The wind has blown the responsibility of network transport security onto the each MDM.
If your medical device or service interfaces with email -- a different transport than TLS -- the DICOM standard describes email protections. And if you emit messages on the backend of a network -- or between endpoints in the cloud -- DICOM now pays major attention to auditing and logging. So this is part I of III on DICOM security, secure transport between devices using TLS. Stay tuned for the next two parts: securing DICOM email and media transmittal, and secure DICOM logging and auditing!
How we can help 🔗
If you need help with DICOM TLS, there are a few ways we can help:
- We can help you evaluate whether you need to incorporate DICOM TLS into your medical device.
- We can assist you in setting up DICOM TLS in a new or legacy device.
- We can help write a DICOM Conformance Statement.
- We can also provide third-party cybersecurity penetration testing, which the FDA suggested be conducted for most network-enabled devices.
