DataBreaches.Net

Menu
  • About
  • Breach Notification Laws
  • Privacy Policy
  • Transparency Report
Menu

The Mystery of the Reappearing FTP server, Part 2

Posted on September 14, 2016 by Dissent

Earlier this week, in the context of discussing of how old and forgotten databases can come back to bite us in costly databreaches, I reported on a somewhat bizarre situation involving files belonging to a Pennsylvania dentist. I have since obtained more information on that situation, and thought I would update you all.

Let’s start with the burning question of “What happened?” According to Dr. Ronald Schultz, in October of 2003, he was considering a change of computer systems. In order to “test drive” one particular computer system, he provided his patient database to the new vendor, Kapricorn (and yes, I know what most of you are thinking about him providing  real data and not dummy data, but see this comment below this post).

“This involved the vendor transmitting our patient information to a protected outside server; particular credentials were required to access our files on the server,” Dr. Schultz explains. He continues:

As it turns out, we did not like the new computer system, and went with a different computer system provider. At that point, we believed that the information had been deleted or removed from the server, which was still protected and still required specific credentials for accessing it. In 2004, the company that owned the server was bought out by Atlantic Broadband, and the server was removed from the internet completely.

And that’s where things stood until the researcher who found the leak got in touch with him recently to tell him that he found some of his patients’ information online.

“We immediately began an investigation, including our own computer consultants and Atlantic Broadband,” Dr. Schultz reports. He continues:

It appears that, for reasons that are still unknown, the particular server that went offline in 2004 was brought back online for approximately 2 weeks. Additionally, during that time, the credentials requirement was removed, so that anyone who could find that server on the internet could access the information.

So for about two weeks, files that were presumably deleted 12 years ago reappeared online for reasons no one seems to know or is willing to admit to.

So now what? Is notification of patients necessary at all? In the opinion of attorney Jeff Drummond, this is not a reportable breach under HIPAA because the dentist is not a covered entity under HIPAA. While that may surprise some readers, keep in mind that HIPAA applies to health care provider “who transmits any health information in electronic form in connection with a transaction covered by this subchapter.” Because Dr. Schultz does not engage in electronic transactions of any kind, he wouldn’t be covered by HIPAA, Drummond tells DataBreaches.net.

Sometimes it pays to be a dinosaur.

But what about any notification requirements under state laws? The opinion of those who investigated the leak seemed to be that there was very low risk of finding or accessing the data. For patients in states where the threshold for notification is likelihood of harm or identity theft, then no notification would be required.  The only exception might be patients from Virginia, where the statute requires notification if healthcare information is involved.

So Dr. Schultz does not need to notify HHS, and he probably doesn’t need to notify patients in three of the four states from which his patients come. Despite that, he has decided to notify all patients whose Social Security numbers might have been exposed.  He explains:

In the course of our investigation, we were not able to definitively rule out that no one other than Mr. Shafer and our own practice and consultants accessed the information during the brief period it was available and unprotected. However, it was clear to us that only someone with specific skills in dental computer technology, and only someone with access to old versions of current dental computer software (such as Mr. Shafer), who also happened to be looking for that specific server, would have been able to access that information and be able to view it or use it. Based on this, by early August the practice had determined that there was a low probability that your data might have been compromised, and that no notifications were required.

On August 31, Mr. Shafer told the practice that he thought there might be other ways to view the data, if someone acquired it during the two-week period it was online. We still believe that it would be extremely difficult for anyone without specific knowledge and access to old technology. However, out of an abundance of caution, we are providing you with this notice that, through no fault of this practice, there is a slim possibility that your dental information, including your social security number, might have been accessible during that time period, and we believe that there is a small chance that you may be at risk of identity theft.

Nicely done. And I’m pleased to see that the researcher who uncovered the leak was not treated as some kind of criminal hacker or miscreant, but was treated respectfully.

So we still don’t know how files that were allegedly deleted by the vendor magically reappeared, and we don’t know how a server magically reappeared online after twelve years.

But could this happen to any of us who use vendors or third-party providers? What are you doing to protect against this type of situation?

Category: Breach IncidentsExposureHealth DataSubcontractorU.S.

Post navigation

← St. Francis Health System hacked: TheDarkOverlord? (UPDATE)
Someone just lost 324k payment records, complete with CVVs →

5 thoughts on “The Mystery of the Reappearing FTP server, Part 2”

  1. Justin Shafer says:
    September 14, 2016 at 5:05 pm

    I think the possibility exists that the ftp server was up longer then 12 days, and for that reason, and perhaps the lack of logs, is the main reason to notify. I am glad the doctor has chosen to notify.

  2. Justin Shafer says:
    September 14, 2016 at 5:06 pm

    Oh, I would like to add, that the doctor handed over live data because it is supposed to go through data conversion, and then after that there is normally a large checklist of things that must be verified.. Patient Balances, Notes, etc etc.. And without actual instead of fake data, the test conversion won’t.. REALLY be a test. Thought I would throw that in here.

    1. Dissent says:
      September 14, 2016 at 5:11 pm

      Thanks for explaining that… I’ll point to your comment from my post.

  3. Regret says:
    September 15, 2016 at 1:10 pm

    Seems like a best practice for customers like this dentist would be to get a written attestation that patient/test data has been destroyed at the conclusion of a test. Then at least the customer would have something to clarify who’s responsible for breach liability.

    1. Dissent says:
      September 15, 2016 at 1:49 pm

      That’s actually one of the recommendations in a report I’ve co-authored that will be released on Monday. GMTA…

Comments are closed.

Now more than ever

"Stand with Ukraine:" above raised hands. The illustration is in blue and yellow, the colors of Ukraine's flag.

Search

Browse by Categories

Recent Posts

  • Germany fines Vodafone $51 million for privacy, security breaches
  • Google: Hackers target Salesforce accounts in data extortion attacks
  • The US Grid Attack Looming on the Horizon
  • US govt login portal could be one cyberattack away from collapse, say auditors
  • Two Men Sentenced to Prison for Aggravated Identity Theft and Computer Hacking Crimes
  • 100,000 UK taxpayer accounts hit in £47m phishing attack on HMRC
  • CISA Alert: Updated Guidance on Play Ransomware
  • Almost one year later, U.S. Dermatology Partners is still not being very transparent about their 2024 breach
  • Oklahoma Expands its Security Breach Notification Law
  • Ransomware group Gunra claims to have exfiltrated 450 million patient records from American Hospital Dubai.

No, You Can’t Buy a Post or an Interview

This site does not accept sponsored posts or link-back arrangements. Inquiries about either are ignored.

And despite what some trolls may try to claim: DataBreaches has never accepted even one dime to interview or report on anyone. Nor will DataBreaches ever pay anyone for data or to interview them.

Want to Get Our RSS Feed?

Grab it here:

https://databreaches.net/feed/

RSS Recent Posts on PogoWasRight.org

  • How the FBI Sought a Warrant to Search Instagram of Columbia Student Protesters
  • Germany fines Vodafone $51 million for privacy, security breaches
  • Malaysia enacts data sharing rules for public sector
  • U.S. Enacts Take It Down Act
  • 23andMe Bankruptcy Judge Ponders Trump Bill’s Injunction Impact
  • Hell No: The ODNI Wants to Make it Easier for the Government to Buy Your Data Without Warrant
  • US State Dept. says silence or anonymity on social media is suspicious

Have a News Tip?

Email: Tips[at]DataBreaches.net

Signal: +1 516-776-7756

Contact Me

Email: info[at]databreaches.net

Mastodon: Infosec.Exchange/@PogoWasRight

Signal: +1 516-776-7756

DMCA Concern: dmca[at]databreaches.net
© 2009 – 2025 DataBreaches.net and DataBreaches LLC. All rights reserved.
Menu
  • About
  • Breach Notification Laws
  • Privacy Policy
  • Transparency Report