Blood Test Results Exposed in Cloud RepositoryWhat Other Entities Should Do to Prevent Similar Mishaps
An apparently misconfigured Amazon repository that exposed on the web medical data for approximately 150,000 patients serves as another important reminder of the need to protect cloud-based health information from being inadvertently accessible to the public.
In a blog, Kromtech Security, a cybersecurity services company, says that on Sept. 29, it discovered that weekly blood test results stored in more than 316,000 PDFs were publicly accessible in an Amazon S3 repository.
The data appears to include multiple weekly blood tests of about 150,000 patients, and the database appears to be connected to a company called Patient Home Monitoring, says Robert Diachenko, Kromtech's chief communications officer.
Patient Home Monitoring did not immediately respond to an Information Security Media Group request for comment.
Kromtech reports that it first identified the vulnerable bucket of data on Sept. 29 and then notified the company on Oct. 5. The data bucket was secured and no longer publicly accessible as of Oct. 6.
Kromtech says the leaked data included a 47.5 Gbyte repository containing 316,363 PDF medical records containing patient names, addresses, phone numbers and blood test results.
"Amazon Web Services S3 'buckets' are a safe and secure cloud storage option for data when it is properly configured and does not allow public access, Diachenko tells ISMG.
"Many companies, government agencies and individuals safely store their most private and sensitive data using Amazon S3 repositories. Under normal conditions, there are no problems or issues when users apply even the minimum cyber security measures. The reason to choose an Amazon S3 repository is it offers a simple web services interface and allows users to store and retrieve any amount of data, at any time, from anywhere on the web."
In the case of the recent incident involving the patient monitoring data, "it appears that a misconfigured Amazon S3 bucket was the culprit," he says.
"All the AWS buckets are protected by default. Seems like administrators manually changed important security settings that were set to 'public' instead of 'private,' allowing anyone with an internet connection to gain access to the repository," Diachenko says. "This was not a hack, and no password was needed to access the data. It literally was laying out in the open for anyone to see."
In terms of the data collected from patients and kept in the repository, Diachenko says it appears the individuals used meter devices from Abbott Labs or Roche to measure the time it takes for their blood to clot while being treated on an anti-coagulation medication. "Once they have the completed test strips ... users to upload the data to their web account or call an account manager on the phone to manually enter the information," he says.
In a similar incident back in February, Emory Healthcare reported a breach involving patient appointment data allegedly exposed on the web via a misconfigured MongoDB database (see Emory Healthcare Data Breach: What Happened?).
Like the latest breach involving the patient monitoring data, the discovery of the security incident involving the Emory patient data was made by security researchers at MacKeeper, a unit of Kromtech.
In a February statement posted on its website, Atlanta, Ga.-based Emory Healthcare said that on Jan. 3, the organization "learned that there was unauthorized access to [its patient appointment] waits & delays database around the New Year's weekend after someone deleted the database and demanded that EHC pay to have it restored."
In addition to the extortion attack on the database, Emory Healthcare said in its notification statement that it also learned "that there was another unauthorized access by an independent security research center that searches out vulnerabilities in applications and traditionally notifies the company so that it can be remedied."
At that time, MacKeeper confirmed discovering the misconfigured Emory Healthcare database. "What we do during our security audit research is analysis of data received via publicly available Shodan API," MacKeeper said.
When MacKeeper reached out to Emory about its Dec. 30 discovery of an alleged misconfigured Mongo database containing what appeared to be information on thousands of patients, "we never heard back from Emory," Diachenko says. "When we went back to review the data, it was identified that the database had been a victim of the [hacker] Harak1r1 ...," he says.
The Emory breach was reported to the Department of Health and Human Services on Feb. 21 as a hacking incident affecting nearly 80,000 individuals.
Because Kromtech called attention to both the Patient Home Monitoring and Emory Healthcare incidents, one security expert calls into question alleged "ambulance chaser" practices of some security research firms that hunt down these kinds of vulnerabilities, looking for mistakes to publicize for their own marketing purposes.
In response, Kromtech of Diachenko tells ISMG: "In many cases, we even don't hear back from the affected companies and, of course, our goal here is to prevent similar cases from happening by identifying the reasons behind the breach and raising awareness on the simple cyber hygiene rules. "We do that by following responsible disclosure policy and we never report a non-secured breach."
Check Your Configuration
Kate Borten, president of the security and privacy consultancy The Marblehead Group, says the latest incident involving the allegedly leaked patient monitoring data offers an important reminder to other entities.
"Every organization using AWS should immediately check their configuration including S3. Reportedly, S3 defaults to 'public.' All default settings should be examined to determine if they are appropriate," she stresses.
"Many organizations rely on big cloud providers, including AWS and Microsoft Azure, and assume that these providers are conscientious about security. This situation shows that trust is misplaced."
It is ultimately the customer's responsibility to verify security configurations, she adds.
Mac McMillan, president of security consultancy CynergisTek, says the issue involving the publicly accessible repository "could be avoided by simply applying an appropriate security checklist when standing up a cloud repository, and then testing afterward to make sure nothing was missed. There are readily available cloud security frameworks and guides for just this thing. Start using them."
Misconfiguration usually occurs, McMillan claims, when an organization deploying its service in the cloud lacks "a mature security program or in some cases anyone dedicated to managing security.
"Healthcare entities using these services should have the right processes to review what the vendor is doing. Patients can ask if their data is secure, but it's really an unfair situation as most patients will have no knowledge of what is required to secure the data, nor are they likely to be even aware that the vendor is using a cloud vendor to store their information."