1. Skip to navigation
  2. Skip to content
  3. Skip to sidebar

New Guidance on Disclosure Exceptions for Investigations and Fraud

On March 17, 2017, the  Office of the Privacy Commissioner of Canada (OPC) published guidance on two new exceptions in PIPEDA permitting disclosure without consent. The guidance is very helpful to interpreting these new provisions and the OPC’s expectations of organizations. However, as expected, there is an undercurrent to the guidance suggesting that that the OPC would like to restrict organizations from setting up systematic information-sharing programs. This is very unfortunate given that these provisions are directly connected to improving confidence in the digital economy. Systematic sharing of information, particularly for fraud detection, suppression and prevention should be able to be accomplished if PIPEDA is truly technologically neutral. Without these tools, the OPC is incentivizing organizations to use much less transparent methods, such as predictive analytics.

Background

The Digital Privacy Act, 2015, amended Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA) to lower the threshold for when an organization could share personal information without the knowledge or consent of the individual for the purposes of an investigation into a breach of an agreement or a contravention of the laws of Canada. In addition, the Digital Privacy Act, 2015, added a new exception to PIPEDA to permit the disclosure of personal information without the knowledge or consent of the individual for the purpose of the detection or suppressing fraud or preventing fraud that is likely to be committed.

7(3) […] an organization may disclose personal information without the knowledge or consent of the individual only if the disclosure is

(d.1) made to another organization and is reasonable for the purposes of investigating a breach of an agreement or a contravention of the laws of Canada or a province that has been, is being or is about to be committed and it is reasonable to expect that disclosure with the knowledge or consent of the individual would compromise the investigation;

(d.2) made to another organization and is reasonable for the purposes of detecting or suppressing fraud or of preventing fraud that is likely to be committed and it is reasonable to expect that the disclosure with the knowledge or consent of the individual would compromise the ability to prevent, detect or suppress the fraud;

The OPC did not support these amendments. Even before these amendments were passed and came into force, the OPC was sounding alarms that it would interpret these provisions narrowly.  In particular, the OPC was concerned about two issues:

First, the triggering threshold for a permitted disclosure was changed. Under the previous provisions, organizations had to have reasonable grounds to believe that the information related to a breach of an agreement or contravention of law. Following the amendments, an organization only had to determine that the disclosure was reasonable for the purpose of investigating a breach of an agreement or a contravention of a law or reasonable for the purpose of detecting, suppressing or preventing fraud.

Second, the range of purposes were too broad in the OPC’s view. In particular, the OPC was concerned about the possibility of oversharing under the fraud exception.

OPC Guidance

The OPC’s guidance is an attempt to ensure that organizations interpret these provisions narrowly. Although the OPC does not state expressly state that organizations cannot participate in systematic programs to attempt to detect or prevent fraud or breaches of agreements, it is clear that the OPC would prefer that these exceptions be used in isolated circumstances. This is particularly evident in the OPC’s statement that organizations must be able to establish on a case-by-case basis the reasons why it determined that disclosure was appropriate.

The OPC recommends that organizations prepare policies and procedures and to make those available to individuals. The OPC reminds organizations that individuals have the right to make an access request and obtain an account of the third parties to which information has been disclosed. The OPC would also like to see organizations report publicly on the number and type of disclosures made. It should be noted that there is no legislative basis that would require such reporting.

To satisfy the OPC’s concerns about indiscriminate use of these provisions, organizations should develop polices and procedures to ensure that the preconditions to disclosure are met and should make these policies and procedures available on demand.

Although the OPC seems to suggest that organizations should include disclosure of the use of these exceptions, it does not appear to be legislatively required to advise individuals in a privacy notice that the organization may use a lawful exception to disclose information without consent. Any such disclosure would have to be at a very high level unless the organization was participating in a systematic program to share information. What could an organization meaningfully say in the case of a disclosure under the investigation exception? Nevertheless, there are clear benefits to at least mentioning the possibility of these types of disclosures to prevent later accusations that the organization failed to be transparent.

Recommendations

When developing a policy or procedure for disclosures relating to an investigation into a breach of an agreement or the contravention of a law of Canada, organizations should require that, at a minimum, the following criteria (and the common criteria set out below) are met before disclosure:

  • If the investigation relates to a law, it is a law of Canada. The law should be specified and documented. A breach of a foreign law is not covered by this exception.
  • If the investigation relates to a breach of an agreement, the agreement is documented and in force at the time of the alleged breach.
  • The breach or contravention has already taken place, is ongoing or is about to happen. This suggests that the organization must document must be some credible evidence of a breach of the agreement or a contravention of a law of Canada.
  • The investigation is a bona fide formal or systematic inquiry to determine the facts. It cannot be a fishing expedition or gossip.

The following are the minimum criteria for disclosures relating to detecting or suppressing fraud or of preventing fraud:

  • If the disclosure relates to detecting or suppressing fraud or preventing fraud that is likely to be committed.
  • In the case of preventing fraud, the risk of fraud is probable and not merely possible .
  • The type of fraud that is in issue should be documented.

The following common criteria apply to disclosures under either provision:

  • If the organization has received a request for disclosure under these provisions, the request provides sufficient information to ensure that the rationale for disclosure is documented in the request. Requests should not be taken at face value.
  • The disclosure will be made from one organization to another organization. These provisions do not permit disclosure to law enforcement or family members.
  • The disclosure is reasonably related and proportionate to the investigation of the breach of an agreement or a contravention of law or to the activities of detecting or suppressing fraud or preventing fraud that is likely to be committed. Organizations should document their rationale for why the information is necessary to assist in the investigation or is rationally connected to and effective the detection, suppression or prevention of fraud.
  • Obtaining the consent of the individual would compromise the investigation or the fraud detection, suppression or prevention purposes. The rationale for the organization’s decision should be documented.

For the text of the OPC’s Guidance, see: Applying paragraphs 7(3)(d.1) and 7(3)(d.2) of PIPEDA

,

New Guidance on Disclosure Exceptions for Investigations and Fraud

Private Right of Action under CASL coming July 2017

Canada’s Anti-Spam Law came into force on July 1, 2014.  Since then, all eyes have been on the Canadian Radio-television and Telecommunications Commission (CRTC) for decisions concerning CASL violations.  In the cases made public to date, monetary penalties or settlement payments have ranged from $48,000 to $1.1 million.  Canadian and foreign companies have learned some things in the past two years about how CASL applies to their business, and many have taken steps to put in place policies and procedures to avoid violations.

Whatever steps you have taken to date, 2017 will be the time to revisit CASL compliance

On July 1, 2017, the private right of action (PRA) comes into force under CASL.  An individual or organization who is affected by a contravention may litigate to enforce the new private rights directly.  While CASL does not expressly provide for class actions, it is broadly expected that such actions will be launched to permit large numbers of applicants (for example, the recipients of alleged spam) to pursue compensation as a group.

Where the court finds a violation, it may order not only compensation for the applicant’s damages, but also monetary payments up to the following amounts:

  • for sending commercial electronic messages contrary to CASL – $200 per contravention, to a maximum of $1 million for each day that the conduct occurred
  • for altering the transmission data of a commercial electronic message – a maximum of $1 million for each day that the conduct occurred
  • for installing apps or other computer programs contrary to CASL – a maximum of $1 million for each day that the conduct occurred
  • for scraping, generating or otherwise accessing electronic addresses contrary to PIPEDA – a maximum of $1 million for each day that the conduct occurred
  • for sending commercial electronic messages with false or misleading information, including sender, locator or subject matter information, contrary to the Competition Act – $200 per contravention, to a maximum of $1 million for each day that the conduct occurred

When the court sets the amount to be paid, it must consider the purpose of the payment order – which “is to promote compliance…and not to punish”, the nature and scope of the violation, the history of compliance, any financial benefit or compensation from the conduct, ability to pay, and “any other relevant factor”.

CASL also provides for extended liability.  Directors, officers, agents or mandataries of a corporation may be liable if they directed, authorized, assented to or participated in the contravention.  Where an employee’s conduct in the course of his or her employment breaches CASL, the employer may be vicariously liable.

Revisiting CASL

CASL provides that where a person establishes that they exercised due diligence to prevent a violation, they cannot be found to have contravened CASL.  Despite this provision, a number of well-meaning businesses have been found offside CASL’s provisions, have made significant penalty or settlement payments, and in some cases have received negative media coverage for their failure to meet CASL requirements.

In July 2017, the risk exposure will increase.  Now is the time to revisit your CASL compliance.

  1. Discuss with your Board and Senior Management team why you need to revisit CASL in 2017.
  2. Make sure that you have a CASL Compliance Policy and Procedure that covers your operations, and that is easy for employees to understand and use.
  3. Ensure that existing and new employees have access to – and receive appropriate training in – the Policy and Procedure.
  4. Conduct an audit under the Compliance Policy and Procedure, including how consent is obtained and documented; whether unsubscribe requests are fulfilled quickly; whether CASL-compliant message templates are consistently used; how complaints are addressed (etc.).
  5. Consider whether you need to check in with service providers (to send messages or install apps or other computer programs) about their CASL compliance.
  6. Consider whether service provider contracts include the appropriate clauses to address CASL compliance, liability, and indemnification.

See also:

Lessons Learned: E-Learning Company Faces $50K Spam Fine

CRTC Enforcement Advisory – Records to Show Consent

Privacy Law and Anti-Spam – Guidance from the Office of the Privacy Commissioner

Canada’s Anti-Spam Law: Not just for Canadians

CASL Applies to Software January 15 2015

New CASL Compliance and Enforcement Guidelines

 

, ,

Private Right of Action under CASL coming July 2017

NIST and USCG Issue New Maritime Industry Cybersecurity Profile

In 2013, President Obama issued Executive Order 13636 and directed the Director of the National Institute of Standards and Technology (NIST) to “lead the development of a framework to reduce cybersecurity risks to critical infrastructure” (Cybersecurity Framework).  The Cybersecurity Framework was published in February 2014.  A number of industries are integrating the Cybersecurity Framework, including by creating industry-focused Framework Profiles (Profiles) as described in the Cybersecurity Framework.

This month, NIST and the United States Coast Guard (USCG) released a “Maritime Bulk Liquids Transfer Cybersecurity Framework Profile” (Bulk Liquids Transfer Profile) to address the vulnerabilities in the transfer process of bulk hazardous liquids in the maritime industry.  These transfers are often a part of a sophisticated supply chain that uses multiple networked systems, and is therefore vulnerable to attack.   The new profile serves to assist in cybersecurity risk assessments for those entities involved in maritime bulk liquids transfer operations as overseen by the USCG, and is intended to act as “non-mandatory guidance to organizations conducting” maritime bulk liquids transfer operations within facilities and vessels under the regulatory control of the USCG under the Code of Federal Regulations 33 CFR 154-156.

The stated benefits of creating the new Bulk Liquids Transfer Profile include:

  • Compliance reporting becoming a byproduct of running an organization’s security operation;
  • Adding new security requirements will become more straightforward;
  • Adding or changing operational methodology will be less intrusive to ongoing operations;
  • Minimizing future work by future organizations;
  • Decreasing the chance that organizations will accidentally omit a requirement;
  • Facilitating understanding of the bulk liquid transfers environment to allow for consistent analysis of cybersecurity-risk; and
  • Aligning industry and USCG cybersecurity priorities.

Other benefits include strengthening strategic communications between:

  • Risk executives and operational technology integration of cybersecurity capabilities;
  • Personnel involved in cybersecurity governance processes and operational technology oversight; and
  • Enterprises who are just becoming aware of cybersecurity recommended practices with subject matter expertise and the collective wisdom of industry experts.

The new profile can be found here.

NIST and USCG Issue New Maritime Industry Cybersecurity Profile

Internet of Things (IoT) Security Takes Center Stage At FBI, DHS, NIST and Congress

On October 21, 2016, a domain name service host and internet management company experienced at least two waves of a distributed denial of service (DDoS) attack that impacted at least 80 websites, including those belonging to Netflix, Twitter and CNN.  The attack was launched by infecting millions of American’s Internet of Things (IoT) connected devices with a variation of the Mirai malware.  The Mirai malware primarily targets IoT devices such as routers, digital video records and webcams / security cameras by exploiting their use of default usernames and passwords and coordinating them into a botnet used to conduct DDoS attacks.  The U.S. Federal Bureau of Investigation (FBI) does not have confirmation of a group or individual responsible for the attack.  In September 2016, two of the largest IoT DDoS attacks using the same malware disrupted the operations of a gaming server and computer security blogger website.

In light of these attacks, there has been an increased focus on IoT security at the FBI, the U.S. Department of Homeland and Security (DHS), the National Institute of Standards and Technology (NIST) and Capitol Hill.

FBI Guidance

Five days after the October 21, 2016 attack, the FBI issued a Private Industry Notification, providing a list of precautionary measures stakeholders should take to mitigate “a range of potential DDoS threats and IoT compromise,” including but not limited to:

  • Having a DDoS mitigation strategy ready ahead of time and keeping logs of any potential attacks;
  • Implementing an incident response plan that includes DDoS mitigation.  The plan may involve external organizations such as law enforcement;
  • Implementing a data back-up and recovery plan to maintain copies of sensitive or proprietary data in a separate and secure location;
  • Reviewing reliance on easily identified internet connections for critical operations, particularly those shared with public facing web servers;
  • Ensuring upstream firewalls are in place to block incoming UDP packets;
  • Changing default credentials on all IoT devices; and
  • Ensuring that software or firmware updates are applied as soon as the device manufacturer releases them.

A copy of the FBI Notification can be found here.

DHS Guidance

On November 15, 2016, the DHS issued its own non-binding guidance for prioritizing IoT security, aimed at IoT developers, IoT manufacturers, service providers, industrial and business-level consumers.  According to the DHS, there are six non-binding principles that, if followed, will help account for security as stakeholders develop, manufacture, implement or use network-connected devices.

Principle #1 – Incorporate Security at the Design Phase

The DHS notes that security should be evaluated as an integral component of any network-connected device.  Building security “in at the design phase reduces potential disruptions and avoids the much more difficult and expensive endeavor of attempting to add security to products after they have been developed and deployed.”  To that end, the DHS suggests the following practices:

  • Enable security by default through unique, hard to crack default user names and passwords.
  • Build the device using the most recent operating system that is technically viable and economically feasible.
  • Use hardware that incorporates security features to strengthen the protection and integrity of the device.
  • Design with system and operational disruption in mind.

Principle #2 – Advance Security Updates and Vulnerability Management

Even when security is included at the design stage, vulnerabilities may be discovered in products after they have been sent to market.  The DHS notes these flaws can be mitigated through patching, security updates, and vulnerability management strategies.  Suggested practices include:

  • Consider ways to secure the device over network connections or through automated means.
  • Consider coordinating software updates among third-party vendors to address vulnerabilities and security improvements to ensure consumer devices have the complete set of current protections.
  • Develop automated mechanisms for addressing vulnerabilities.
  • Develop a policy regarding the coordinated disclosure of vulnerabilities, including associated security practices to address identified vulnerabilities.
  • Develop an end-of-life strategy for IoT products.

Principle #3 – Build on Proven Security Practices

According to the DHS, many tested practices used in traditional IT and network security can be applied to IoT, and can help identify vulnerabilities, detect irregularities, respond to potential incidents and recover from damage or disruption to IoT devices.  The DHS recommends NIST’s framework for cybersecurity risk management, which has widely been adopted by private industry and integrated across sectors.  Other suggested practices include:

  • Start with basic software security and cyber security practices, and apply them to the IoT ecosystem in flexible, adaptive and innovative ways.
  • Refer to relevant Sector-Specific Guidance, where it exists, as a starting point from which to consider security practices (e.g., the National Highway Traffic Safety Administration recently released guidance on Cybersecurity Best Practices for Modern Vehicles and the Food and Drug Administration released draft guidance on Postmarket Management of Cybersecurity in Medical Devices).
  • Practice defense in depth.
  • Participate in information sharing platforms to report vulnerabilities and receive timely and critical information about current cyber threats and vulnerabilities from public  and private partners.

Principle #4 – Prioritize Security Measures According to Potential Impact

The DHS recognizes that risk models differ substantially across the IoT ecosystem, and the consequences of a security failure will vary significantly.  The DHS therefore recommends:

  • Knowing a device’s intended use and environment, where possible;
  • Performing a “red-teaming” exercise where developers actively try to bypass the security measures needed at the application, network, data or physical layers; and
  • Identifying and authenticating the devices connected to the network, especially for industrial consumers and business networks.

Principle #5 – Promote Transparency Across IoT

Where possible, the DHS recommends that developers and manufacturers know their supply chain, and whether there are any associated vulnerabilities with the software and hardware components provided by vendors outside their organization.  This increased awareness could help manufacturers and industrial consumers identify where and how to apply security measures or build in redundancies.  Recommended practices include:

  • Conduct end-to-end risk assessments that account for both internal and third party vendor risks, where possible.
  • Consider the creation of a publicly disclosed mechanism for using vulnerability reports.
  • Consider developing and employing a software bill of materials that can be used as a means of building shared trust among vendors and manufacturers.

Principle #6 – Connect Carefully and Deliberately

The DHS notes that consumers, particularly in the industrial context, should “deliberately consider whether continuous connectivity is needed given the use of the IoT device and the risks associated with its disruption.”  To that end, suggested practices include:

  • Advise IoT consumers on the intended purpose of any network connections
  • Making intentional connections.
  • Build in controls to allow manufacturers, service providers, and consumers to disable network connections or specific ports when needed or desired to enable selective connectivity.

A copy of the DHS guidance can be found here.

NIST Guidelines

On November 15, 2016, NIST released its own guidance advising IoT manufacturers and developers to implement security safeguards and to monitor those systems on a regular basis.  NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems.  The new NIST Special Publication 800-160 is the product of four years of research and development, and focuses largely on engineering actions that are required to ensure connected devices are able to prevent and recover from cyber attacks, and lays out dozens of technical standards and security principles for developers to consider.

A complete copy of the NIST guidance can be found here.

Congressional Hearing

One day after the DHS and NIST guidance was released, on November 16, 2016, the House Committee on Energy and Commerce’s Subcommittee on Commerce, Manufacturing, and Trade and the Subcommittee on Communications and Technology held a hearing on “Understanding the Role of Connected Devices in Recent Cyber Attacks.”  The witnesses were Dale Drew of Level 3 Communications, Kevin Fu of Virta Labs and the University of Michigan, and Bruce Schneier from the Berkman Klein Center at Harvard University.

The witnesses uniformly recommended that while the DDos attack in October was just on popular websites, and not critical infrastructure, attacks toward critical infrastructure, including public safety and hospital systems, are likely.  Each witness stressed the importance of addressing the vulnerabilities at the onset of developing technology, and urged greater oversight by lawmakers.

A video of this hearing can be found here.

Internet of Things (IoT) Security Takes Center Stage At FBI, DHS, NIST and Congress

New York Proposes First-in-the-Nation Cybersecurity Regulation for Financial Institutions

On September 13, 2016, the New York Department of Financial Services introduced a new rule that would require banks, insurance companies and other financial institutions regulated by the Department to establish and maintain a cybersecurity program designed to protect consumers and ensure the safety of New York’s financial services industry.  The proposed regulation is subject to a 45-day notice and public comment period, following the September 28, 2016 publication in the New York State register before final issuance.

Under the proposed rule, regulated financial institutions would be required to:

  • Establish a cybersecurity program;
  • Adopt a written cybersecurity policy;
  • Designate a Chief Information Security Officer responsible for implementing and overseeing the new cybersecurity program and policy; and
  • Have policies and procedures designed to ensure the security of information systems and nonpublic information accessible to third-parties.

Establishment of a Cybersecurity Program

According to the proposed rule, regulated financial institutions will need to establish a “cybersecurity program designed to ensure the confidentiality, integrity and availability of information systems that performs five core cybersecurity functions:”

  • Identification of cyber risks.
  • Implementation of policies and procedures to protect unauthorized access / use or other malicious acts.
  • Detection of cybersecurity events.
  • Responsiveness to identified cybersecurity events to mitigate any negative events.
  • Recovery from cybersecurity events and restoration of normal operations and services.

Additional requirements for each “cybersecurity program” include:

  • Annual penetration testing and vulnerability assessments.
  • Implementation and maintenance of an audit trail system to reconstruct transactions and log access privileges.
  • Limitations and periodic reviews of access privileges.
  • Written application security procedures, guidelines and standards that are reviewed and updated by the CISO at least annually.
  • Annual risk assessment of the confidentiality, integrity, and availability of information systems; adequacy of controls; and how identified risks will be mitigated or accepted.
  • Employment and training of cybersecurity personnel to stay abreast of changing threats and countermeasures.
  • Multi-factor authentication for individuals accessing internal systems who have privileged access or to support functions including remote access.
  • Timely destruction of nonpublic information that is no longer necessary except where required to be retained by law or regulation.
  • Monitoring of authorized users and cybersecurity awareness training for all personnel.
  • Encryption of all nonpublic information held or transmitted.
  • Written incident response plan to respond to, and recover from, any cybersecurity event.

Adoption of a Cybersecurity Policy

The new rule would require regulated financial institutions to adopt a written cybersecurity policy, setting forth “policies and procedures for the protection of their information systems and nonpublic information that addresses, at a minimum, the following:”

  • Information security.
  • Data governance and classification.
  • Access controls and identity management.
  • Business continuity and disaster recovery planning and resources.
  • Capacity and performance planning.
  • Systems operations and availability concerns.
  • Systems and network security.
  • Systems and network monitoring.
  • Systems and application development and quality assurance.
  • Physical security and environmental controls.
  • Customer data privacy.
  • Vendor and third-party service provider management.
  • Risk assessment.
  • Incident response.

Creation of Chief Information Security Officer

The new rule would require regulated financial institutions to designate a qualified individual to serve as a CISO, responsible for “overseeing and implementing the institution’s cybersecurity program and enforcing its cybersecurity policy.”  The new rule also would require the CISO to “report to the board, at least bi-annually to:”

  • Assess the confidentiality, integrity and availability of information systems.
  • Detail exceptions to cybersecurity policies and procedures.
  • Identify cyber risks.
  • Assess the effectiveness of the cybersecurity program.
  • Propose steps to remediate any inadequacies identified.
  • Include a summary of all material cybersecurity events that affected the regulated institution during the time period addressed by the report.

Third Party Protections

The new rule also would require regulated financial institutions to have policies and procedures designed to ensure the security of information systems and nonpublic information accessible to, or held by, third-parties, including the following:

  • Identification and risk assessment of third-parties with access to such information systems or such nonpublic information.
  • Minimum cybersecurity practices required to be met by such third-parties.
  • Due diligence processes used to evaluate the adequacy of cybersecurity practices of such third-parties.
  • Periodic assessment, at least annually, of third-parties and the continued adequacy of their cybersecurity practices.

A draft of the proposed rule is here.

New York Proposes First-in-the-Nation Cybersecurity Regulation for Financial Institutions