Is the Data of Your Patients Secure? Here's How to Check With PRTG

 Originally published on September 27, 2019 by Shaun Behrens
Last updated on January 23, 2024 • 10 minute read

We live in an age where data leaks are a constant concern. Facebook, dating sites, even video gaming platforms: there have been countless leaks where personal data was made accessible through a security gap. But can you imagine data more personal than your medical data? Probably not. But that's exactly the data that was exposed recently when millions of compromised healthcare servers were discovered.

The Exposed Data

The problem was discovered by ProPublica in an investigation they did in conjunction with Greenbone Networks, a security company, and Bayerische Rundfunk, a German broadcasting network. They discovered that they could view the medical images—such as MRIs and X-rays—of millions of patients globally. It wasn't even necessary to be able to code; in some instances, all you needed was a standard browser and to know where to look. Making matters worse is the fact that, according to a report by Greenbone Networks, the patients' names, date of birth, and some information about the reason for the medical examination were exposed along with the images.

Let's take a look at how this data was accessible, and how this issue could have been prevented.

The Extent of the Problem

I've previously written about the architecture of healthcare IT, including the Picture Archiving and Communications System (PACS). To summarize here: medical imaging devices (called modalities) store the images they take to PACS, which is essentially a storage system. The Digital Imaging and Communications in Medicine (DICOM) protocol is used to store these images and retrieve them from the PACS.

The problem is that, like in any other IT environment (and this is going to sound really obvious), PACS servers that are not secured properly are vulnerable. And that's the crux of this issue. Greenbone did a global scan to find accessible PACS servers. When they found accessible servers, they attempted to retrieve patient images using the DICOM protocol. And guess what? They were able to access a lot of images.

Here's what they wrote on their website about it:

Altogether, we unearthed more than 24 million records which, combined linked to more than 700 million images. Of these scans, 400 million were actually downloadable. These unprotected systems are located in 52 countries around the world. In addition to the general “openness” of the systems, they also have thousands of “real” vulnerabilities, i.e. outdated web server versions and vulnerable database instances. In some cases, the PACS servers even allow patient data and images to be viewed via http and a web browser.

There is no doubt that what Greenbone found was alarming, but it should also be seen in context of a bigger picture. The headlines screamed that "millions" of images were publicly accessible, which is true, but this figure is actually the most sensational statistic from the entire study. Let's look at the results for the USA: they were able to access 303.1 million images. That is a lot. But these 303.1 million images were across only 187 exposed servers. That's 187 out of a potential of tens of thousands of servers. 

The other thing to add context is that although there were 303.1 million images accessible, these were not from 303.1 million patients. Rather, each patient can have multiple "studies" (a DICOM term for a medical examination), and each study can have many images. Here are the statistics for USA and Germany (taken from the Greenbone report): 

Country Exposed Servers Studies Images
USA 187 13,700,499

303,126,601

Germany 6 15,310

2,859,595

Here you can see that the number of images does not equate to the number of compromised records. And although the number of accessible images is unacceptably high, the problem is not as wide-spread as some media outlets would have you believe.

An Avoidable Situation

It's important to note that the problem is not with PACS or DICOM; rather, the fault lies with bad security practices in securing the servers. In many cases, the servers were purposely made accessible so that doctors and external entities could easily access the patient data remotely. But there are several ways that this could have been avoided. Here are a few possibilities.

  • Use a VPN: If you need to access patient date remotely, then set up VPN access rather than make the server available in other ways.
  • Apply Application Entity Title (AET) filters: In DICOM, applications can be configured with a title that identifies it. In this way, you can configure the PACS to only accept requests from application entities with specific titles.  
  • Apply Access Control Lists to filter requests for specific IP addresses and ports.
  • Use WADO-RS: This service is part of the DICOM RESTful family, and is HTTPS-based. It also lets you query DICOM studies, instead of each image individually. 

Check your PACS with PRTG

If you want to check if your PACS server is publicly accessible or not, then you can use the DICOM sensors of PRTG. Now, I know that I am assuming that IT professionals might not know the status of their servers, but remember: there's a reason that all of those servers are accessible in the first place! So just in case, here's an idea of how to use PRTG to continuously monitor the availability of your PACS.

In PRTG, set up the DICOM C-ECHO sensor to monitor the public IP of your PACS. What this does is send regular C-ECHO requests to the server, and then checks if it gets a response (kind of like Ping). If it gets a response, then the status is green. However, in this case, getting a green status is bad, because that means your PACS is receiving the C-ECHO request and responding to it! So here you would want to set a kind of reverse notification: if the sensor is green, send an alert.

dicom-c-echo-sensor

Additionally, you can also use the DICOM Query/Retrieve Sensor to check if it's possible to access studies over the public IP of the PACS. 

For more advice about monitoring PACS, the integration engine, and other healthcare IT components, download our Healthcare IT Primer below.