Phoenix pay system compromised Public Servants’ privacy

Complaint under the Privacy Act (the Act)

Summary

1. The Office of the Privacy Commissioner (OPC) received three complaints related to the Phoenix Pay System (Phoenix). The complainants alleged that Public Services and Procurement Canada (PSPC) improperly disclosed the personal information of all federal public service employees (employees^{Footnote 1}) to up to 70,000 employees through Phoenix. According to the complainants, PSPC was aware of a potential privacy issue as early as January 18, 2016, well before the launch of Phoenix, but did not address the situation.
2. In its initial representations to our Office, PSPC submitted that a number of breaches occurred. It reported that the breaches involved a limited number of departments, only involved employee names and Personal Record Identifier (PRI) numbers, and the information was only available to a limited number of federal public servants. Furthermore, PSPC submitted that in its view, the risk to affected individuals was “very low”. Finally, PSPC informed us that in at least 2 cases, the issues that led to the breaches had not been resolved.
3. Our investigation revealed that the breaches and vulnerabilities within the Phoenix system went beyond what PSPC initially reported to our Office. We established that at least 11 breaches occurred and the personal information at issue included employee names, PRI, and salary information. Most of the vulnerabilities were government-wide, meaning the information of all employees in the Phoenix system at the time of each breach was at risk. We established that for some breaches, information could be changed and transactions could be conducted. Furthermore, we determined that there may be persistent vulnerabilities that could lead to future breaches.
4. Our investigation determined that the breaches were the result of a combination of inadequate testing, coding errors, and insufficient monitors and controls of the Phoenix system. Each of these issues is addressed below.
5. In light of the breaches revealed by our investigation, we determined that the complaints are well-founded. The reasons for our findings are outlined below.
6. In addition to our findings, we made the following recommendations to assist PSPC in resolving the issues that contributed to the breaches.
   • Recommendation 1: Audit Accesses to the System
   • Recommendation 2: Improve Testing Procedures
   • Recommendation 3: Improve the Management of Security Risks
   • Recommendation 4: Mitigate the Risk of Real Harm by Addressing Potential Call Centre Vulnerability
   • Recommendation 5: Inform Affected Individuals
   • Recommendation 6: Complete Review of Pages with Row-level Security
7. On May 15, 2017, PSPC responded to our recommendations. We ask that PSPC follow-up with our Office in 6 months to report on its progress in implementing our recommendations.
8. The first part of this Report focuses on our investigation and details the facts it established. It then outlines our analysis of key facts that we relied on to support our findings. The Report concludes with our recommendations and PSPC’s subsequent response.^{Footnote 2}

Scope of the Investigation and Methodology

9. Our investigation concerned both the disclosure of personal information held within Phoenix and the vulnerabilities that led to these disclosures. For the purposes of this Report of Findings, we define breaches as incidents where there is sufficient evidence to determine that an unauthorized disclosure of personal information occurred. Furthermore, a disclosure need not be to parties outside the public service. An unauthorized disclosure includes access beyond those that have a “need to know” the personal information in question. Vulnerability refers to specific conditions, such as a programming error, that could lead to a breach. Our investigation uncovered evidence of both vulnerabilities and breaches.
10. When we requested representations from PSPC, its officials were unable to provide us with complete information. Therefore, in order to establish the facts outlined below, we had to review numerous documents, conduct several interviews with PSPC officials, and seek clarification on multiple occasions regarding what appeared to be inconsistent submissions and information.
11. We developed a statement of facts which we had validated by PSPC. Based on these facts we provided PSPC with our findings with recommendations. On May 15, 2017 PSPC responded to our recommendations.

Background

12. PSPC is responsible for administering the pay for over 100 departments, agencies, and Crown Corporations, which collectively employ approximately 290,000 public servants. In 2009, the Government of Canada approved PSPC’s Transformation of Pay Administration Initiative, which was intended to update the pay system that was in place at the time.
13. The Transformation of Pay Administration Initiative has two key components, namely Pay Consolidation and Pay Modernization. Pay Consolidation was a project to centralize pay services delivered to departments and agencies. The intent of the Pay Consolidation project is to eventually transition the pay services of all departments to a centralized Pay Centre.
14. According to PSPC, the consolidation of pay was a fundamental concept underlying the modernization of pay. The Pay Modernization Project was intended to replace the government’s pay system with a new system called “Phoenix” which is based on commercial, off-the-shelf software. Phoenix was designed to increase automation of some administrative processes, allow a degree of self-service for users, and integrate with the government’s Human Resources Management System.^{Footnote 3}
15. During our interviews, PSPC officials explained that Phoenix is based on the PeopleSoft^{Footnote 4} application architecture. It is structured as a suite of modules that are composed of pages. Most of Phoenix is comprised of off-the-shelf components and features of PeopleSoft; however, some aspects have been customized by PSPC to meet the government’s specific requirements.
16. Phoenix was implemented in 2016 in 2 phases. During the first phase, 34 organizations were brought online on February 24, 2016. PSPC submitted that the personal information of approximately 120,000 employees was migrated to Phoenix between February and April 2016. During the second phase, the remaining organizations were brought online on April 21, 2016. At this time the personal information of approximately 170,000 additional employees was migrated to Phoenix.
17. Phoenix has both institutional and individual users. The individual user roles at issue in this investigation are the Compensation Advisor (CA), the Financial Officer (FO), the manager^{Footnote 5}, and the employee. Access to personal information held within Phoenix is determined by the function assigned to each role. For example, managers are intended to be provided access to the information of employees under their supervision.^{Footnote 6} CAs who work within an organization are intended to be given access to the information of employees within their own organization.
18. PSPC was not able to provide the exact number of CAs, FOs, and managers using Phoenix at the time of each breach. However, it did provide us with a representative snapshot. In January 2017 there were 1,679 CAs, 558 FOs, and 21,419 managers using Phoenix.
19. There are three types of organizations that use Phoenix:
    • Pay Centre organizations are provided pay services directly from the Public Service Pay Centre in Miramichi, New-Brunswick. These organizations do not have internal CAs.
    • Web Services Organizations use their own Human Resources management systems that are integrated with Phoenix. These organizations have their own CAs to administer pay actions within Phoenix.
    • Direct access organizations have their own CAs that process pay transactions directly into Phoenix, independently from the Public Service Pay Centre.
20. Many of the incidents we investigated involved individuals in assigned roles being given access to personal information that was beyond the scope of their function.

General Facts Concerning the Breaches ^{Footnote 7}

21. Interviews held with PSPC officials established that Phoenix has had privacy vulnerabilities since the day it launched. Some of these vulnerabilities were identified before the February 24, 2016 launch. PSPC took measures to address the vulnerabilities before Phoenix launched but these measures did not resolve the known vulnerabilities.
22. The vulnerabilities in Phoenix led to privacy breaches, meaning users in specific roles were given unauthorized access to personal information, and in many cases (often unintentionally) viewed the personal information of employees outside of their organizations. In general, the scope of the vulnerabilities was government-wide, meaning the information of all employees in Phoenix was available to all individuals assigned to the role at issue. However, the scope of the breaches was limited to that which specific individuals actually accessed. Furthermore, based on our discussions with PSPC officials, there may be persistent privacy vulnerabilities^{Footnote 8} within Phoenix that could lead to additional breaches in the future.
23. Three general categories of issues have contributed to vulnerabilities which, in turn, have led to breaches.

Category 1: Breaches Related to Row-Level Security

24. An important feature for controlling the access to data in PeopleSoft is called “row-level security”^{Footnote 9}. This feature allows the system operator to ensure that not only is access provided based on someone’s role (e.g., employee, manager, CA) but also based on their organization (e.g., a CA only sees employees in his or her own organization).
25. The problems encountered in this category of breach incidents relate to a failure to properly implement row-level security in some pages that make up Phoenix. Specifically, for some pages used by CAs, the row-level security feature was not enabled. This meant that searches for employees using these pages produced results that were not restricted to the appropriate organization(s).
26. A fix was developed to enable the row-level security feature for these pages. However, this has only been done for pages that have been reported by CAs in organizations, and the vulnerability may still exist for other pages. According to PSPC, there remain approximately 1,676 pages with potential vulnerabilities.
27. We found 6 breaches related to row-level security.

Category 2: Breaches Related to Coding

28. Custom code (PeopleCode^{Footnote 10}) was added to pages in a module used by managers (the Time and Labour Module^{Footnote 11}) to support requirements specific to the Canadian government. There were problems with this custom code such that measures taken to restrict the access to data based on the managers’ organization were not always applied. When a certain sequence of actions was taken by the managers, the custom code was bypassed and a search for employees returned all employees in the government (in groups of 300) instead of only the employees in the manager’s organization.
29. A fix was developed to modify the custom code so that the security feature was always invoked. Prior to this change, a quick fix was attempted that removed a feature to save search parameters prior to a search for employees, but this quick fix did not cover all pages that the managers used (i.e., the Worklist page).
30. We found 3 breaches related to coding.

Category 3: Breaches Related to User Input Errors

31. The third category of breach relates to errors made by Phoenix users. For example, in one instance, an employee who was a system administrator with special access rights made an error that allowed all CAs in the government to have unrestricted access to a page within Phoenix. From this page, a CA could view and modify the pay information of any employee in Phoenix and could carry out some administrative actions. In another instance, an employee was able to view the personal information of another employee when viewing her pay stub through Phoenix. In both instances, user error seems to have contributed to the breaches. PSPC addressed these errors on a case-specific basis.
32. We found 2 breaches related to user input errors.

PSPC’s Audit and Review

33. Currently, PSPC does not monitor or audit who accesses personal information used by Phoenix. According to PSPC officials, enabling such a feature would have a substantial impact on the performance of Phoenix. This means that PSPC relies on users to report breaches and vulnerabilities that involve unauthorized access to personal information used by Phoenix. PSPC submitted that the ability to audit access to personal information “does not exist for a system with similar number of users across the same number of organizations.”
34. Although PSPC does not audit access to information (viewing), it submitted that it has the ability to audit transactions in Phoenix. This said, it did not provide evidence to demonstrate that it conducts regular audits of Phoenix transactions. Rather, according to the documentation provided by PSPC, “because execution of PeopleSoft audit capabilities can have an impact on system performance, the Phoenix design team has limited the use of audits to very specific data items.”
35. PSPC submitted that after it became aware of the abovementioned breaches and vulnerabilities, it conducted transaction audits in cases where users had the ability to add, modify, or delete information.
36. On several occasions PSPC assured our Office that according to its audits, no inappropriate transactions associated with the breaches or vulnerabilities had taken place; however, upon reviewing the audit logs PSPC provided us, we noted what appeared to be an inappropriate transaction. When questioned about this discrepancy, PSPC confirmed that an inappropriate transaction had taken place related to IR 03685524 (see appendix). PSPC has since submitted that no other inappropriate transaction associated with the breaches or vulnerabilities has taken place.
37. PSPC informed us that it is in the process of conducting a systematic review of pages used by CAs to determine if any vulnerabilities remain. PSPC committed to completing the review by June 30, 2017.

PSPC’s Notification of Affected Individuals

38. PSPC submitted that because of the large number of individuals affected by the breaches and vulnerabilities, it chose to notify employees via a message sent by PSPC’s Deputy Minister on July 21, 2016. The message was also posted online.
39. Concerning the breaches that occurred between February and April 2016, the online message stated:

    “Several managers from four departments were able to access employee names and PRIs from other federal departments. These breaches were resolved.”

40. On November 1, 2016, the online message was updated to include the following notification:

    “On July 26, the Department was made aware that two employees from two departments were able to access other employees’ personal information and could initiate pay actions pending approval. These issues have been addressed.”

41. In its representations to our Office, PSPC submitted that “although notification of affected individuals is considered a best practice by [Treasury Board Secretariat] policies, it is not mandatory.” In reference to its decision to send out the abovementioned notifications, PSPC explained that it determined that “the potential negative impact [of the breaches and vulnerabilities] was… very low.” In coming to this decision to notify employees in the way it did, PSPC considered “the benefits of notification against the potential harm of unnecessarily alarming the public.”

Applicable Sections of the Privacy Act

42. In making our determination, we considered Sections 3 and 8 of the Privacy Act (the Act).
43. Section 3 of the Act defines personal information as information about an identifiable individual that is recorded in any form including, without restricting the generality of the foregoing: information relating to race, national or ethnic origin, colour, religion, age, marital status, education, medical, criminal or employment history, financial transactions, identifying numbers, fingerprints, blood type, personal opinions, etc.
44. the Act states that personal information can only be disclosed with an individual's consent – subsection 8(1) – or in accordance with one of the categories of permitted disclosures outlined in subsection 8(2) of the Act.

Analysis

Was personal information at issue in the reported incidents?

45. Our investigation determined that the information at issue in the reported incidents included: name, PRI, salary information, and in at least one instance, date of birth and home address of federal public service employees. This constitutes personal information as defined by the Act.

Was the personal information at issue improperly disclosed?

46. We determined that in each of the breach incidents, some personal information was disclosed. The disclosures were to federal public service employees. None of these disclosures was in accordance with any of the provisions outlined in subsection 8(2).

What was the scope of the improper disclosure?

47. Because PSPC does not have the capability to monitor the viewing of personal information held in Phoenix, it could not provide us with the exact number of instances of unauthorized access to personal information. However, we were able to determine that for many of the vulnerabilities, the personal information of all employees in the Phoenix system at the time was at risk.

Was the personal information that was improperly disclosed misused?

48. We found no evidence that the personal information disclosed in the reported incidents was misused. However, given that we were unable to determine the scope of the disclosures, we cannot assert with any certainty that no personal information was misused.

Was PSPC aware of potential privacy issues with Phoenix before the launch?

49. The complainant alleged that PSPC was aware that Phoenix had privacy vulnerabilities before the system was launched. Our investigation confirmed that PSPC was aware of a privacy vulnerability that allowed managers to view the name and PRI of employees outside the scope of their function before Phoenix launched (IR 03591514 see appendix). The scope of this vulnerability was system-wide, meaning all managers who had access to Phoenix at that time could see the personal information of employees within their organization. Although PSPC made efforts to address this issue it was not resolved at the time Phoenix was launched.
50. With respect to the other vulnerabilities outlined above, we did not find evidence that PSPC was aware of them before Phoenix was launched. This said, we note that PSPC’s testing processes did not identify these vulnerabilities before they were reported by users.

What kind of harm could result from the unauthorized disclosure of the personal information at issue?

51. Although we found no evidence that the personal information at issue was disclosed to individuals outside of the government, we have seen cases of employee snooping in other departments as well as PSPC. For example, in April of 2017, PSPC reported another breach to our Office that involved a contract employee who used access to Phoenix to snoop on family members who were employees in the federal public service.^{Footnote 12} According to PSPC, this incident was not related to the vulnerabilities we identified in this investigation. However, it reported that sensitive personal information of the affected individuals was disclosed to at least 1 individual outside the government. Therefore, it is clear that the improper disclosure of personal information puts affected individuals at risk of harm that could result from the improper use of their personal information by government employees.
52. Generally speaking, identity theft and financial fraud^{Footnote 13} are potential harms that can result from the unauthorized disclosure of personal information. For example, name and PRI can be combined with other information collected from publically available information sources^{Footnote 14} and/or information collected through social engineering techniques^{Footnote 15} to impersonate another individual to make changes to financial accounts or gain fraudulent access to funds.^{Footnote 16}
53. In addition to public information sources and social engineering, personal information can be gathered from protected information sources that require special access. For example, some CAs have access to a government database called the Central Index. A CA can use an employee’s name and PRI to access personal information on the Central Index, including Social Insurance Number, date of birth, and home address. In normal circumstances, CAs would only have the name and PRI of specific employees. However, if CAs had access to the name and PRI of all government employees then they could access the personal information of any employee in the Central Index.
54. Our investigation did not uncover evidence to suggest that the personal information of government employees was disclosed to individuals outside the Government of Canada as a result of the breach incidents. Furthermore, we did not find evidence of identity theft or fraud. However, we did find evidence that at least one inappropriate transaction occurred. Therefore, in our view, the breaches present a potential risk of real harm.
55. An assessment of risk takes into account both the seriousness of the potential harm and the probability that the harm will occur. In order to consider the probability that this harm will result from the vulnerabilities in Phoenix, the scale of the breaches must be known. However, PSPC was unable to provide us with the number of individuals that inappropriately accessed the personal information at issue. Therefore, we cannot comment on the probability that specific harm will result from the Phoenix breaches.
56. Section 3 of the Act defines personal information as information about an identifiable individual that is recorded in any form including, without restricting the generality of the foregoing: information relating to race, national or ethnic origin, colour, religion, age, marital status, education, medical, criminal or employment history, financial transactions, identifying numbers, fingerprints, blood type, personal opinions, etc.

Has PSPC resolved all of the vulnerabilities within Phoenix?

57. According to PSPC, it has resolved the vulnerabilities related to custom coding (Category 2). It submitted that it has reviewed each page that contains custom coding in order to ensure that no vulnerabilities remain. To date, no further breaches related to custom coding have been reported since PSPC resolved the issue.
58. PSPC submitted that it responds to vulnerabilities related to user input errors (Category 3) on a case-by-case basis. However, we note that PSPC relied on other departments to identify and report the breach incidents. This suggests that although PSPC has resolved theses specific breaches, it lacks monitors and controls that would allow it to identify vulnerabilities related to user input errors or to recognize breaches related to such vulnerabilities if they were to occur.
59. Vulnerabilities related to row-level security remain a concern (Category 1). This concern is based on the number of pages that remain at issue^{Footnote 17} and PSPC’s inability to proactively identify vulnerabilities. PSPC has committed to reviewing each page that uses row-level security by June 30, 2017. Until that review is complete it remains possible that additional vulnerabilities persist.

Did PSPC provide individuals with timely information regarding the breaches and vulnerabilities?

60. PSPC provided 2 public notifications regarding the breaches. The first was sent on July 21, 2016, and referenced only IR 03591514 (see appendix). None of the breaches involving CAs or the ongoing vulnerabilities related to row-level security were mentioned at this time. Furthermore, we note that the notification might have given the impression that the vulnerability at issue was limited to 4 departments. This was not the case. The scope of the vulnerability was system-wide.
61. On November 1, 2016, PSPC notified employees that 2 employees were able to access personal information and could initiate pay actions pending approval. This notification referenced only IR 03645195 and IR 3663251 (see appendix). As with the previous notification, PSPC used language that might give the impression that the vulnerability involved only 2 employees in 2 departments when in fact, the vulnerability was system-wide, and at the time of the notification, ongoing.
62. When explaining its decision to notify employees in the way that it did, PSPC referenced the Treasury Board Secretariat Guidelines for Privacy Breaches (the Breach Guidelines). Section 2 of the Breach Guidelines states the following:

    “…it is strongly recommended that institutions notify all affected individuals whose personal information has been or may have been compromised through theft, loss or unauthorized disclosure, especially if the breach:

    • Involves sensitive personal data such as financial or medical information, or personal identifiers such as the Social Insurance Number;
    • Can result in identity theft or some other related fraud; or
    • Can otherwise cause harm or embarrassment detrimental to the individual's career, reputation, financial position, safety, health or well-being.

    Notification should occur as soon as possible following the breach to allow individuals to take actions to protect themselves against, or mitigate the damage from, identity theft or other possible harm” (emphasis added).^{Footnote 18}

63. In its representations, PSPC rightly stated that notification of individuals is a “best practice”, or in the language of the Breach Guidelines, “strongly recommended”. Nevertheless, we note that this best practice is in place, in part, to allow individuals to take actions to protect themselves against the potential harm that could result from a breach.
64. In our view, PSPC did not provide employees with enough timely information to allow them to properly assess the risk and take actions they deemed necessary to protect themselves against possible harm.

Finding

65. In light of the above, the complaints are well-founded.

Recommendations

66. On May 1, 2017, we provided our Report of Findings with recommendations to PSPC. We requested that it inform us whether it intended to accept our recommendations.
67. On May 15, 2017, PSPC informed us that it agreed to all of our recommendations. However, when detailing how it would respond to the recommendations, not all of PSPC’s proposed actions appeared consistent with its stated intention.
68. Our recommendations, PSPC’s response, and our subsequent comments are outlined below.^{Footnote 19}
69. We ask that PSPC follow-up with our Office in 6 months to report on its progress in implementing our recommendations.

Recommendation 1: Audit Accesses to the System

70. Privacy is a fundamental value to Canadians and is an essential element in maintaining public trust in government. We remind PSPC that it needs to continually be aware of the personal information under its control and ensure that access to this information is limited to those who have a legitimate need to know. Monitoring and auditing access to personal information is one way to fulfill this responsibility.
71. Our investigation determined that PSPC does not audit access to personal information held in Phoenix.
72. PSPC conducts audits on transactions made in Phoenix but only monitors these kinds of audits on a limited ad hoc basis.
73. The Treasury Board Secretariat (TBS) Directive on Privacy Practices (the Directive) provides guidance in this area. Section 6.2.21 of the Directive requires departments to:

    [adopt] appropriate measures to ensure that access to, as well as use and disclosure of, personal information are monitored and documented in order to address the timely identification of inappropriate or unauthorized access to, or handling of, personal information (emphasis added).^{Footnote 20}

    Furthermore, section 17 of the Directive requires departments to:

    include a security audit log function in all IT systems… [and] …incorporate automated, real-time, incident tools in high risk systems.^{Footnote 21}

    Given the sensitivity of the personal information held in Phoenix and the potential harm that could result from the misuse of this information, we recommend that PSPC develop and implement controls to monitor and document access to personal information held in Phoenix.
74. With respect to the issue of auditing transactions, PSPS responded to our recommendation by stating that it is introducing “systemic monitoring of Phoenix audit tables, which will allow proactive identification of situations where users have improperly changed information in the system.” PSPC has also committed to developing queries to allow departments to monitor compensation advisor activities by June 30, 2017.
75. PSPC also committed to introducing a more robust system for monitoring the Actions of managers, Human Resources Analysts, and section 33 authorizers, by March 31, 2018.
76. With respect to the issue of monitoring access to personal information, PSPC stated that it “has yet been unable to identify a practical solution to monitor pages viewed by users.” However, following our request for clarification, PSPC indicated that it is committed to working toward finding a practical solution and is currently investigating the monitoring capability used by the Canada Revenue Agency as a possible option. We will continue to engage with PSPC on the issue of monitoring access to personal information until it finds a practical solution.

Recommendation 2: Improve Testing Procedures

77. Phoenix is required to adhere to specific requirements in order to protect the personal information it holds. System testing is an essential process for evaluating the degree to which Phoenix is fulfilling these requirements. Our investigation revealed that PSPC’s testing procedures for Phoenix were insufficient to evaluate compliance with privacy requirements. This led to situations where PSPC officials were forced to rely on reporting by institutions to identify privacy vulnerabilities. This suggests a weakness in the testing procedures for proposed system solutions.
78. Once vulnerabilities were reported PSPC was not always able to ensure that the Actions it took would actually address the vulnerability. For example, when a reported problem was fixed PSPC did not look for other pages or code that might have the same problem. This led to situations where similar vulnerabilities kept reoccurring.
79. Furthermore, we observed that the main method for handling security incidents and preparing responses was an email chain. In our view, this is not a good practice for ensuring effective security.
80. In light of the issues above, we recommend that PSPC develop more robust testing and response procedures to ensure it can proactively address privacy vulnerabilities, more effectively test proposed solutions to known vulnerabilities within Phoenix, and improve its responses to security incidents.
81. In its response, PSPC indicated that it had conducted a review of its change management process for Phoenix and had provided mandatory training for Phoenix team members. Furthermore, PSPC committed to reviewing its process for responding to security incidents.
82. In our view, PSPC has demonstrated that it recognizes the issue and has taken measures to implement Recommendation 2.

Recommendation 3: Improve the Management of Security Risks

83. The TBS Operational Security Standard: Management of Information Technology Security (MITS) requires that departments continuously manage security risks to information and IT assets throughout the life cycle of their programs and services. Security risk management activities may include conducting a Threat and Risk Assessment (TRA), audits, a Business Impact Analysis, and a Privacy Impact Assessment (PIA), among other assessments. Given the security risks to personal information uncovered by our investigation, we recommend that PSPC conduct necessary assessments to identify potential risks and vulnerabilities in Phoenix.
84. PSPC has agreed to complete a PIA and TRA by April 2018.
85. The absence of a completed TRA and PIA creates significant privacy risks. Given this, we would expect that these assessments would have already been completed or moving forward, with greater urgency than the timeline proposed by PSPC.

Recommendation 4: Mitigate the Risk of Real Harm by Addressing Potential Call Centre Vulnerability

86. The privacy vulnerabilities in Phoenix increase the possibility that personal information held within the system will be misused. As noted above, social engineering is one method for using information disclosed by breaches to gather additional personal information and possibly manipulate salary information. This makes employees who work in the Public Service Pay Centre and the Government of Canada Pension Centre targets for social engineering tactics. For example, an individual could use information gained from a breach in conjunction with information gained from open sources to pose as an employee when contacting the Pay Centre or Pension Centre and change account information (such as where funds are deposited).
87. In light of the risk posed by social engineering, we recommend that PSPC take measures to mitigate the increased vulnerability of information used by employees in the Public Service Pay Centre and the Government of Canada Pension Centre.
88. In its response, PSPC stated that “the Call Centre is acutely aware of the risks identified.” However, PSPC has not demonstrated that it has taken any special measures to make employees in the Public Service Pay Centre and the Government of Canada Pension Centre aware of the increased risks presented by the vulnerabilities identified by our investigation. Therefore, in our view, PSPC has not taken sufficient measures to implement Recommendation 4.

Recommendation 5: Inform Affected Individuals

89. Those affected by privacy breaches and vulnerabilities must be aware of increased risks to their information if they are to take appropriate measures to protect themselves from potential harms such as identity theft and financial fraud. In our view, PSPC did not provide employees with enough information to assess the risk and to take measures they deemed appropriate. Therefore, we recommend that PSPC review its breach notification practices to ensure that in the future, affected individuals are sufficiently informed to take appropriate measures to protect themselves. Furthermore, we recommend that PSPC provides notification of the extent of the Phoenix breaches and vulnerabilities.
90. In its response, PSPC stated that it will post “additional details about the protection of personal information in Phoenix” on its website. However, it did not commit to notifying affected individuals of the extent of the Phoenix breaches and vulnerabilities. This is troubling given that we noted a discrepancy between what PSPC communicated to affected employees and what PSPC came to know about the Phoenix breaches and vulnerabilities. Therefore, in our view, PSPC has not demonstrated that it is willing to implement Recommendation 5.

Recommendation 6: Complete Review of Pages with Row-level Security

91. Category 1 breaches and vulnerabilities were related to row-level security on specific pages in Phoenix. According PSPC, to ensure that no vulnerabilities related to row-level security remain it must review each page that uses this feature. PSPC committed to reviewing each page that uses row-level security by June 30, 2017. We ask that PSPC fulfill this commitment and report back to our Office when it is complete.
92. PSPC has committed to completing a review of all pages with row-level security by June 30, 2017.

Appendix 1 – Breach Details

Description of Specific Incidents

The Phoenix Security Management Team is responsible for responding to reports of security vulnerabilities and breaches. These include the privacy vulnerabilities and breaches that are being investigated by our Office.

Our investigation uncovered 11 breaches involving the unauthorized disclosure of personal information. These breaches were reported to the Phoenix Security Management Team by Phoenix users in other organizations. The reported breaches represent instances where there is sufficient evidence to determine that an unauthorized disclosure occurred. However, the issues that led to the breaches did not begin the day the breaches were uncovered. Based on discussions with PSPC officials, it is likely that many of the vulnerabilities had been ongoing from the time that Phoenix was launched until the related breach was addressed by the Phoenix Security Management Team.

Each reported breach is described below. They are identified by the Phoenix Security Management Team Incident Report (IR) number.

IR 03596311 – Category 1

On March 4, 2016, the Department of Canadian Heritage (PCH) reported to PSPC that four of its FOs were able to view and authorize On-Cycle payroll for several RCMP payroll accounts. This access was beyond the scope of what the FOs were authorized to view or approve. The information at issue included pay amount, name, and PRI. The PCH FOs also had the ability to approve action items (such as overtime, pay adjustments, acting pay) from the RCMP payroll accounts. PSPC submitted that the PCH FOs approved all the RCMP action items - 1556 in total - before realizing that the breach had occurred.

On March 5, 2016, the Security Management Team revoked access to Phoenix for all PCH FOs. According to PSPC, the issue was related to processes involved in transferring an employee.

On March 8, 2016, the Security Management Team resolved the issue. PSPC officials explained that the issue was difficult to identify and took some time to fix. Furthermore, they submitted that the vulnerability was likely present since the day Phoenix launched.

According to PSPC, it reviewed the approved transactions at issue to ensure that the RCMP employees received the appropriate pay.

IR 03611946 – Category 1

On April 11, 2016, the Canada Revenue Agency (CRA) reported that its CAs could view pay information for every employee in the government. The scope of this vulnerability was system-wide.^{Footnote 22} PSPC was not able to provide us with the exact date the vulnerability began. According to PSPC, the cause of the vulnerability was a failure to turn on row-level security for the View Paycheck page.

PSPC submitted that it did not remove access to the page in question because this would have meant that employees would not have been paid. On April 17, 2016, row-level security was added to the page and the issue was resolved.

IR 03645195 – Category 1

On June 21, 2016, Telefilm Canada informed PSPC that one of its CAs could view the name and PRI of employees outside her organization. The pages in question were Maintain Time Reporter Data and Create Time Reporter Data. The scope of this vulnerability was system-wide, meaning that all CAs could view the pay information of all employees. According to PSPC, the cause of the vulnerability was a failure to turn on row-level security for the pages in question.^{Footnote 23} PSPC submitted that the vulnerability was likely present since the day Phoenix launched.

On June 28, 2016, an Incident Report was created; however, the file was not assigned to an analyst until July 25, 2016.

On July 27, 2016, PSPC added row-security to the pages at issue in a testing environment. On August 2, 2016, the fix was implemented in Phoenix.

IR 3663251 – Category 1

On July 27, 2016, the Office of the Privacy Commissioner (OPC) reported that a CA could view the name, PRI, and some pay information of all employees in the government. The pages in question were Maintain Time Reporter and Employee Transition. The CA could also make changes that would result in an employee not getting paid a transition payment. The scope of this vulnerability was system-wide, meaning that all CAs could view and manipulate the information of all employees. According to PSPC, the cause of the vulnerability was a failure to turn on row-level security for the pages in question. PSPC submitted that the vulnerability was likely present since the day Phoenix launched. This issue was the same as that reported by Telefilm Canada (IR 03645195).

On July 27, 2016, PSPC added row-security to the pages at issue in a testing environment. On August 2, 2016, the fix was implemented in Phoenix.

IR 03647905 – Category 1

On July 5, 2016, a CA from the Office of the Commissioner for Federal Judicial Affairs (FJA) reported to PSPC that he could view the name and PRI of employees outside his organization when he used the search function on the Review Self-Serve Executive Performance Pay page. PSPC submitted that this vulnerability affected 149 employees from 9 organizations. The information at issue was name, PRI, and performance pay amount. According to PSPC, the vulnerability was present since May 13, 2016 (the day the page went live).

On July 5, 2016, access to the page in question was removed. To fix the issue PSPC added row-level security to the Review Self-Serve Executive Performance Pay page. On July 20, 2016, the solution was implemented in Phoenix.

IR 03695691 – Category 1

On October 31, 2016, PSPC was made aware of another page that was missing row-level security. The Office of the Superintendent of Financial Institution (OSFI) reported to PSPC that their CA was able to view the Employee Ranking by Job Code page for all government employees. The personal information viewable on this page included name, PRI, and salary. PSPC reported that the scope of the vulnerability was system-wide, meaning that all CAs could view the information of all employees, but that no change could be made to the information on the page in question. Furthermore, the vulnerability was likely present since the day Phoenix launched.

On November 1, 2016, PSPC removed access to the page.

In response to the issue PSPC permanently removed access to the page in question. PSPC submitted that on November 9, 2016, it determined that access to the page was not required.

IR 03591514 – Category 2

On February 24, 2016, the day the first phase of Phoenix was launched, a manager from the Public Service Commission (PSC) reported to PSPC that she could see the name and PRI of all employees inside her organization. The scope of this vulnerability was system-wide, meaning all managers in the 34 organizations on Phoenix had ability to see the name and PRI of any employee in their organization. According to PSPC, the managers should have only had access to their own employees.

PSPC explained that this was a known issue that had been flagged in draft versions of a Privacy Impact Assessment^{Footnote 24} (PIA) before Phoenix was launched. The issue was related to a function that allowed managers to select employees. To resolve this vulnerability a decision was made to remove the select employee function; however, PSPC submitted that a human error resulted in the failure to implement this solution when Phoenix went live.

PSPC turned off the employee selection function the same day it was informed of the breach.

IR 03602149 – Category 2

On March 15, 2016, PSPC was informed by the PSC that a manager was able to see the name and PRI of “all federal employees” when she searched for her employee. This issue was subsequently report by the Immigration and Refugee Board (IRB), the Canadian Grain Commission (CGC), and the Department of National Defence (DND).

The pages at issue were in the Time and Labour Module and are listed below:

• Manage Schedule
• Approve Time: Used to approve extra duty pay transactions
• Exceptions: Used by managers to view exceptions and error messages on employee accounts
• Timesheet: Used by the manager to enter time on behalf of employees
• Payable Time Detail: Used by managers to view the detail of the payable time generated. Managers can see the hours paid and who approved the payment.
• Payable Time Summary: This page provides a summary of the payable time generated by the time and labour functions.

On April 4, 2016, the Security Management Team revoked the access of 4 managers from the organizations that reported the breaches.

PSPC submitted that the issue was related to custom code it had placed on pages used by managers. On April 7, 2016, the Security Management Team implemented what they thought was a fix. Specifically, the team removed a feature that saved search parameters for the pages in question. However, this fix was ineffective and the same issue was reported again in July, 2016 (IR 03660361 – see below).

The scope of the vulnerability was system-wide, meaning all managers using Phoenix had access to the personal information of all employees whose institutions were using Phoenix at the time. These managers also had the ability to approve requests made in the Time and Labour Module. The information at issue was employee name and PRI. PSPC submitted that the vulnerability was likely present since the day Phoenix launched.

IR 03660361 – Category 2

This breach is related to IR 03602149.

On July 12, 2016, PSC reported to PSPC that its managers could still view “all employees in Phoenix”. PSPC submitted that, as with IR 03602149, the issue was with custom code that had been used on pages accessed by managers.

On July 25, 2016, the breach was assigned to an analyst.

On July 28, 2016, PSPC informed organizations that it had removed access to the page at issue (the Worklist page).

On August 1, 2016, PSPC implemented a fix to resolve the issue. Specifically, it modified the custom code to turn on a security feature that would limit a manager’s access to only his or her employees. Unlike the previous response – turning off a search function – this fix was intended to resolve the root cause of the issue.

The scope of the vulnerability was system-wide, meaning all managers had access to the personal information of all employees whose institutions were using Phoenix at the time of the breach. Managers also had the ability to approve requests made in the Time and Labour Module. The information at issue was the same as that which was at issue in IR 03602149. According to PSPC, the vulnerability was likely present since the day Phoenix launched.

PSPC submitted that it has since reviewed all pages that have the custom code in an attempt to ensure that the fix has been implemented where it is needed.

IR 03640919 – Category 3

On June 13, 2016, Immigration, Refugees and Citizenship Canada (IRCC) was informed by Justice Canada that a Justice Canada employee could see the personal information (name, PRI, date of birth, home address) of another employee when viewing her pay stub in the Phoenix Self Service module – View Pay Check. IRCC informed PSPC of the issue on June 14, 2016.

On June 21, 2016, PSPC corrected the information so that the Justice Canada employee could no longer see the information of the IRCC employee.

According to PSPC, the issue was caused when incorrect information from the departmental HR system was integrated with Phoenix. PSPC stated that the error did not originate with Phoenix.

PSPC submitted that it informed the individual affected that her information had been improperly disclosed. It also verified that no inappropriate financial transactions had been made.

IR 03685524 – Category 3

In late September, 2016, a PSPC employee who is a system administrator removed access to the By Payline Security page^{Footnote 25} for all CAs. This is a routine manual action that is done for every pay cycle. On September 29, 2016, the employee was supposed to restore access to the By Payline Security page. However, the employee gave all CAs access to the By Payline page, which is normally restricted to PSPC users. The result was that all CAs could access the information of all employees and make adjustments to their pay. On the same day, several CAs reported the issue. Once it was made aware of the error PSPC removed access to the By Payline page.

In response to the breach, PSPC reviewed all transactions that were carried out during the period that CAs had access to the By Payline page. The review determined that 1 inappropriate transaction occurred. Specifically, a CA responsible for administering pay services for the Canadian High Arctic Research Station (CHARS) had attempted to hire an employee; however, rather than hiring the employee to CHARS the employee was hired to PSPC. PSPC submitted that the error was caught the same day it occurred and the error was remedied.

PSPC submitted that it intends to automate the procedure for removing and restoring access to the By Payline Security page to avoid this error in the future.

Breach Summary Table

CategoryFootnote 26	Incident Report Number	User Role	Description	Scope	Organization that Reported Breach	Date Breach was Reported to PSPC	Date of Fix
1	03611946	CAFootnote 27	All CAs could view name, PRI, and pay information of all employees from the time Phoenix launched.	System-wideFootnote 28	CRA	April 11, 2016	April 17, 2016
	03596311	FOFootnote 29	4 FOs from PCH could view and approve action items on payroll accounts of some RCMP employees	1556 RCMP employees affected. Vulnerability was likely present since Phoenix launched.	PCH	March 4, 2016	March 15, 2016
	03645195	CA	All CAs could view name, PRI, and pay information of all employees.	System-wide	Telefilm Canada	June 21, 2016	August 2, 2016
	3663251	CA	All CAs could view name, PRI, and pay information of all employees and could make changes to employee accounts that would affect their pay.	System-wide	OPC	July 27, 2016	August 2, 2016
	03647905	CA	All CAs could view name, PRI, and performance pay amount of all employees in Phoenix receiving performance pay.	System-wide (149 employees across 9 organizations at the time)	FJA	July 5, 2016	July 20, 2016
	03696591	CA	All CAs could view and manipulate the personal information of all employees.	System-wide	OSFI	October 31, 2016	November 1, 2016
2	03591414	Manager	All managers could view the name and PRI of all employees within their organization.	System-wide	PCH	February 24, 2016	February 24, 2016
	03602149	Manager	All managers could view the name, PRI, and pay information of all employees within their organization.	System-wide	PSC, IRB, CGC, DND	March 15, 2016	August 1, 2016
	03660361	Manager	All managers could view the name and PRI of all employees within their organization.	System-wide	PSC	July 12, 2016	August 1, 2016
3	03640919	Employee	A Justice Canada employee could see the personal information (name, PRI, date of birth, home address) of another employee when viewing her pay stub in the Phoenix Self Service module – View Pay Check.	Personal information of 1 employee at issue	IRCC	June 13, 2016	June 21, 2016
	03685524	CA	All CAs had access to pay information of all employees and could make adjustments to their pay.	System-wide starting September 29, 2016	OSGG	September 30, 2016	September 30, 2016

Appendix 2 – PSPC Response to Recommendations^{Footnote 30}

Recommendations	Departmental Position	Management Response
1- Audit Access to Information Given the sensitivity of the personal information held in Phoenix and the potential harm that could result from the misuse of this information, we recommend that PSPC develop and implement controls to monitor and document access to personal information held in Phoenix. These control include a systematic review of logs as opposed to PSPC’s current practice of relying on ad hoc analysis.	Agree with comments	PSPC takes the safeguarding of employee personal information very seriously. The strategic vision for Pay Modernization includes the assumption that any compensation advisor in the PSPC Pay Centre, Satellite Offices and Pay Offices would have the ability to access and process cases for any employee in the departments and agencies they service at any time as it relates to the performance of their regular duties. Controls in place to safeguard personal information in this model include: All Compensation Advisors have training including topics to ensure that they understand privacy, appropriate access and consequences. Privileged user accounts is restricted in numbers, and requires user certification of their responsibilities prior to access, and departmental approval. PSPC will take additional steps to implement more robust processes related to user access management as well as audit of user activities. All Phoenix roles are being reviewed. Access to information is being streamlined for existing roles, and new roles are being created to suit specific purposes. While Phoenix roles will continue to evolve as we roll out new functionality, this review will be completed by June 30, 2017. As noted in your report, PSPC has as yet been unable to identify a practical solution to monitor pages viewed by users. However, PSPC has begun introduction of systemic monitoring of Phoenix audit tables, which will allow proactive identification of situations where users have improperly changed information in the system. Our first priority is to develop queries to allow departments to monitor compensation advisor activities; this is due to be released by June 30, 2017. PSPC is taking additional steps to ensure Compensation Advisors are acutely aware of their respective roles and responsibilities including protecting employee personal data and limiting the scope of their work to their respective portfolio. Steps to ensure consistent application of consequences to Compensation Advisors inappropriately accessing employee information are currently being confirmed. Next steps will be to introduce more robust monitoring of the Actions of s.34 managers, HR Analysts and s.33 authorizers. This was not the practice under the Regional Pay System and will require analysis and development of a new process involving PSPC and client departments. A preliminary design and implementation plan for the new process is expected to be in place by March 31, 2018. PSPC will engage a third party to review and advise on this design and its implementation plan action plan.
2- Improve Testing Procedures We recommend that PSPC develop more robust testing and response procedure to ensure it can proactively address privacy vulnerabilities, more effectively test proposed solutions to known vulnerabilities within Phoenix, and improve its response to security incidents.	Agree.	The implementation of Phoenix includes a stabilization period, which was originally anticipated to take one year, but is now expected to be completed in late 2017. The process to stabilize Phoenix has included a review of the end-to-end change management process for Phoenix. A new process was released in February 2017 and all Phoenix team members attended mandatory training. Any change to Phoenix now requires: An assessment of security/privacy considerations in analysis and design of solution; Specific consideration of security/privacy requirements in testing; Specific testing of security/privacy requirements identified; and Sign off by the security team prior to implementation. PSPC believes this new process meets OPC recommendations for testing and change management. PSPC will review the process for response to security incidents. This review will be completed by September 30, 2017.
3- Improve the Management of Security Risks Given the security risks to personal information uncovered by our investigation, we recommend that PSPC conduct necessary assessments to identify potential risks and vulnerabilities in Phoenix.	Agree, with comments.	PSPC has drafted a Privacy Impact Assessment for the Phoenix system, which is now being updated to reflect a broader scope of review (including system development practices) and to incorporate changes in operations since go live. The PIA is scheduled to be completed by April 2018. An updated Threat and Risk Assessment will be produced this fiscal year (FY 2017-18) as per the recommendations. This assessment is expected to be completed by April 2018.
4- Mitigate the Risk of Real Harm by Addressing Potential Call Centre Vulnerability In light of the risk posed by social engineering, we recommend that PSPC take measures to mitigate the increased vulnerability of information used by employees in the Public Service Pay Centre and the Government of Canada Pension Centre.	Agree, with comments	The Call Centre is acutely aware of the risks identified. All staff are trained and reminded of the importance to confirm the identity of the person (whether calling in or being called) through validation of key identifiers prior to discussing personal information. If at any time the Call Centre Staff are unsure of the identity of the person, the call is terminated and the person is directed to a more senior staff member for more stringent identification.
5- Inform Affected Individuals We recommend that PSPC review its breach notification practices to ensure that in the future, affected individuals are sufficiently informed to take appropriate measures to protect themselves. Furthermore, we recommend that PSPC provides notifications of the extent of the Phoenix breaches and vulnerabilities.	Agree.	PSPC’s privacy breach protocol, which was formally implemented in March 2016, provides guidance regarding notifications to individuals. The Protocol follows the Treasury Board Secretariat (TBS) guidance regarding breach notification. In light of the findings of this investigation, PSPC will review its Protocol with a view to ensure it is robust enough. In addition, we will supplement information already posted on our website with additional details about the protection of personal information in Phoenix.
6- Complete Review of Pages with Row-level Security PSPC committed to reviewing each page that uses row-level security by June 30, 2017. We ask that PSPC fulfill this commitment and report back to our Office when it is complete.		This review is currently on track to be completed by June 30, 2017. As requested, the results will be shared with the OPC.