A legal blog about the law of information by Dan Michaluk of Borden Ladner Gervais LLP
Teaching is the best way of learning for some, including me. Here are two recent cyber security presentations that may be of interest:
If you have questions please get in touch!
Manitoba Ombudsman Jill Perron has issued her report into Manitoba Families’ 2020 e-mail incident. The incident involved the inadvertent e-mailing of personal health information belonging to 8,900 children in receipt of disability services to approximately 100 external agencies and community advocates. It is such a common incident that it is worth outlining the Ombudsman’s incident response findings.
Manitoba Families meant to transfer the information to the Manitoba Advocate for Children and Youth to support a program review. It included information about services received. Some records included diagnoses.
Manitoba Families mistakenly blind copied the external agencies and advocates on an e-mail that included the information in an encrypted file and a follow-up e-mail that included the password to the file. It had made the same mistake about a week earlier. Several agencies alerted Manitoba Families to its error, and it began containment within a half hour.
The Ombudsman held that Manitoba Families’ containment effort was reasonable. She described it as follows.
Attempts at recalling the email began minutes later at 8:29 a.m. and continued at various intervals. Also, at 8:35 a.m., CDS sent an email to all unintended recipients noting in bold that they were incorrectly included on a confidential email from Children’s disAbility Services and requested immediate deletion of the email and any attachments. Follow up calls to the unintended recipients by CDS program staff began to occur that morning to request deletion of the emails and a list was created to track these calls and the outcomes. A communication outline was created for these calls which included a request to delete emails, a further request that emails be deleted from the deleted folder and that any emails that went to a junk email folder also be deleted…
In January 2021, we received additional written communication from the program stating that all agency service providers and advocates were contacted and verified deletion of the personal health information received in error. The log form created to track and monitor the name of the organization, the date and details of the contact was provided to our office.
The Ombudsman reached a similar finding regarding Manitoba Families’ notification effort, though she needed to recommend that Manitoba Families identify the agencies and advocates to affected individuals, which Manitoba Families agreed to do upon request.
What’s most significant – especially given class action proceedings have been commenced – is a point the Ombudsman made about evidence that Manitoba Families appears not to have gathered.
In addition to assuring families about the deletion of the email, additional information such as who viewed the email, if the attachment was opened and read, whether it was forwarded to anyone else or printed, whether it was stored in any other network drive or paper file or, conversely, that no records exist – can be helpful information to provide those affected by a privacy breach. It is best practice, therefore, to provide families with as much assurance as possible about the security of their child’s health information.
The question is, what is one to make of an arguable shortcoming in an incident response investigation? I say “arguable” because the probability of any of these actions occurring is very low in the unique circumstances of this incident, which involved trusted individuals receiving a password-protected and encrypted file. Manitoba Families ought to have collected this evidence because they called the e-mail recipients anyway, it is helpful and was probably available for collection. If it did not do so, however, I believe it is perfectly acceptable to for Manitoba Families to stand by the scope of a narrower investigation and and put the plaintiff to proof.
Hat tip to my good colleague Francois Joli-Coeur, who let our group know yesterday that the OIPC Alberta has issued a number of breach notification decisions about the Blackbaud incident, finding in each one that it gave rise to a “real risk of significant harm” that warrants notification and reporting under Alberta PIPA.
Blackbaud is a cloud service provider to organizations engaged in fundraising who suffered a ransomware incident last spring in which hackers exfiltrated the personal information of donors and educational institution alumni. The true scope of the incident is unknown, but likely large, affecting millions of individuals across the globe.
Blackbaud issued notably strong communications that de-emphasized the risk of harm. It rested primarily on the payment of a ransom, assurances by the threat actors that they would delete all data in exchange for payment and its ongoing dark web searches. Most affected institutions (Blackbaud clients) notified anyway.
On my count the OIPC issued seven breach notification decisions about the incident late last year, each time finding a “real risk.” In a decision involving an American college with donors or alumni in Alberta, the OIPC said:
In my view, a reasonable person would consider the likelihood of significant harm resulting from this incident is increased because the personal information was compromised due to a deliberate unauthorized intrusion by a cybercriminal. The Organization reported that the cybercriminal both accessed and stole the personal information at issue. The Organization can only assume that cybercriminal did not or will not misuse, disseminate or otherwise make available publicly the personal information at issue.
This is not surprising, but tells us how the OIPC feels about the assurance gained from paying a ransom to recover stolen data.
Here is a non-law post to pass on some ideas about root cause analysis, The Five Whys, and incident response.
This is inspired by having finished reading The Lean Startup by Eric Ries. It’s a good book end-to-end, but Ries’ chapter on adaptive organizations and The Five Whys was most interesting to me – inspiring even!
The Five Whys is a well-known analytical tool that supports root cause analysis. Taichii Ohno, the father of the Toyota Production System, described it as “the basis of Toyota’s scientific approach.” By asking why a problem has occurred five times – therefore probing five causes deep – Ohno says, “the nature of the problem as well as its solution becomes clear.” Pushing to deeper causes of a failure is plainly important; if only the surface causes of a failure are addressed, the failure is near certain to recur.
Reis, in a book geared to startups, explains how to use The Five Whys as an “automatic speed regulator” in businesses that face failures in driving rapidly to market. The outcome of The Five Whys process, according to Ries, is to make a “proportional” investment in corrections at each five layers of the causal analysis – proportional in relation to to the significance of the problem.
Of course, root cause analysis is part of security incident response. The National Institute of Standards and Technology suggests that taking steps to prevent recurrences is both part of eradication and recovery and the post-incident phase. My own experience is that root cause analysis in incident response is often done poorly – with remedial measures almost always targeted at surface level causes. What I did not understand until reading Ries, is that conducting the kind of good root cause analysis associated with The Five Whys is HARD.
Ries explains that conducting root cause analysis without a strong culture of mutual trust can devolve into The Five Blames. He gives some good tips on how to implement The Five Whys despite this challenge: establishing norms around accepting the first mistake, starting with less than the full analytical process and using a “master” from the executive ranks to sponsor root cause analysis.
From my perspective, I’ll now expect a little less insight out of clients who are in the heat of crises. It may be okay to go a couple levels deep while an incident is still live and while some process owners are not even apprised of the incident – just deep enough to find some meaningful resolutions to communicate to regulators and other stakeholders. It may be okay to tell these stakeholders “we will [also] look into our processes and make appropriate improvements to prevent a recurrence” – text frequently proposed by clients for notification letters and reports.
What clients should do, however is commit to conducting good root cause analysis as part of the post-incident phase:
*Write The Five Whys into your incident response policy.
*Stipulate that a meeting will be held.
*Stipulate that everyone with a share of the problem will be invited.
*Commit to making a proportional investment to address each identified cause.
Ries would lead us to believe that this will be both unenjoyable yet invaluable – good reason to use your incident response policy to help it become part of your organization’s discipline.
Two publications released earlier this month illustrate different views on how to structure ransomware response, and in particular on how to structure the involvement of legal counsel.
On Wednesday of last week, the Ontario Ministry of Government Services issued a bulletin entitled “What is Ransomware and How to Prevent Ransomware Attacks” to the broader public sector. It features a preparation and response playbook that will be much appreciated by the hospitals, universities, colleges, school boards and municipalities targeted by the MGS.
The playbook treats ransomware response as primarily a technical problem – i.e., a problem about restoration of IT services. Legal counsel is mentioned in a statement about incident preparation, but is assigned no role in the heart of the response process. Indeed, the MGS suggests that the Information and Privacy Commissioner/Ontario is the source of advice, even “early on” in an incident:
If you are unable to rule out whether or not PII was compromised (which will likely be the case early on in an incident), contact the Privacy Commissioner of Ontario (416) 326-3333.
Contrast this with what Coveware says in its very significant Q3 ransomware trends report that it released on November 4th. Coveware – arguably the best source of ransomware data – explains that data exfiltration threats now feature in 50% of ransomware incidents and that ransom payments are a poor (and becoming poorer) method of preventing threat actors from leaking what they take. Coveware says:
Accordingly, we strongly advise all victims of data exfiltration to take the hard, but responsible steps. Those include getting the advice of competent privacy attorneys, performing an investigation into what data was taken, and performing the necessary notifications that result from that investigation and counsel. Paying a threat actor does not discharge any of the above, and given the outcomes that we have recently seen, paying a threat actor not to leak stolen data provides almost no benefit to the victim. There may be other reasons to consider, such as brand damage or longer term liability, and all considerations should be made before a strategy is set.
The Coveware view, shared by Canadian cyber-insurers, is that ransomware is primarily a legal and reputational problem, with significant downside legal risks for institutions who do not engage early with legal counsel.
I favor this latter view, and will say quite clearly that it is bad practice to call a privacy regulator about a potentially significant privacy problem before calling a privacy lawyer. A regulator is not an advisor in this context.
This is not a position I take out of self-interest, nor do I believe that lawyers should always be engaged to coordinate incident response. As I’ve argued, the routine use of lawyers as incident coordinators can create problems in claiming privilege when lawyer engagement truly is for the “dominant purpose of existing or anticipated litigation.” My point is that ransomware attacks, especially how they are trending, leave institutions in a legal minefield. Institutions – though they may not know it – have a deep need to involve trusted counsel from the very start.
Here’s a copy of a presentation I gave yesterday at the High Technology Crime Investigation Association virtual conference. It adresses the cyber security pressures on public bodies that arise out of access-to-information legislation, with a segment on how public sector incident response differs from incident response in the private sector
The IPC/Ontario has issued a significant decision about information governance under the Personal Health Information Protection Act. Specifically, it held that a hospital that gives a physician access to an electronic medical record for use in private practice is a health information custodian together with the physician, but that it can retain a duty to notify of a breach arising out of the private practice.
Background
The hospital maintained an EMR system and gave access to its credentialed physicians and their employees for use in private practice. Employees in two such private practices accessed EMRs without authorization. The hospital notified affected patients and reported the breach to the IPC, which led the IPC to investigate.
In the course of investigation it came to light that some of the employees had shared their login credentials with others outside of the hospital, but apparently to enable health care. The employees also apparently accessed some records (for non-health care purposes) with the consent of friends of family members. Both of these actions violated hospital policy.
Decision
The IPC held that the access enabled by credential sharing and the access made with the consent of family members was made in breach of PHIPA. Although a more benign form of unauthorized access, the IPC found a breach based on section 10(2) of PHIPA, which states, “A health information custodian shall comply with its information practices.”
Regarding the identity of the custodian, the IPC held that both the hospital and the two private practice physicians were custodians in the circumstances – the physicians being custodians “when they access patient information in [the EMR] for the purpose of privatizing health care to their private practice patients.” Such access, the IPC explained, invites a disclosure by the hospital and a collection by the physicians; in this context the physicians were not the hospitals’ agents.
Despite the physicians’ custodianship, the IPC held it was appropriate for the hospital to notify in the circumstances. It said:
[122] In the cases under review, THP and the private practice physicians also treated THP as the health information custodian responsible for notifying affected individuals of the private practice employees’ unauthorized accesses in THP’s EMR. In these circumstances, I agree that THP was the appropriate party to give notice under section 12(2) of PHIPA. As the health information custodian who maintains the EMR, THP was best placed to discover and investigate the extent of the employees’ activity in the EMR, identify all the parties whose personal health information had been accessed without authority, and initiate contact with these individuals, all of whom are THP patients, but some of whom may not have any relationship with the particular private practice physician for whom the employee worked. In these cases, notification by THP was appropriate, taking into account not only the language of section 12(2)[29] but also the interests of the affected individuals.
[123] I also agree with THP that in some circumstances, notification by the collecting custodian may be more appropriate, and a reasonable approach to fulfilling the notice obligation in section 12(2). For example, in a case where the private practice physician has a more significant relationship with the patient whose privacy was breached, notice from that physician (rather than from the custodian who disclosed the information) may be prudent. So long as the notice is given as required upon the events described in section 12(2) (and complies with the other requirements of that section), I agree with THP that circumstances such as the patient’s interests and the relationships between the patients and the various custodians involved may be relevant factors in deciding how best to fulfil the notification obligation. I am not persuaded that applying such an approach to notification in future cases would have the consequences of discouraging hospitals from adopting EMR technologies, or from participating in broader initiatives like a provincial electronic health record system.
Implications
The kind of shared accountability invited by this decision can cause confusion and risk. It will behoove hospitals and other custodians who provide shared access to their EMR systems to be very clear and detailed in establishing who is responsible for what. The hospital in this case, for example, decided post-incident to make more clear that physicians who are given outside access are responsible for training and supervising their employees. It also expressly obligated physicians to participate in privacy investigations arising from the actions of an employee.
The IPC’s finding on who provides notification is very qualified, and rests partly on the fact that the hospital in this case voluntarily provided notification to affected individuals. While taking control of notification may be beneficial to hospitals who maintain and provide third-party access to EMR systems, providing notification may also signal responsibility for a breach and for the related risks for which hospitals have little or no ability to control. The hospital in this case dealt with this tension by stipulating to its physicians that they may be named in hospital notification letters “as being responsible for the breach.” Other hospitals, may wish to require physicians to notify themselves in certain circumstances. The IPC’s decision does not appear to preclude such alternatives.
I’m off to a cyber conference in Montreal this week to sit on a panel about threat exchanges. My role will be to address the legal risks associated with sharing threat information and a university’s ability to effectively assert a confidentiality interest in the same information. I’m genuinely interested in the topic and have prepared not just one, but two papers!
Here is the first one – a nuts and bots presentation on privilege and data security incident response. I hope it is useful to you. Feedback welcome through PMs.
I’d encourage you to read David Fraser’s blog post from last weekend – The value of legal privilege: Your diligent privacy consultant may become your worst enemy.
David’s basic point is sound: structuring a security or privacy expert retainer to support a privilege claim can prevent your own expert’s advice from being used against you. Most often this is done by having legal counsel retain an expert in anticipation of litigation and for the dominant purpose of litigation, with instructions and conclusions going strictly between counsel and expert.
David explains a scenario in which an organization retained an expert to advise on some form of due diligence connected to a subsequent security incident. The expert was apparently quite candid in its written advice, outlining a security problem that amounted to what David compares to a “dumpster fire.” The organization responded partly but not wholly to the expert’s recommendations. That expert’s report will therefore become, as David says, the plaintiff’s Exhibit A.
Being faced with your own expert’s advice is very bad, hence the soundness of David’s point. My additional point: legal privilege is no solution to a bad client-counsel-expert relationship.
The views on what is a reasonable investigation or remediation in the data security context can vary widely between equally qualified experts. Too often, perhaps driven by conflicting interests, security experts recommend what’s possible and rather than what is “due.” A breach coach can help address this problem, identifying trusted experts and working with them to reach a shared and acceptable understanding of the due diligence required in responding to a security incident. With such a relationship, departing from an expert’s recommendations (even though they are privileged) represents a real and meaningful risk. The facts – i.e., the things done based on an expert’s recommendations – are never privileged. If litigation ensues those facts will be picked apart by other experts, and you want the good ones to view the facts the same way as you and your trusted advisor.
Experts that are prone to floating long lists of options need to be retained under privilege because they are dangerous, but even under privilege their advice is worth little. The prescription: do everything you can to build a great client-counsel-expert relationship. Use a breach coach. Keep a roster of trusted experts on retainer. Don’t use experts retained for due diligence advice to do the very remedial work they recommend.
When an employer confronts an employee with an allegation of improper access to personal information, it is important to give the employee the event log data that proves the allegation. It may often be voluminous and difficult to interpret, but presenting a general allegation or summarizing events without particulars will give the employee a good reason to deny the allegation.
This is what happened in this very illustrative British Columbia case in which an arbitrator held he could not infer dishonesty from the grievor’s initial failure to admit wrongdoing because the grievor had not been given log data. Also, if an employee continues to deny responsibility, log data can be difficult to rely upon; even if it can be established to be authentic, there are issues about presenting log data in a meaningful and privacy-protective way. An early admission can go a long way.
All About Information 
You must be logged in to post a comment.