Misconfigured Server Exposes Patient Data (InfoRiskToday)

Data Breach , Governance , Patch Management

Security Researcher Discovers Apparent Breach at Medical Practice

Misconfigured Server Exposes Patient Data

A medical practice’s misconfigured database server that allegedly left information about thousands of patients – plus staff – exposed serves as another reminder about the importance of safeguarding sensitive data from exposure on the internet.

See Also: Addressing the Identity Risk Factor in the Age of ‘Need It Now’

The breach involving Huntington, New York-based medical practice Cohen, Bergman, Klepper, Romano MDs was discovered by Chris Vickery, director of cyber risk research at the cybersecurity firm UpGuard.

In a March 26 blog, Vickery says that on Jan. 25, he discovered an “exposed port within IT systems” containing data involving the medical office. “The exposed port in question, port 873, is typically used for rsync, or ‘remote synchronization,’ a utility typically used to copy data from one machine to another,” he writes.

“While rsync can be secured against public access by employing the utility’s ‘hosts allow/deny’ functions, it can also be configured for global access, allowing anyone to access the information knowing only the server’s IP address. In this case, lacking the protection [required] by a directive to only allow particular IP addresses to access the rsync server, the repository was exposed to anyone who happened across it.”

Among the data exposed was an “Outlook backup saved as a .pst file, containing a large number of apparent email communications, while a virtual hard drive stored within the repository holds a number of documents about office staff,” he writes.

Those emails revealed staff information, including home addresses, spousal details, names of their children, and in at least one instance, the Social Security numbers for all family members.

The bigger exposure, however, was a database folder containing a number of tables consisting of over 42,000 patient names – as well as Social Security numbers, dates of birth, phone numbers, email addresses, ethnicities, and insurance policy information. “Perhaps most troubling is the presence in one table of over 3 million medical notes – each one a specific observation of an individual’s condition,” Vickery writes.

“The exposure of personally identifiable information about tens of thousands of individuals raises serious questions about how privileged medical information is secured on digital systems.”

Breach Notification

The medical practice’s data exposure was corrected by March 19, “after initial analysis and notification on Feb. 12, and following many phone calls and emails” to the entity by UpGuard’s cyber risk team, Vickery writes.

Vickery has previously discovered a number of other large data breaches by scanning the web, including finding in 2015 a database containing more than 191 million U.S. voter registration records.

The Cohen, Bergman, Klepper, Romano MDs medical practice did not immediately respond to an Information Security Media Group request for comment on the incident.

As of March 27, the incident was not listed on the U.S. Department of Health and Human Services’ Office for Civil Rights’ HIPAA Breach Reporting Website. Commonly called the “wall of shame”, the website lists reports to OCR of health data breaches affecting 500 or more individuals.

Common Problems?

Mistakes involving configurations are a common risk that can lead to security incidents, says Tom Walsh, president of the seconsultancy tw-Security.

“As much as IT people like to consider themselves accurate and thorough in their work, they often get in a hurry,” he says. “Change control and configuration management can be perceived as administrative tasks … that slow down their work so they frequently are skipped. And that is when mistakes can happen.

“In healthcare, we typically find the change control and configuration management process for major applications and systems are handled by the vendor. However, these practices do not always carryover to the network and infrastructure team,” he says.

Other Incidents

In fact, the OCR wall of shame is dotted with other breaches involving health data unintentionally exposed on the web due to misconfigured settings and related mistakes.

For instance, last June, the University of Iowa Hospitals and Clinics reported to OCR the discovery of a breach involving health data that was accidentally exposed on an application development website for about two years.

In that incident, protected health information of approximately 5,300 patients was inadvertently saved in unencrypted files that were posted online on an application development site.

In a few cases involving patient data being exposed on the web, regulators have taken enforcement action.

In 2016, OCR smacked California-based St. Joseph Health System with a $2.14 million penalty after investigating a 2012 breach that left PHI of nearly 32,000 individuals exposed to internet searches for more than a year.

In that case, a server St. Joseph Health purchased to store files related to the organization’s participation in the HITECH Act’s electronic health records meaningful use program included a file sharing application with default settings that allowed anyone with an internet connection to access files containing PHI, the agency said.

And in 2012, OCR signed a $100,000 HIPAA settlement and corrective action plan with a small Arizona-based medical practice, Phoenix Cardiac Surgery, that had clinical and surgical appointments for its patients on an internet-based calendar that was publicly accessible.

Federal Agency Mishaps

But even some federal agencies have had their own incidents involving sensitive health related data being inadvertently exposed to web.

For instance, in the early weeks after the launch of the Affordable Care Act website HealthCare.gov, a software glitch allowed a North Carolina consumer to access personal information of a South Carolina man. HHS’ Centers for Medicare and Medicaid Services said at the time that the mistake was “immediately” fixed once the problem was reported. Still, the incident at the time raised controversy about the overall security of the Obamacare health information exchange site (see HealthCare.gov: Rebuilding Trust).

Steps to Take

Entities can take measures to help prevent data security incidents involving configuration issues, Walsh says. “Disciplined organizations have a formal change control and configuration management process in place and will enforce the process to make sure that applications and systems are maintained and configured properly,” he says.

To prevent possible misconfigurations, and potential exposure of patient data on the web, Walsh suggests entities consider taking these steps, especially for external facing systems:

  • Performing periodic vulnerability scans;
  • Conducting penetration testing – at least annually or whenever there is a significant change;
  • Conducting code reviews of web applications before they are released;
  • Keeping operating systems updated and other software patched;
  • Refreshing hardware and software platforms whenever possible.

“Older systems are harder to secure against today’s cyberattacks,” Walsh notes.