By Eric Goldberg
Security breaches show no signs of slowing down in 2018, and the ramifications of them can be costly for the organizations involved—especially if the response to the incident isn’t handled in a timely way. Case in point: a recent error that exposed over 19,000 of Orlando Orthopaedic Center’s patient records for roughly two months. The breach happened when a third party they worked with, a transcription service, underwent a software upgrade and left the server open to the public without requiring authentication.
I sat down with Nikolay Filipets, Vendor Risk Management Product Manager at Rsam, for a debriefing on the situation and his expert opinion on avoiding more security breaches and enabling better third-party IT risk management in healthcare.
Vendor Risk Assessments and ePHI
Eric: Healthcare organizations work with so many vendors that it can be difficult to complete appropriate risk assessments. What’s your advice for an organization managing electronic protected health information (ePHI)?
Nikolay: There are a few problematic issues in the Orlando Orthopaedic Center case that we can learn from. Organizations need a certain level of maturity in both their vendor assessment and internal processes. There are controls an organization should have in the pre-engagement stage with a vendor, and internal controls that help them monitor their internal systems as well as the services a vendor provides.
In this case, they didn’t do a good job vetting their transcription vendor, since the vendor obviously did not have the ability to manage database access and control. And secondly, they probably didn’t invest a lot of time and effort to monitor their environment. If they did, they would have been able to detect things like an open port or improperly configured database, so it’s kind of a two-fold issue.
Shared Risk and Organizational Responsibility
Eric: This situation touches on the issue of shared risk. The Orlando Orthopaedic Center likely thought they were following HIPAA guidelines and doing all the right things. However, when this breach happened through a third-party, the Office of Civil Rights (OCR) isn’t going to come after the transcriptionist that had the problem. They’ll come after the Orlando Orthopaedic Center.
Nikolay: Absolutely, the Orlando Othopaedic Center, in this case, is the responsible party and they failed to apply controls to manage their patients’ data. This goes back to another issue that comes up very often these days: brand management. Firstly, they failed to protect their patients’ data and, secondly, they failed to comply with local laws to report the breach; they were nearly 6 months past due to report this [when they finally did]. When cases like this become public, of course it’s going to have an impact on the organization’s reputation in the state and their brand value.
HIPAA Requirements and Deadlines for Reporting
Eric: Under HIPAA, organizations are given 60 days to notify the U.S. Department of Health and Human Services (HHS) about the breach discovery. As you mentioned, in this instance it was a much longer timeframe—nearly six months before patients were notified.
Nikolay: Yes, in this case, everything seemed to go wrong. They didn’t vet their suppliers, they didn’t have the right controls internally to detect the problem and they waited too long to report it. They became a case study of what not to do. These organizations get hit with outrageous fines just to discourage everyone else to not drop the ball. And if you do, you better fix it as quickly as possible and report it correctly.
Causes of Delay in Breach Reporting
Eric: What do you think are the issues at play that would cause an organization to take so long to respond?
Nikolay: It could be poor management practice or a collusion internally to not report it, but that’s usually unlikely. [Another possibility is] they may not have a process to report it or didn’t involve their legal department in their risk management process, so they didn’t know they needed to report it. A lot of times IT personnel is not well-versed in all of the legal requirements around a situation like this.
The Need for a Playbook and Process
Eric: There likely was no playbook for breach notifications so they didn’t have a process around who is notified, who needs to sign off, what’s the workflow around notifications and tracking. If you’re not anticipating a breach and you don’t have a playbook around incident response, it makes sense that it would take longer than 60 days. That 60-day window is relatively short to make clear what was breached.
Nikolay: I think the key here is you need a process and playbook as part of your program and vendor risk management checklist. Keep in mind that a playbook won’t always save you. A lot of times, just having a playbook doesn’t mean that it has been tested and everyone involved knows their responsibilities. The best way to approach these kinds of incidents would be to have a system that would automatically notify involved stakeholders up to the state officials, because sometimes when incidents get cited they don’t necessarily get tracked. However, if the system is automated, you can notify everyone involved much more easily.
Automation Is the “Easy” Button
Eric: With an automated system, it’s very easy to say to check on the workflow and notification status. If you’re trying to do this via email, which many organizations do, you’ll run into situations like “I thought I cc’d you on this, or maybe I didn’t respond to the last message on the thread.” So trying to handle incident responses like this through email is going to make it difficult to meet that 60-day HIPPA requirement. It’s interesting to note that one of the other cases I can remember, Presence Health, was hit with an almost $500,000 fine. And they were only 40 days late in their notification.
Nikolay: I really do believe that it’s not sometime malicious internally, but more just a matter of if not being prepared and not having a process in place. In those cases, the 60-day notification standard can be difficult to hit because you want to make sure you’re presenting the right information, you want to lay out what happened and what information was leaked, and gathering that information can be challenging if there’s not a process, automation and notifications around that.
An Added Complication: Fourth-Party Risk
Eric: As I understand this hack, essentially the culpable party in this situation was the transcription vendor for the Orlando Orthopaedic Cetner. They upgraded their software in December 2017. In the process, the server was left open to the public and it allowed access without authentication, and that’s where the hack happened.
One of the things I wonder is, is this transcription service doing their own server maintenance or is it in fact, someone this transcriptionist has contracted out to do maintenance on their servers—ostensibly a fourth-party risk?
Nikolay: Yes, that could be the case. Just the fact that an organization like the transcriptionist is allowing another party to do maintenance on their servers means they have access to the database, they have access to all the ePHI—which means at the very least they should have been subject to the same controls that the Orlando Orthopaedic Center placed on their third-party vendors.
A Better Strategy for Vendor Risk Assessments
Eric: In one of our recent webinars for security professionals, we discovered that more than 50 percent of organizations are only able to assess less than 15 percent of their total vendors. The reason given is that even a small organization can have hundreds and hundreds of third parties that they work with. What would you recommend to organizations related to strategies and assessments, to make sure they’re spending the time with the most critical vendors?
Nikolay: It’s really looking at your vendors through a risk-based approach. For vendor risk that means is determining what is most important to you and what you want to safeguard within your organization. Is it your patients’ data, is it your data about your secret sauce or some patent that you hold or developed? Whatever the case is, determine your criteria and assess who is managing the data, who has access over it, and who controls it. That will give you the best place to concentrate and outline who are the most critical vendors to assess.
Start by Developing Risk Categories
Eric: We’ve seen this in the past, it’s really beneficial to do a mini-survey with all your vendors to understand the risk classification that you want to have for those vendors. Once you identify those risk profiles, the next step is to identify a subset of high-risk vendors. For instance, you may have 250 vendors but only 30 interactive with ePHI. Through that vendor management questionnaire, you create different risk categories for and can then do a deeper dive into, for example, this transcriptionist who has access to your data and has a fourth-party risk as well.
Is there parting advice you have for someone who’s worried about becoming the next topic of conversation for a similar breach?
Nikolay: For risk management in general, I would advise everyone to work closely with your stakeholders. Work with IT, work with your finance organization and with your legal advisors.Make sure everyone is on the same page. Know who you’re paying for what services, what they’re supposed to be doing for you, and what kind of access they truly need versus what they actually have.