Third-Party Vendor at Center of Breach
An incident involving a third-party vendor migrating a server containing archived email of emergency medical device provider Zoll has resulted in a reported health data breach impacting more than 277,000 individuals.
As of Thursday, the incident is the fourth largest health data breach listed so far in 2019 on the Department of Health and Human Services’ HIPAA Breach Reporting Tool website.
Commonly called the “wall of shame,” the website lists health data breaches impacting 500 or more individuals.
Pennsylvania-based Zoll, which provides emergency medical products such as wearable heart defibrillators, therapeutic temperature management systems, and ventilation devices, reported the breach on March 18 to HHS as a hacking/IT incident involving a network server and a business associate.
The incident was reported as impacting 277,319 individuals.
In a March 18 statement, Zoll notes that its email is archived by a third-party service provider to comply with record retention and maintenance requirements, policies and procedures.
“During a server migration, some data from Zoll emails was exposed. The vendor believes that the incident occurred between Nov. 8, 2018 and Dec. 28, 2018,” Zoll says.
“At this point, Zoll is not aware of any fraud or identity theft to any individual as a result of this exposure. The vendor has since confirmed that all information has now been secured.”
Information potentially exposed includes patient names, addresses, dates of birth, and limited medical information. A small percentage of patients also had Social Security numbers exposed, Zoll says. The company is offering free credit and identity monitoring services for one year to impacted patients.
“Upon learning of the incident, Zoll immediately initiated an internal review and retained a leading independent forensics firm to conduct a thorough investigation of the incident,” the company says. “Law enforcement and federal and state agencies have been notified to give them the opportunity to further investigate.”
“Email should be encrypted if it contains sensitive data, like PHI in transmission or at rest.”
—Mark Johnson, LBMC Information Security
In addition, Zoll says it is taking steps to review its process for managing third party vendors and confirmed that the impacted vendor has also taken actions to help prevent against similar incidents in the future.
Zoll declined an Information Security Media Group request to identify the vendor involved in the incident.
Just the Latest Incident
The incident involving Zoll and a third-party service provider is among the latest health data security mishaps involving vendors and server-related snafus.
For instance, earlier this week, Sacramento, Calif.-based Meditab Software Inc., which provides fax services and more for healthcare providers, confirmed a report by a security researcher that the vendor leaked patient records through a fax server that was hosted by a subdomain of one of its affiliate companies, MedPharm Services, based in Puerto Rico (see Unsecure Fax Server Leaked Patient Data).
In the Zoll situation, “it seems that the organization was leveraging a third party to accomplish email retention and maintenance requirements,” notes Mark Johnson, a former healthcare CISO and currently a shareholder at consultancy LBMC Information Security.
“In my view this is not unlike any other record retention for back-up, disaster recovery, or regulatory requirement. Therefore, this is not per se an email issue. This is more of a record retention issue,” he says.
“However, in general, email should be encrypted if it contains sensitive data, like PHI in transmission or at rest. But if the system is on, it is technically not at rest, so encryption is not really applicable here. Data loss prevention is also a great idea, if configured correctly.”
Any migration presents risk, Johnson adds. “Typically, migrations are large changes, from one version to another or from one solution to a different solution. Any large change has many moving parts,” he says.
“This event is doubly hard, since it wasn’t the organization who made the change, but their vendor,” Johnson adds. “This highlights an area that most miss in their vendor risk management process: How does the vendor plan and execute major changes – for example, migrations – so events like this don’t happen.”
Every vendor, like any other organization, changes their infrastructure, he notes. “Products are updated, organizations change products, all the time. So, cybersecurity must be part of that process. Vendor risk management should understand how cybersecurity is involved in these efforts to understand the risk.”
Critical Steps for PHI Security
Tom Walsh, president of tw-Security, notes that covered entities and their vendors need to take a variety of critical steps to prevent PHI from being exposed during email and other server migrations.
For starters, make sure the staff doing the migration is well-rested, he says. “In most cases, migrations take place afterhours to minimize business disruption of services. If the IT staff has already worked a full shift and is then expected to either stay late or report back later that night to the make the migration – they may be tired,” he says. “Mistakes are more likely to happen when people are tired.”
“It is important to remove real identifiers from non-production systems when no longer in use.”
—Tom Walsh, tw-Security
Also, it’s critical to review access controls and user access/rights prior to the migration, he notes.
“User access rights have a tendency to drift over time, giving some users more access rights than what are needed. There may be some accounts with elevated privileges or system administrator rights giving them direct access to the whole database of emails as opposed to just a single user’s mailbox,” he says.
Reviewing the server settings or rules is also important, Walsh says. “Test environments or staging environments need the same level of security controls as production environments. Because these servers are ‘temporarily’ being used, sometimes organizations let down their guard to make it easier to do the migration,” he notes.
Next, entities need to ensure that server migrations have proper oversight, including securing data that’s involved. “Updates or migrations can be perceived as routine or sometimes ‘grunt work’ and may not have the attention of the information security officer or even a higher-level of technical expertise overseeing the migration.”
Walsh also suggests purging data when finished with server migrations. “Many of the reported data breaches have occurred with old data left on test systems, staging environments, and on decommissioned servers. It is important to remove real identifiers from nonproduction systems when no longer in use,” he says.
Finally, change control/change management should never be short-changed, he says.
“While most organizations today strictly follow change control processes for production applications, the discipline is often lacking when it comes to general support systems such as network equipment and email,” Walsh says.
“Because formal change control involves documentation and meetings, some IT staff may not see any value in doing change control. That is of course, until something bad happens during an upgrade or a migration, as in this case.”
Date: March 26, 2019