Does hospital network threat detection stop DICOM leaks?

AdvancedUNO
11 Aug, 2026
Does hospital network threat detection stop DICOM leaks?

8 min read

How does hospital network threat detection miss the most exposed clinical endpoints?

Hospital network threat detection often misses exposed DICOM servers, leaving medical imaging systems vulnerable to silent data exfiltration.

In the quiet of a clinical environment, the failure of a system rarely announces itself with a flashing red light. Instead, it manifests as a subtle delay—a slow-loading MRI scan, a workstation that requires a hard reboot between patients, or an automated script that quietly copies medical images to an external server. The Digital Imaging and Communications in Medicine standard, universally known as DICOM, is the lifeblood of modern diagnostic medicine. It enables a CT scanner manufactured by Siemens to transmit high-resolution images to a Picture Archiving and Communication System developed by Fujifilm, which is then accessed by a radiologist on a Barco diagnostic display. This interoperability is a triumph of clinical engineering, but it was designed in an era when clinical networks were physically isolated from the internet.

Today, those networks are hyper-connected. When a hospital system deploys general-purpose intrusion detection software, the security operations center monitors standard enterprise traffic. They look for suspicious active directory logins, anomalous email attachments, and unauthorized virtual private network connections. Yet, these systems remain fundamentally blind to the specialized, high-volume protocols that run the actual diagnostic machinery. The assumption that standard network monitoring protects the clinical network is a dangerous illusion that leaves the most sensitive patient data exposed to silent exploitation.

The clinical data pipeline where security visibility goes dark

To understand why traditional security tools fail in this environment, one must examine the path a medical image takes. When a patient undergoes an ultrasound, the imaging modality generates a series of DICOM files. These files contain not only the pixel data of the scan but also a rich header packed with protected health information, including the patient's name, medical record number, date of birth, and clinical history. The modality transmits these files over the internal network using unencrypted TCP protocols, typically targeting Port 104, Port 11112, or other custom ports assigned by the vendor.

Standard network security tools rely on signature-based detection or basic behavioral baselines optimized for web traffic. Think of standard network monitoring as a security guard watching the front lobby of a bank while ignoring the specialized pneumatic tubes carrying cash directly from the vault to the drive-thru. Enterprise security platforms like Palo Alto Networks Cortex or Splunk do not natively parse DICOM application-layer commands, such as C-FIND, C-MOVE, or C-STORE. Consequently, when an unauthorized device on the network queries a PACS server for thousands of patient records, the transaction looks identical to a routine clinical query, passing through the network without triggering a single alert.

Why network address translation cannot fix unencrypted clinical protocols

A common defense raised by network administrators is that these imaging suites are protected behind local firewalls and Network Address Translation boundaries. In theory, this limits exposure to the immediate clinical subnet. In practice, this defense regularly crumbles under the realities of medical device maintenance. Third-party field service engineers frequently configure temporary port-forwarding rules on local routers to allow remote calibration, troubleshooting, or software updates. These temporary rules often become permanent fixtures, quietly exposing raw DICOM ports directly to the public internet where automated scanners index them within hours.

"We are securing the administrative perimeter while leaving the clinical diagnostic pipeline completely unencrypted and exposed to the public internet."

Autopsy of a clinical imaging breach that bypassed standard monitoring

To see how this vulnerability plays out in practice, consider a representative regional hospital network operating across multiple clinical campuses. This composite scenario illustrates a pattern that recurs across the healthcare sector, where the gap between administrative IT security and clinical engineering becomes a costly liability.

  1. The initial exposure via remote maintenance: A field technician servicing a legacy CT scanner configures a direct port-forwarding rule on the local subnet router to perform remote diagnostics from their home office. The technician bypasses the hospital's formal change-control process to expedite the repair, leaving Port 104 open to the public internet without requiring multi-factor authentication.
  2. The silent reconnaissance and data harvest: An automated external scanner operated by a threat group detects the exposed port. Using standard DICOM query protocols, the attackers issue a series of low-and-slow C-FIND requests. Over three weeks, they systematically harvest 14,300 patient imaging files, including metadata and diagnostic reports, completely bypassing the hospital's enterprise intrusion detection system which is not configured to monitor Port 104 traffic.
  3. The lateral pivot and clinical disruption: After mapping the internal network through the PACS directory, the attackers identify a legacy Windows workstation running the imaging gateway software. They exploit an unpatched operating system vulnerability to gain a foothold, eventually deploying ransomware that encrypts the pathology department's reporting system, forcing clinicians to revert to paper charts and delaying critical surgeries.

Who profits from clinical security sales and who pays for the fallout?

The economics of healthcare cybersecurity reveal a stark imbalance between those who capture financial value and those who absorb the operational and human costs. Security software vendors generate high-margin subscription revenues by selling complex threat detection platforms, often marketing them as comprehensive solutions for the Internet of Medical Things. Cybersecurity consulting firms charge premium incident-response fees to clean up networks after a breach occurs, turning organizational failures into profitable engagements.

Meanwhile, the financial and physical consequences are absorbed entirely by the clinical providers and their patients. When a ransomware attack forces a hospital to divert ambulances, the financial loss from canceled elective surgeries and emergency services falls squarely on the healthcare system's balance sheet. Frontline nurses and physicians absorb the physical toll, managing high-acuity patients without access to electronic health records or real-time lab results. Ultimately, the Office for Civil Rights under the Department of Health and Human Services enforces strict HIPAA penalties against the healthcare provider, not the medical device manufacturer who delivered an unpatchable imaging system, nor the security vendor whose software failed to detect the intrusion.

Where legacy perimeter controls still hold their ground

This analysis does not imply that standard enterprise security controls are obsolete. For traditional administrative networks—such as billing departments, human resources databases, and corporate email systems—standard endpoint detection and response tools like CrowdStrike Falcon or Microsoft Defender for Endpoint are highly effective. These environments are highly standardized, making it relatively straightforward to isolate anomalous behavior and enforce strict access policies.

The error lies in attempting to apply these same administrative tools to the clinical engineering domain. A medical device is not a corporate laptop; it cannot tolerate the latency introduced by active local scanning agents, and its software environment is strictly controlled by regulatory clearances. Trying to force enterprise security paradigms onto clinical modalities creates a false sense of security while failing to address the fundamental lack of encryption and authentication inherent in legacy clinical protocols.

How to build an actionable security checklist for clinical network environments

Instead of purchasing additional software licenses that promise automated remediation, healthcare organizations must focus on precise, system-level process controls. By aligning with established frameworks such as the Health Industry Cybersecurity Practices guidelines and the FDA's pre-market cybersecurity requirements, clinical security teams can implement highly effective, low-cost interventions that directly reduce the attack surface.

  • Implement strict internal access control lists: Configure network switches to restrict Port 104 and Port 11112 traffic exclusively to authorized PACS IP addresses, preventing unauthorized lateral communication between medical devices.
  • Establish a centralized Software Bill of Materials registry: Catalog the underlying operating systems of all connected clinical modalities to track known vulnerabilities, ensuring that legacy systems are isolated via microsegmentation rather than left exposed on the general network.
  • Enforce zero-trust vendor access policies: Mandate that all third-party remote maintenance sessions occur through a secure, monitored gateway that automatically terminates sessions after a specified period, eliminating permanent port-forwarding rules.

Frequently Asked Questions

What happens to our clinical workflow when a security scanner's active network probe crashes a legacy anesthesia machine?

Active vulnerability scanning on clinical subnets frequently causes legacy embedded operating systems to freeze, reboot, or drop network connectivity. To prevent clinical downtime, security teams must use passive network monitoring tools that analyze mirrored SPAN port traffic, ensuring that no active packets are injected into clinical sessions while patients are undergoing treatment.

How do we handle third-party imaging vendors who refuse to let us install endpoint security agents on their PACS workstations?

Medical device manufacturers often state that installing third-party software voids their FDA clearance or service warranty. In these scenarios, you must isolate the workstation using microsegmentation at the network switch level, restricting its communication strictly to the specific PACS storage endpoints it requires to function.

Why did our enterprise SIEM fail to alert us when an external IP address downloaded 50 gigabytes of DICOM files?

Most enterprise SIEMs are not configured to parse DICOM application-layer commands. To the SIEM, this looks like normal, high-volume clinical data transfer between authorized internal zones, especially if the traffic is routed through an intermediate server that has legitimate access to the imaging network.

What is the baseline cost overhead of implementing TLS encryption across our existing fleet of legacy DICOM devices?

Implementing DICOM TLS on legacy imaging devices often requires hardware upgrades or software patches that cost between $5,000 and $25,000 per modality, assuming the manufacturer even supports it. If the device's embedded processor cannot handle the cryptographic handshake overhead without introducing latency into the imaging pipeline, you must deploy an external hardware gateway to encrypt the traffic at the network edge.

The Clinical Security Verdict: True resilience in healthcare cybersecurity is not bought through expensive, automated threat detection suites that generate endless alerts for overworked security operations centers. It is earned through rigorous, quiet process design—segmenting legacy modalities, enforcing strict vendor access controls, and aligning clinical engineering with IT security. Until we shift our budgets from reactive software to proactive architectural hygiene, hospital networks will continue to pay the price for vulnerabilities they did not create.

Related from this blog

Sources

Next Post Previous Post
No Comment
Add Comment
comment url