An old database that seems to have magically reappeared online more than a decade after it was removed reminds us of an often-overlooked risk.
In January, DataBreaches.net reported that a behavior intervention therapist’s database was exposed online due to a misconfigured MongoDB installation. What struck me about the incident was that the therapist likely had no idea that a company she had never contracted with was in possession of a copy of her client database. That type of situation probably happens every day.
Suppose you contract with Company A to help you with your patient or customer database. They secure it and arrange hosting for it with Company B. At some point, you cancel your contract with A or they cancel the contract with Company B. Does Company A securely delete all the data they handled for you? Does Company B securely delete all the data they hosted, or do they retain a copy of your database in a backup somewhere? And what happens if Company B is bought out by Company C after you had terminated your contract with Company B, and you don’t even know that Company C just acquired a copy of your database in backup files they acquired in the takeover or sale? Is your head spinning yet with all the horrible possibilities?
Here’s a recent example where an old database in a vendor’s hands may have created costly breach notification obligations: CHI Franciscan Healthcare Highline Medical Center purchased Highline in 2014. This July, they learned that a former vendor for the previous owner had inadvertently exposed over 18,000 patients’ information on the Internet, beginning in April. Even though they never contracted with R-C Healthcare Management, they now found themselves notifying HHS and over 18,000 patients, with all the costs that breach notification and mitigation entails.
The cost of doing business, right? But why was the vendor still in possession of those data, and why were those data still connected to the Internet?
But here’s a real nightmarish example that was reported to DataBreaches.net: an FTP server that held a Pennsylvania dentist’s patients’ information mysteriously reappeared online more than a decade after it had been removed. And worse, whatever protection had been on the database when it was originally hosted reportedly disappeared when it came online again.
Neither the dentist, the IT company who had arranged hosting for the FTP server, nor the ISP has as yet explained how the server managed to wind up back online more than a decade later, especially since it had allegedly been deleted before the current ISP bought the ISP that was hosting it back then.
Based primarily on reports from the security researcher who discovered it (because neither the current ISP nor the IT firm have responded to repeated requests for an explanation:
Back in 2004, Ronald F. Schultz, a dentist in Waynesboro, Pennsylvania, was using Kapricorn Systems to help with his patient management software and system. According to Shafer, who informs DataBreaches.net that he spoke with someone from Kapricorn, they had uploaded the patient database to an FTP server that was hosted by an ISP that was eventually acquired by Atlantic Broadband. The FTP server had reportedly contained not only this dentist’s patient database, but other dental clients’ files, too.
A Kapricorn spokesperson reportedly told Shafer that circa 2005 or 2006, Kapricorn deleted the data from the FTP server and canceled the contract with the ISP.
And there things remained for over a decade, until the researcher found the exposed server with thousands of patients’ unencrypted data that included name, address, phone number, and full Social Security number. The files were indexed by both FileWatcher and Google.
While other dentists’ files all appeared to still be password-protected when the files mysteriously reappeared online, Dr. Schultz was not so lucky. His patient files, which Kapricorn insists had had protection, now had no protection.
At this point, everything is still a mystery. DataBreaches.net will update this post if information becomes available from Atlantic Broadband, Kapricorn, or Dr. Schultz. DataBreaches.net made no attempt to contact the dentist due to a family issue that has kept him otherwise occupied. Nor were patients contacted directly by DataBreaches.net, as an attorney attempting to assist Dr. Schultz had confirmed that yes, this database was the dentist’s database.
Of course, depending on what any logs might show, patients might need to be notified of this incident. But who would be liable or responsible? I would think Atlantic Broadband might have some liability if they exposed the files without any request or authorization from the owners of the databases or their agent, but my guesses about what should be do not always match what actually happens.
The Mystery of the Reappearing Server notwithstanding, all of these incidents should make us think:
– When we cancel contracts with vendors or business associates, how many of us ensure that we get all copies of our patients’ databases securely deleted?
– How many databases are floating around out there with our patients’ (or clients’) information and we have no idea where they are, who possesses them, who has access to them, and what security safeguards are in place for them?
– How many old or “test” databases with real data have we forgotten about or not given a thought about as to whether they still might be connected to the Internet?
– And how many of us actually consider these old databases in our risk assessments or in our budgets for responding to potential breaches?
It seems like there should be lessons to be learned here, but will any of us learn them?