On October 8, Jeremiah Fowler reported that he had discovered a non-password protected database that contained what appeared to be information regarding healthcare workers and traveling nurses. If you had read the report on Security Discovery at the time, you would have read that almost one million people were potentially affected. Based on that reporting, DataBreaches.net reached out to Freedom Healthcare to inquire whether they would be notifying Colorado regulators of the leak. In response, their external counsel called me and emailed me, saying, “We believe there are inaccuracies in [the reporting].”
DataBreaches.net agreed to hold off posting anything to give them time to respond more fully to Fowler’s report. On October 28, I received their statement, which I am reproducing in full. I’ll have some comments on the other side and Fowler’s response.
This comment is in connection with a cybersecurity incident that occurred on September 15, 2019. Freedom Healthcare has been in the process of migrating our contact management system from one third party vendor to another. A portion of the old database which was stored on our previous authorized vendor’s servers was not migrating properly by our new vendor and, to remedy this, our vendor extracted a small portion of that data to handle separately as test data. Unfortunately, the technical vendor inadvertently left the test data on a publicly accessible server. The publicly accessible server was not controlled by Freedom Healthcare but rather our vendor. The test data included personal identifiable information (“PII”) of less than 90 persons who work in the healthcare sector. While this event is something we take very seriously, it is markedly different situation than what was initially reported in some of the blogs and form the basis your request for comment.
We were informed of our technical vendor’s mistake by Security Discovery, “ethical hackers” who appropriately neither examined it deeply or copied it to their servers. Upon being informed, we immediately took action and our vendor promptly restricted access to the data. In coordination with our technical vendor and other privacy and cyber security consultants, the investigation revealed that the data was only publicly available for a very limited time, that it was not downloaded or copied in any manner, and that no persons, other than Security Discovery and other authorized users (who had access to the information regardless) accessed or reviewed the data in the limited time that it was publicly available. Based upon these conclusions, and because it contained incorrect information, Security Discovery removed their posting.
From the investigation findings, we do not believe there is a legal duty to report this incident, and do not believe that the individuals whose PII was available are at any risk. However, the breach notification laws are in flux and thus, out of an abundance of caution, we are notifying those individuals whose PII was available.
Freedom Healthcare takes the privacy of its employees and customers very seriously and we are committed to ensuring their protection. While this incident is best described as a “near miss”, we are working with our technical vendor and cyber-security experts to protect against something like this from happening again.
We are grateful for the services of Security Discovery and the role ethical
hackers play in our society. They provide a valuable service in ensuring data protection.
Based on their statement provided to this site, Freedom Healthcare seems to be acknowledging that there was a misconfiguration (by a vendor) and that personal information was exposed. They also seem to acknowledge that they learned of it because of Fowler’s notification to them. Apart from attributing the error to a vendor and not to their own employees, it seems like the biggest disagreement with Fowler’s reporting was one of numbers. He claimed that 957,000 had data exposed. They claim fewer than 90. So why didn’t Fowler just issue a correction and apology if that was the issue (if he had actually made an error in the numbers that they could prove)? Why did Security Discovery just silently remove their post with no explanation at all? And what about all the sites that had linked to that report and reported his stated findings?
DataBreaches.net contacted Security Discovery to ask why they removed their report. And that’s when things got even more confusing, because it seems they removed their post because they didn’t have enough data to prove that the data were real and not “test data.” Fowler explained, in part:
As a policy we do not download the data we discover and only take a very small sample of documents for verification purposes. The same day it was published, I got a call from their lawyer who said that they insist it was internal test data.
[…]
Unfortunately, I can not validate with confidence that the data was not test data as they said, so I redacted the article.
Maybe the data were being used for testing migration, but by Freedom Healthcare’s statement to this site, those were real data on some healthcare workers.
It seems that Fowler removed the report based on Freedom Healthcare’s initial claim that the data was (only) “internal test data.” But “internal test data” can be real data.
When entities tell researchers (or journalists) that something was only “test data,” we need to follow up by asking if they mean real individuals’ data being used for testing purposes or if they are claiming that the data itself is fake/fabricated data not tied to real individuals.
Fowler seems to have found a real exposure, although the number of individuals exposed may be in controversy. Maybe he shouldn’t have been so quick to just remove the article. It might have been better to update it to say that it was under review. But Fowler gets the last word on this one, as he realized that in the future, they need to download and preserve more proof of leaks to support their reporting. He wrote to me:
As I am sure you understand, our focus is on data protection and not trying to fight legal battles. So, it was a learning experience and now we will change our verification policies. We will also increase the number of documents going forward before publication to ensure that we never run in to this again.
It’s a painful lesson that many of us have learned and will likely learn again.