Last month, DataBreaches.net was contacted by Kromtech Security’s research team and asked to assist it in alerting a medical billing firm that they were exposing patients’ personal and protected health information on their backup server. On June 12, DataBreaches.net sent iMax Medical Billing in Ohio a message and left them a voice mail, alerting them to check for email from Kromtech about security concerns. Kromtech later informed this site that the firm appeared to have secured the data promptly.
Not only did iMax secure the data promptly, as we would later learn, their incident response was also blisteringly fast and appears to be suitably comprehensive. But more on that later in this report.
As it has done in the past, Kromtech Security provided this site with some files from the exposed server that would demonstrate the types of information that were at risk. You can read Kromtech’s report on the incident on their site. As is this site’s policy, DataBreaches.net will not post any unredacted PII or PHI. For now, we will just post one redacted image from one of the approximately two dozen clients’ exposed files. The file contained approximately 1,600 patients’ names, addresses, phone numbers, date of birth, insurance policy number and carrier, and payment guarantor information. Other files that we saw from other clients contained more specific medical information about diagnoses and treatment. And yet other files contained login credentials for insurer submissions.
iMax’s Response
DataBreaches.net received a response from iMax this morning. In their statement, Brian Dean writes:
I do not see the same vulnerability that was reported to you initially, which tells me that the IT team has corrected any open web access from any Buffalo devices. We have contacted clients and made them aware of the situation and that we are finishing up the security of their information. I am not aware of any patient data that has been compromised. If you are aware of patient data please provide evidence so that I can follow-up with those individuals specifically.
DataBreaches.net has since provided iMax with some information on patient data, but of course, since this site does not have all of the files that had been unintentionally exposed, DataBreaches.net cannot give iMax a comprehensive list of whom they might need to notify. Their access logs should give them the answer to that question, I would hope.
In response to a follow-up inquiry about the clear-text insurer logins that DataBreaches.net had seen in exposed files, Dean also reported that most of the logins had already been reset, and “There are only a handful of logins that we are waiting on the payer to reset or unfreeze after we verify.”
Because iMax responded promptly to the initial alert, and states that it is notifying clients and appears to be diligently working to notify all those who might need to be notified and to secure its files, DataBreaches.net is not naming any of their clients at this time. This post may be updated as more information becomes available, but for now, perhaps this incident best serves as another reminder for entities using Rsync backup to check their configuration. IMax Billing appears to be doing a truly admirable job of incident response, but I bet they join us in wishing it had never been needed.