Scattered Data: What PIPEDA Means for Distributed Enterprises

By: Josh Mayfield | 11/1/2018

Sitting in the shadow of laws like GDPR and CCPA, Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA) has grown teeth and steps into full view today, November 1, 2018. While Canada boasts of several laws related to privacy, it is PIPEDA’s amendments that has companies all over the world scrambling to ensure data protection and that the proper channels are in place when there is unauthorized access to personal information.

Effective today, organizations across Canada (and the rest of the world) are required to provide notice of any data breach, but without the Draconian deadlines of other laws, such as GDPR’s 72-hour window. This doesn’t seem like anything to worry about, right? After all, most companies are relatively skilled at giving the mea culpa when consumer data is snatched, and given the uncapped window for reporting, many have argued that organizations will be free from any regulatory reckoning when personal information is compromised.

When you look closer, you start to realize how our definitions of ‘breach’ are woefully inadequate. We use words like ‘incident’, ‘event’, ‘compromise’ which are necessarily time bound and occur through a chronological sequence, gathering attributes along the way to land on the correct composite definition.

At a point in time, something with certain defining attributes has happened to deserve our terms. Often, we apply the term ‘breach’ once the defining attribute of exfiltration has happened: data has been taken out of systems by someone who was unauthorized to do so. But PIPEDA’s reporting requirements adds a subtle attribute to this commonly accepted definition which deserves our careful attention.

PIPEDA Breach Reporting

Any organization must report what happened to the authorities and affected persons when there has been a “breach of security safeguards,” which is defined in PIPEDA as: 

The loss of, unauthorized access to or unauthorized disclosure of personal information resulting from a breach of an organization’s security safeguards, or from a failure to establish those safeguards. 

A change in the lexicon describes just how to define what has happened and whether reporting is required. Let’s break down each aspect of PIPEDA’s definition and consider how protecting data in a distributed enterprise can hedge any business holding personal information of Canadian citizens.

Breach of Security Safeguards

PIPEDA is less concerned with whether information systems themselves have been breached (allowing unauthorized access) and more focused on the safeguards surrounding the computing environment which creates, stores, shares, transmits, or otherwise processes personal data.

Since the first part PIPEDA’s definition assumes the organization has security safeguards, you can look through the chronological sequence of events to determine if any safeguard was penetrated (breached). Whether data was lifted from the organization’s coffers is irrelevant.

Failure to Establish Safeguards

The backend of the PIPEDA definition of a breach pulls your attention to question whether safeguards were established.

In a distributed enterprise, users work with consumers’ personal information via laptops, tablets, smartphones, and other transient machines.

  • Are safeguards present at those devices? Are they functioning properly?
  • Is personal and other sensitive data currently residing on the device? What about cloud storage apps?
  • If personal data isn’t directly stored on the device, does the user have access to those data from the device?

When answering these questions, you’re able to determine if safeguards are effective within the computing environment so that you can apply the appropriate definition to breached safeguards. It is not enough to confirm (or disconfirm) safeguards have not been breached.

 Figure 1.1 Decision Tree to report a PIPEDA-defined breach

Loss and Unauthorized Access or Disclosure

Clearly, accessing personal or sensitive data is not the same as loss. Typically, data losses do not consist of a direct removal. They are characterized by the duplicate and staged records making their way out of your information systems. These actions are observable, making it relatively simple to figure out if “loss of personal information” has, in fact, occurred.

But PIPEDA doesn’t stop there. Just as the definition of ‘breach’ embraces both failures to establish safeguards and the defeat of established safeguards, you can see how losing personal information is joined by unauthorized access or disclosure.

Once the safeguards have been breached (or were missing altogether), you cannot conclude that a notification is unnecessary because no data was lost. You must also validate that when safeguards were defeated, an unauthorized party did not access the records behind the safeguards. Further still, you are obligated to demonstrate that personal information was not disclosed in any unauthorized manner.

What about distributed data?

This is where PIPEDA gets difficult. Organizations have intentionally removed data boundaries. Considering how employees, contractors, and partners are granted access to consumer data and are able to work with that data on local endpoints, it requires constant vigilance of every device to validate data residency and verify safeguards in thousands of enforcement points.

Data Residency

The first step to comply with PIPEDA is to pinpoint all the personal information distributed across endpoints. Typically, this is accomplished through lexicographical crawling and recursive indexing. Just as search engine web-crawlers comb through pages on the Internet, catalog tags, and ‘read’ what’s there, lexicographical crawling allows you to probe a population of endpoints and see the search results that identify personal information.

This is where the study of metadata comes in handy. Metadata, or data about data, will create a key-value pair where the key is the metadata referent (e.g. last name) with values being any data that is consistent with the typical markers of the metadata referent (e.g. Kennedy, Khrushchev). This makes the lexicographical crawling more efficient, because you can scan the population for the metadata associated with personal information.

The second technique is recursive indexing. Once you’ve received the metadata components and the values that were associated with the metadata, you have the opportunity to update the pinpointing systems with the values, without needing the original metadata referent: “Continue to look for strings of characters that look like these results [the last names] and update our residency confirmation, even if there isn’t a column header or field name for the value [no last name label].”

Once these two techniques are in place, you’re able to cover about 80-90% of the possible identifiable personal information that could fall into the PIPEDA regulations.

Verify Safeguards

Though you may never confirm 100% of data residency, the additive effect of verifying safeguards clinches the deal for PIPEDA compliance and tells you when/if you need to report a breach. Now that you have knowledge of where data lives, you can discover if the data’s home has required safeguards including things like encryption, access controls, anti-malware, and least privilege permissions. To verify protective technology, ask three specific questions:

  1. Is the protection installed?
  2. Is the protection active?
  3. Is the protection updated?

Most organizations rely on the technique of digital tethering to keep a grip on devices to interrogate the entire endpoint population and validate each of these questions. Digital tethering comes from within the boot process where a firmware module is directed to ask and receive answers to the three questions. The tether cannot be interrupted, because if the machine is on, so too is the firmware module. The firmware module is the best method we know of because it can be programmed to be an idiot savant: it can’t do anything well…except one really important thing. It cannot communicate with other programs, run installations, or even communicate with anything but the paired monitoring console.

We humans have a natural inclination to fear what we do not understand. PIPEDA provides us with a specific example of how countless security professionals can be led to anxiety and dread with a looming stack of regulations on fast approach. To be sure, there are penalties and costs for non-compliance but by following these deliberate steps, you can equip yourself in the same way you have in other regulatory battles and achieve success.

If you’re interested in learning more about how to comply with PIPEDA, check out our Risk & Compliance resources. We can also run a compliance assessment for your organization, which provides you with insight into areas where you may still have blind spots within your data protection architecture.

Financial Services