[NORMAL] Audit of Access to the Corporate Management System. Audit Report

(1)

Audit of Access to the

Corporate Management System

Audit Report

Project Number: 19010/10-11

SP-1028-05-12E

(2)

Paper

ISBN: 978-1-100-20667-7 Cat. No.: HS28-202/2012E PDF

ISBN: 978-1-100-20668-4 Cat. No.: HS28-202/2012E-PDF

(3)

EXECUTIVE SUMMARY

The Corporate Management System (CMS) is a large-scale enterprise

management system, built, maintained and used by Human Resources and Skills Development Canada (HRSDC) to support its business environment. CMS is made up of eleven modules and more than 350 different screens. The main groupings are: Human Resources (HR), Control Data, Security, Administration – Operations and Maintenance Transaction Module (OMTM) and Finance.

CMS users fall into two groups. The first includes all 26,000 HRSDC employees, who can access CMS through the Paperless Office to input and view leave balances, and to enter related personal information. The second group includes approximately 6,0001_{active users who access the system through modules and} screens to process financial and HR transactions.

For this audit, we reviewed the user access management of the second group of users.

The information contained in CMS is a valuable departmental asset. User access management is more than just an Information Technology (IT) function as it affects every aspect of the Department by providing an overall and integrated approach to security, departmental business and practices. User access management and privileged user management ensure the right access to

information is available to authorized users and denied to unauthorized users as part of an effective, efficient Identity and Access Management (IAM) Lifecycle. The System is Evolving

HRSDC is preparing to replace CMS with a current, industry standard enterprise resource planning (ERP) system. This initiative is in the planning stage and will not immediately address current vulnerabilities raised by either the Office of the Auditor General (OAG), previous internal audit reports or other reviews

commissioned by the Department. This audit will help HRSDC gain further understanding of the current IAM vulnerabilities, and inform the next phase of ERP.

Audit Objective

The objective of the audit is to assess the adequacy of the management control framework as it is applied to safeguard access to HRSDC’s Corporate

Management System information assets.

(6)

More specifically, the audit will determine if:

CMS governance and oversight, as it applies to access, is adequate and effective in supporting its activities.

Controls are designed and applied consistently to safeguard access to information assets.

Risks related to access have been identified, assessed and mitigated. Summary of Key Findings

Overall, we found that there was insufficient infrastructure, standardized practices and procedures to provide adequate governance.

Governance is ad hoc and employees are managing intuitively.

The Department is granting access to CMS without adequately managing the system’s user access lifecycle based on the least-privilege principle and the need-to-know.

Protected

There is little to no oversight that exists to ensure managers are fulfilling their responsibilities as set out in Treasury Board Secretariat (TBS) and HRSDC policies and guidelines.

With regard to CMS the Department is not in compliance with TBS policies such as the Policy on Privacy Protection, the Government Security Policy and the Operational Security Standard: Management of Information Technology Security (MITS).

An effective risk management process is not in place to continuously manage security risks to CMS information assets.

Audit Conclusion

The audit concluded that the current CMS control framework and its related system of controls and risk management practices are not adequate in

safeguarding access to its information assets. Although weaknesses have been identified that require management attention, issues are considered to be

moderate as the access to CMS is limited to HRSDC’s internal network. It is also important to note that improvements should focus on the Identity and Access Management Lifecycle rather than on the system itself as CMS will soon be replaced by industry standard ERP system.

(7)

Summary of Recommendations

Innovation, Information and Technology Branch (IITB), in consultation with Chief Financial Officer Branch (CFOB) and Human Resources Services Branch (HRSB), should develop and implement a comprehensive IAM

strategy to address current weaknesses, to provide guidance and standardize access management practices.

CFOB and HRSB, in consultation with IITB, should develop and implement a centralized privileged user management (PUM) process, as an important element of the Department’s overall IAM strategy.

CFOB and HRSB, in consultation with IITB, should remind all managers and authorized requestors who are approving access to CMS of their roles, responsibilities and accountabilities associated with user access

management.

CFOB and HRSB, in consultation with IITB, should undertake the following activities to mitigate some of the risks identified during the audit:

- develop a process to manage temporary personal record identifiers (PRIs) and perform a review of the current (active) temporary PRIs;

- reuse the same usercode instead of creating a new one each time a request for access is granted;

- Protected

- determine who should have access to the system and communicate decisions to the appropriate parties; and

- request that managers review and update employee access based on the least-privilege principle and the need-to-know.

CFOB and HRSB should determine what level of CMS risk assessment is required to safeguard CMS as it continues to support the Department’s business environment over the next few years while ERP is being implemented.

Original signed by:

______________________________________________

Vincent DaLuz, CA, CIA Chief Audit Executive

(8)

Audit Team Members

Senior Director - Brigitte Marois, CGA, CMA Giuseppe Tartaglia, CGAP, CISA

Mary Lou Sauriol Sébastien Pilote Amanda Elliott

(9)

1.0 BACKGROUND

1.1 Context

The Audit of Access to CMS was included in the approved 2010-2011 Risk-Based Internal Audit Plan. It is important to note that this audit was underway before the announcement of Shared Services Canada.

CMS is a large-scale enterprise management system, built, maintained and used by HRSDC to support its business environment. CMS is made up of modules, the main groupings are: HR, Control Data, Security, Administration–OMTM and Finance.

CMS users fall into two groups: all 26,000 HRSDC employees can access CMS through Paperless Office to input and view leave balances, and to enter related personal information. Approximately 6,0002

active users access CMS through modules and screens to process financial and HR transactions.

For this audit, we reviewed the user access management of the second group of users.

User Access Management Defined

User access management is the process of managing who has access to what information over time. It is more than an IT function as this process affects every business practice throughout the Department. HRSDC currently manages

approximately 6,000 users with access rights and a variety of permissions to perform specific departmental activities within CMS.

User Access Management answers the following: Who are you?

What can you do? What did you do?

A user’s role changes over the course of employment, this may include:

promotion, demotion, changes in the business roles, moves to different branches and departure. Users can also accumulate access privileges over time and as such strong user access management practices are required to manage the entire lifecycle in order to safeguard information.

(10)

Personal information

Personal information includes any factual or subjective information, recorded or not, about an identifiable individual. This includes information in any form, such as:

• age, name, identification numbers, income, ethnic origin, or blood type;

• opinions, evaluations, comments, social status, or disciplinary actions; and

• employee files, credit records, loan records, medical records, existence of a dispute between a consumer and a merchant, intentions (for example, to acquire goods or services, or change jobs). Personal information does not include the name, title or business address or telephone number of an employee of an organization.

Privacy Act Section 3

The key success factor of user access management is involvement and

commitment from the appropriate stakeholders. Senior management, managers and employees are all responsible for the privacy and security of the

Department’s information assets.

The System is Evolving

The Department is preparing to replace CMS with industry standard technology endorsed by TBS (PeopleSoft to replace HR modules and SAP3_{to replace} finance modules). IITB is currently planning to deliver an IAM strategy as an automated service for over 120 applications including CMS.

These initiatives are in various stages of planning and will not immediately address current vulnerabilities raised by the OAG, previous internal audit reports and other reviews commissioned by the Department. Therefore, it is important that HRSDC gain an understanding as to the current deficiencies in order to course correct and to bring this knowledge into the next phase of these initiatives.

1.2 Risk Environment

When it comes to IT security, one of the weakest links4 is IAM.5_{Often the focus of user access management is to} quickly provide employees with the access they require to perform their duties. However, just as important is removing this access when it is no longer appropriate or necessary (based on the least-privilege principle6_{and the} need-to-know7

).

CMS data is subject to privacy and confidentiality

regulations. A lapse in security controls could constitute

high risk to the Department. The potential deficiencies centre on how the

3

The name SAP stands for Systems, Applications and Products in Data Processing.

4 _{“The Fundamentals of Identity and Access Management”}_,_{article published in the Internal}

Auditor Journal from the Institute of Internal Auditor, April 2008.

5

IAM is a comprehensive set of business processes and supporting infrastructure for creating and maintaining digital identities and providing efficient, secure and documented access to applications, email, printers and the organization's internal network.

6

The least-privilege principle: To provide the minimum level of access to a user in order to complete their business roles (giving a user only those powers which are absolutely essential to do his/her work).

7

The need-to-know: Takes the least-privilege principle one step further, by providing access to systems and information only where there is a need for the user to have such access at that time.

(11)

Protected

The potential impacts of unauthorized access include:

the Deputy Minister and Departmental Security Officer may be held accountable for policy non-compliance;

reputational damage may result from the loss of information confidentiality, integrity and availability;

the Department may not be able to adequately demonstrate that it has satisfactorily discharged its responsibilities regarding Stewardship, Information Management and Controls; and

inappropriate disclosure may result in legal penalties in the event of an offence.8

1.3 Audit Objective

The objective of the audit is to assess the adequacy of the management control framework as it is applied to safeguard access to HRSDC’s Corporate

Management System information assets. More specifically, the audit will determine if:

CMS governance and oversight, as it applies to access, is adequate and effective in supporting its activities.

Controls are designed and applied consistently to safeguard access to information assets.

Risks related to access have been identified, assessed and mitigated.

1.4 Scope

The audit assessed the internal control framework, business processes, and operational procedures to ensure that unauthorized access to CMS is prevented. This audit engagement focused on selected components within the IAM lifecycle process that apply strictly to the non-technological9 aspects of CMS user access management. Furthermore, the scope of the audit did not include access

privileges granted to processes and programs that are interfacing with CMS nor any forensic analysis of information breaches.

8

Department of Human Resources and Skills Development Act (2005, c. 34) PART 4 Protection of Personal Information

9

The focus is on the business processes of user access management and not the system currently in use (i.e. CMS).

(12)

1.5 Methodology

The audit team examined the CMS control framework, the related processes and guidance documents.

The audit team interviewed key departmental personnel at National

Headquarters (NHQ) and in selected regions (Moncton, Belleville and Montreal). The team also analysed computer generated reports from the Electronic

Document System (EDS) in order to review CMS access.

The audit team also researched and reviewed information from the web on IT governance, IAM, audits conducted by other federal departments and white papers from a variety of sources in order to provide best practices to the appropriate stakeholders.

(13)

2.0 AUDIT FINDINGS

2.1 Insufficient governance supporting CMS’ user access management

The audit team did not find that the Department had the infrastructures, standardized practices and procedures in place to effectively and efficiently manage user access in CMS.

Analysis

In assessing CMS Governance, we expected to find the following key elements: The HRSDC Control Framework for CMS is compliant with TBS policies and

directives.

User access management is included in the control framework and is aligned to ensure that management monitors progress and has in place a continuous improvement plan.

The roles, responsibilities and accountabilities are clearly defined, delegated and communicated.

The current control framework has not evolved to keep pace with the

continuously changing environment of the Department or with TBS Policies. Governance is ad hoc and employees are managing intuitively with the emphasis on granting access to the system rather than managing the entire user access lifecycle. CMS is being managed informally, without standardized processes and employees are creating their own user access procedures as they have not received guidance from NHQ. However, CFOB has since advised the audit team that they are currently working on initiatives to address these issues.

The only document provided to the audit team to describe CMS governance was a draft version of the CMS Control Framework, last updated in 2002. The

document was not approved or endorsed by the Department, nor were its contents appropriately communicated to stakeholders. In more than 30

interviews, only three individuals indicated they were aware of the framework. All three stated that the framework was outdated and not in use.

Furthermore, IITB has developed a Policy on IT Security Management that describes the overall roles and responsibilities of all employees in the

Department as it pertains to IT security. The majority of interviewees were also not aware of this policy.

(14)

Outdated and unsanctioned, the CMS Control Framework is not compliant with TBS policies such as the Policy on Government Security10_{and the Policy}

Framework for Information and Technology.11_{Both state that Deputy Heads are} responsible for ensuring that IT activities are effectively managed by having clearly defined governance, accountabilities, defined objectives that are aligned with departmental and government-wide policies and priorities. The policies also indicate that performance must be monitored, assessed and reported on to help ensure objectives are being met.

We could not locate a memorandum of understanding describing the roles and responsibilities of CFOB and HRSB in managing CMS. Moving forward—as the Department transitions from CMS to an ERP solution—it will be indispensable for business owners to establish and document their roles, responsibilities and accountabilities.

As CMS will eventually be decommissioned in favour of ERP technology

(PeopleSoft for HRSB, and SAP for CFOB), there is no value added in updating the current governance framework. However, it would be advisable that HRSB, CFOB and IITB develop a management control framework for the ERP solution. 2.2 Controls related to the user access management lifecycle are

not adequately applied

The Department is not adequately managing the CMS user access lifecycle based on the least-privilege principle and the need-to-know. Protected The audit found that accountability for user access management was placed on the

managers of employees requesting CMS access. The managers interviewed did not always understand the extent of their responsibility, nor did they have the tools to facilitate effective CMS user access management and as such

monitoring is limited.

Findings also show that the Department is not in compliance with TBS policies such as the Policy on Privacy Protection,12_{(under section 6.2 - ensuring that a} privacy and impact assessment is completed), the Policy on Government Security (under section 6.0 - ensuring that managers at all levels integrate security and identity management requirements into plans, programs, activities and services) and the Operational Security Standard: MITS (under section 16 - prevention: controls to protect the confidentiality, integrity and availability of information and IT assets, and section 17 - detection: monitoring of systems performance and security audit log functions must be established).

10

Policy on Government Security, Section 6.0.

11

Policy Framework for Information and Technology, Section 2.2.

12

(15)

While some user access controls are in place to mitigate risks related to granting access to CMS, there is no standardized, documented and approved user

access management process in place to provide only authorized individuals with access to the system based on business requirements.

Analysis

In assessing the controls for CMS user access management we expected to find processes and practices that securely manage the user access lifecycle based on the least-privilege principle and the need-to-know. These processes and practices should be found within the following areas:

Provisioning; Authentication; Authorization; Compliance; and De-provisioning.

Provisioning: creating and approving user accounts

The provisioning for CMS begins with a request from an employee’s manager asking that the employee be provided access to the system in order to perform their duties. IITB creates the usercode based on the manager’s manual

authentication of the new user’s identity and on the assertion that the employee has a PRI and is security cleared.

The user access provisioning process for CMS is a two-tier process which demonstrates good segregation of duties. IITB is responsible for creating usercodes before CFOB or HRSB can approve and grant access to the

requested CMS modules or screens. However, the process is not standardized as there are differences in how NHQ and the regions request user account creation and in how new usercodes are provided. Protected the least-privilege principle and the need-to-know and the overall awareness of managers and authorized requestors.

HRSB and CFOB are the business owners and as such are accountable for applying access to roles, they provide a challenge function should access requests contravene segregation of duties; however, managers and authorized requestors are ultimately accountable for the access they request.

(16)

Authentication: sign-on, validating user and ensuring appropriate profile (or usercode)

For the authentication of new users, the auditors found that not all user request forms were approved by the immediate responsibility centre (RC) managers. The auditors were informed that the user request form could be approved by any manager in an employee’s work area and that no distinction was made regarding the reporting relationship. However, the audit team has recently been advised that CFOB is addressing this issue by verifying NHQ access requests with delegated signing authority. We were also told that IITB confirms an acting manager’s status prior to assigning the usercode. This process is dependent on the accuracy of the reporting relationship in the active directory.13

Protected

A CMS usercode cannot be provided without an employee’s PRI14_._Protected We also observed that temporary PRIs were provided to temporary workers (e.g., consultants, casual employees and students) to give them access to CMS. There was no consistency as some interviewees did not condone the practice, while others felt that temporary workers fulfill an operational need and should be granted access. Protected CFOB has since advised the audit team that the actual number is lower. The discrepancies are attributable to the ongoing

cleanup of CMS and the method required to obtain reliable user data. In order to produce user data multiple reports18_{must be generated and then validated in} CMS.

CMS users are intended to be uniquely identifiable by their CMS usercodes and as such should receive only one usercode during their employment at HRSDC. These usercodes can be activated, deactivated and reactivated as necessary. The testing indicated that due to a lack of standardization there were employees

13

Active Directory provides the means to manage the identities and relationships that make up network environments. 14 Protected 15 Protected 16 Protected 17 Protected 18

CFOB is using a combination of LOCUM and DSS as well as manually validating the information in CMS.

(17)

with more than one usercode (i.e. one active usercode and several non-active usercodes).

We also noted that managers and authorized requestors did not consistently apply the least-privilege principle and the need-to-know requirements. It is a common practice for managers and authorized requestors to ask for “the same as” or “9999” access without a clear understanding that employees could, as a result, gain more access than is needed to perform their duties. Employee

movement is not systematically tracked and access appropriately modified within CMS. Protected

Guidance is limited to security awareness training. No additional guidance (i.e. reference materials) is available to assist managers and authorized requestors as they make decisions regarding employee access.

Authorization: granting access and appropriate role

In a role based CMS environment permissions to perform specific computer-system functions are assigned to roles. The users are provided specific roles in order to perform their duties. When strictly applied users can only acquire permissions through their roles. The management of these users would be a matter of assigning the appropriate role(s).

Protected

There are approximately 180 default HR and finance roles, and more than 1,000 customized roles that are created and assigned to CMS user profiles, since customized roles can’t be reused for another account. The risk increases when too many customized roles are being created to fit specific functions, as they need to be maintained. Although roles are being created to fit user needs, the audit team did not find any standardized documentation describing the naming convention, the definition of the different roles and when or how to apply them to user profiles.

It was noted in one of the regions we visited, that a CMS coordinator was playing a dual function. This individual was responsible for applying roles to the usercode and was also approving user request forms. The auditors discussed the situation with CFOB (NHQ and the region) and at the conclusion of the audit; this matter was resolved by removing the individual’s privileged access to CMS.

Compliance: real-time logging, monitoring user access, auditing and reporting An important part of the Department’s responsibility in managing the user

lifecycle and privileged user access is demonstrating that access restrictions are enforced and monitored.

(18)

Protected

In an effective IAM environment, managers ensure that an employee’s access is accurate and aligned with current job responsibilities. The auditors found that the majority of interviewees were not aware that user access reports were available. We also found that the LCM001 report, used for this audit, was inadequate. For example:

the information is not consistently updated, e.g.: last login date was 2007 but the account was still active;

(19)

managers are not able to easily identify their employees as the report is sorted by RC;19

Protected and

there are data integrity issues such as: first and last names reversed, spelling mistakes, inconsistency of upper and lower case, blank fields and initials instead of names.

Protected

At the time of the audit, CFOB was developing a privileged user management process for CFOB privileged users. Although this process is a step in the right direction it is not standardized or centralized across the Department as it is limited to CFOB privileged users with access to the business modules. This process does not include HRSB and IITB nor does it address the actual number of privileged user accounts required to adequately maintain the system. The majority of interviewees stated that privileged user monitoring involved only random manual spot checks conducted on an ad hoc basis by colleagues and not by their managers.

Protected

De-provisioning: removing access

De-provisioning involves removing access to the system—an action prompted by circumstances such as a change to an employee’s role where access is no longer required (least-privilege principle and the need-to-know), extended leave (i.e. maternity or sick leave), or the employee is leaving the Department.

19

The access report is sorted by RC and then usercode. The seven-digit access code contains the first four digits of the RC code where the employee first obtained access. Any subsequent movement of the employee within the Department, including name of the employee, will not appear under the RC where he/she currently reports.

(20)

The automatic payroll control in the HR module was designed to suspend the employee’s account. This control however requires a manual change in the pay status of the employee in order to suspend access and is not a substitute for effective user access management.

Protected

Recommendations

1. IITB, in consultation with CFOB and HRSB, should develop and implement a comprehensive IAM strategy to address current weaknesses, to provide guidance and standardize access management practices.

2. CFOB and HRSB, in consultation with IITB, should develop and implement a centralized PUM process, as an important element of the overall

Department’s IAM strategy.

3. CFOB and HRSB, in consultation with IITB, should remind all managers and authorized requestors who are approving access to CMS of their roles, responsibilities and accountabilities associated with user access

management.

4. CFOB and HRSB, in consultation with IITB, should undertake the following activities to mitigate some of the risks identified during the audit:

- develop a process to manage temporary PRIs and perform a review of the current (active) temporary PRIs;

- reuse the same usercode instead of creating a new one each time a request for access is granted;

- Protected

- determine who should have access to the system and communicate decision to appropriate parties; and

- request that managers review and update employee access based on the least-privilege principle and the need-to-know.

2.3 No departmental risk management process exists for CMS The audit team did not find a risk management process in place to identify, mitigate and monitor risks in safeguarding access to CMS.

Analysis

An effective risk management process is an important component of a successful IT security system or program. This process helps to raise awareness and

(21)

the life of the system or program. The Department must be aware of threats and vulnerabilities to its information systems in order to prevent, detect, react to and recover from incidents.

The auditors were advised by interviewees from CFOB, HRSB and IITB that there is no formal or informal risk management process for CMS and no current and updated threat and risk assessment (TRA) to identify, assess, mitigate and monitor risks related to safeguarding access to CMS. Consequently, the

Department is non-compliant with the Government Security Policy and the Operational Security Standard: MITS, both of which require departments to continuously carry out activities designed to manage IT security risks. Recommendation

5. CFOB and HRSB should determine what level of CMS risk assessment is required to safeguard CMS as it continues to support the Department’s business environment over the next few years while ERP is being implemented.

(22)

3.0 CONCLUSION

The audit concluded that the current CMS control framework and its related system of controls and risk management practices are not adequate in

safeguarding access to its information assets. Although weaknesses have been identified that require management attention, issues are considered to be

moderate as the access to CMS is limited to HRSDC’s internal network. It is also important to note that improvements should focus on the Identity and Access Management Lifecycle rather than on the system itself as CMS will soon be replaced by industry standard ERP system.

4.0 STATEMENT OF ASSURANCE

In our professional judgement, sufficient and appropriate audit procedures have been performed and evidence gathered to support the accuracy of the

conclusions reached and contained in this report. The conclusions were based on observations and analyses of the situations as they existed at the time against the audit criteria. The conclusions are only applicable to the Audit of Access to the Corporate Management System. The evidence was gathered in accordance with the Internal Auditing Standards for the Government of Canada and the International Standards for the Professional Practice of Internal Auditing.

(23)

APPENDIX A: Audit Criteria

The conclusions reached for each of the audit criteria were developed according to the following definitions. Numerical Categorization Conclusion on Audit Criteria Definition of Conclusion 1 Significant Improvements Required

Requires significant improvements (at least one of the following three criteria need to be met):

financial adjustments material to line item or area or to the Department; or

control deficiencies represent serious exposure; or

major deficiencies in overall control structure.

Note: Every audit criterion that is categorized as a “1” must be immediately disclosed to the Chief Audit Executive (CAE) and the client Director General or higher level for corrective action.

2 Moderate Issues Has moderate issues requiring management focus (at least one of the following two criteria need to be met):

control weaknesses, but exposure is limited because likelihood of risk occurring is not high;

control weaknesses, but exposure is limited because impact of the risk is not high.

3 Controlled well managed, but minor improvements

are needed; and

effective.

4 Well Controlled well managed, no material weaknesses noted; and

effective.

The following table outlines the audit criteria and examples of key evidence and/or observations noted which were analyzed and against which conclusions were drawn. In cases where significant improvements (1) and/or moderate issues (2) were observed, these were reported in the audit report.

(24)

Audit Criteria Conclusion Observations/Examples of Key Evidence

2.1 CMS Governance: It is expected that the Department has the infrastructure, policies, practices and procedures in place to manage user access in CMS.

The HRSDC Control Framework for CMS is compliant with TBS policies and directives.

2 The CMS framework provided was last updated in 2002 and is not compliant with TBS policies.

Although CMS is primarily a financial system, it also holds HR data. In NHQ, CFOB is responsible for approving and applying roles to the HR modules. We have not found a Memorandum of Understanding between CFOB and HRSB

describing roles and responsibilities regarding user access management for the HR module.

User access management is included in the control framework and is aligned to ensure that management monitors progress and has in place a continuous improvement plan.

2 The control framework does not specifically address information asset management or user access management.

There is currently no IAM within the Department; however, IITB is developing a departmental strategy.

There is no evidence of progress monitoring related to CMS user access management.

The roles, responsibilities and accountabilities are clearly defined, delegated and communicated.

2 There is no formal documentation, i.e. a framework outlining roles, responsibilities and accountabilities of all employees, as part of the CMS user access lifecycle.

CMS is primarily a financial system, it also holds HR data. In NHQ, CFOB is responsible for approving and applying roles to the HR modules. We have not found a Memorandum of Understanding between CFOB and HRSB

describing roles and responsibilities regarding user access management for the HR module.

Managers interviewed during the audit did not always understand the extent of their responsibility.

(25)

Processes are in place to establish, maintain and monitor user access in order to preserve the confidentiality, integrity and availability of data.

2 Obtaining an accurate inventory of employees that have access to CMS and their level of access proved to be very difficult, as multiple reports need to be generated and validated in CMS.

The information provided in the requested reports was not

sufficiently detailed and specific to CMS.

This element was also assessed in 2.2, under compliance.

(26)

2.2 Controls: It is expected that CMS has a documented and approved user access management process in place to provide only authorized individuals with access to the system based on business requirements.

Internal policies and practices, related to

information access, comply with TBS policies and regulations.

3 and 2 The Policy on departmental IT Security Management complies, as it relates to information access, with TBS policies.

The auditors observed that usercode creation in NHQ is the same as in the regions as it is performed by IITB-SECURITY.

IITB-SECURITY has established a standardized process for usercode creation, modification and deletion; however, the procedure differs slightly between NHQ and the regions.

In NHQ the request (form 5012) is initiated by managers and is sent directly to CFOB.

CFOB then requests the user code from IITB-SECURITY. CFOB grants access to the appropriate module (HR and/or finance), as CFOB is responsible for both modules.

In Moncton and Montreal, the request (form 5046) in sent directly to IITB-SECURITY, then to CFOB for approval of the financial module access and HRSB for approval of the HR module access.

In Belleville, the process is similar to NHQ.

Current information access

practices are not aligned to reflect the intent of the policy, as the least-privilege principle and the need-to-know are not always considered when creating and approving user accounts.

(27)

CMS users (internal,

external and temporary) are uniquely identifiable and have appropriate security clearance.

2 Not all user accounts are uniquely identifiable. We found an instance where a user had a permanent and temporary PRI active at the same time.

The security level is determined by the job description at the time of hiring and is done systematically.

The security level is tied to the job description of an incumbent. When an employee is assigned a PRI, the appropriate security level is

required and it is done prior to an employee start date. The personnel security screen, within the HR module, is where all users and potential users have their

appropriate security level entered.

The Atlantic and Montreal regions stated that no access is granted before a security check is performed.

We have not been able to find any documentation describing the required security levels for users needing access to CMS.

Managers and authorized requestors understand their responsibility in granting access to users (based on the least-privilege

principle/need-to-know).

2 Although most managers and authorized requestors interviewed told the auditors that they were aware of the least-privilege

principle and the need-to-know, we noticed that some access request forms are still based on “same as” or “9999” access, especially in the regions.

We observed that some users have more rights than needed to perform their duties.

CMS user access rights are formally requested by management or an authorized requestor, approved and implemented

2 We found that requests are approved by managers, even though the users do not report directly to that manager.

(28)

by the data owners based on a predefined level of access appropriate to each group of users.

Authorized requestors who approve a request need to be on an

approved list of authorized

requestors to whom authority has been delegated by the

manager/director using form 5054. Management understands

their responsibility in granting access to super users/privileged users (based on the least-privilege principle and the need–to-know).

2 Assessed in 2.2, under compliance.

CMS information can only be accessed or modified by those authorized to do so.

2 Although log files for unauthorized access (i.e. browsing) are available, they are not systematically

monitored.

We observed users who had

moved from one position to another and/or to different branches, still had potential non-related access attached to their accounts, circumventing the least-privilege principle and the need-to-know. Segregation of duties is

reflected in access

privileges; no one user can independently control all aspects of a process or a system including privileged users.

3, except for one exception

For the most part, we observed good segregation of duties between IITB (creation of usercodes) and CFOB and/or HRSB (attribution of roles to usercodes).

Segregation of duties for CMS users (roles assigned to complete a task) could not be assessed due to system limitations as reports did not provide adequate information.

In one region, a CMS coordinator was approving user access request forms and was attributing roles to the same accounts. This situation was brought up to management’s attention which resolved the issue. CMS access privileges are

regularly updated to accurately reflect the

1 Access is not regularly updated, and is not assessed to determine if a user’s access has changed

(29)

current responsibilities and users organizational units; privileges are revised when users move to new

positions, and are

withdrawn from users who leave the organization.

(This criterion was used to assess the movement and the departure of

employees.)

during the course of an employee’s employment with the Department.

Without proper module integration and a standardized process, movement of employees is very difficult to establish and is limited in CMS.

We have found no evidence of a standardized process for applying roles to usercode. It is left to the discretion of the CMS coordinator.

The Department is not granting access consistently.

Testing indicated that user access management is not being updated to reflect the current status of the employee.

CMS user activity, including super users/privileged users, is monitored and any security issues or abuse of privileges are reported to management in a timely manner. An audit trail is maintained to confirm "who did what, when and how".

2 Successful or unsuccessful user access is captured in log files; however, we have found no evidence of an automatic and systematic monitoring function.

Transactional activities are captured.

At the time of the audit, CFOB was working on a privileged user access process.

Processes are in place to ensure that unauthorized accesses are detected, investigated, reported and appropriate administrative action is taken.

2 We have not found any evidence of a standardized process to capture and report unauthorized access. The process is “ad hoc” and manual.

(30)

2.3 Risk Management: It is expected that there is a process in place to identify, mitigate and monitor risks in safeguarding access to CMS.

Documented and approved risk management process is in place to identify, assess, mitigate and monitor risks related to the safeguarding of access to CMS information assets.

2 We found no evidence of any risk management or ongoing TRA to identify, assess, mitigate and monitor risks related to safeguarding access to CMS information assets.

Interviewees were not aware of formal or informal risk management process for CMS.

In addition, interviewees were not aware of current or updated threat risk assessment having been carried out.

(31)

APPENDIX B: Glossary

CAE Chief Audit Executive

CFOB Chief Financial Officer Branch

CMS Corporate Management System

EDS Electronic Document System

ERP Enterprise Resource Planning

HR Human Resources

HRSB Human Resources Services Branch

HRSDC Human Resources and Skills Development Canada

IAM Identity and Access Management

IITB Innovation, Information and Technology Branch

IT Information Technology

MITS Management of Information Technology Security

OAG Office of the Auditor General

OMTM Operations and Maintenance Transaction Module

NHQ National Headquarters

PRI Personal Record Identifier

PUM Privileged User Management

RC Responsibility Centre

SAP Systems, Applications and Products

TBS Treasury Board Secretariat

(32)

APPENDIX C: Definitions

Access The right or permission that is granted to an identity.

These informational access rights can be granted to allow users to perform transactional functions at various levels.

Authorization A process for determining what types of activities are

permitted. Ordinarily, once authenticated, a user may be authorized to perform different types of activity or

granted certain access rights.

Authorized Requestor

An authorized requestor is an employee delegated by their manager, using form 5054, to approve access to CMS on his or her behalf.

Control Framework A recognized system of control categories that covers

all internal controls expected in an organization.

Enterprise Resource Planning

A system used to manage and coordinate all the resources, information, and functions of a business.

Identity and Access Management

System/Strategy

A system consisting of one or more subsystems and components that facilitates the establishment,

management, and revocation of identities and accesses to resources.

Identity A unique sequence or set of characteristics that

uniquely identifies an individual.

Identity Lifecycle Management

The processes used to create and delete accounts, manage account and entitlement changes, and track policy compliance.

Job Profile A collection of application screens required to be

accessed by individuals in the performance of their job.

Privacy Impact Assessment

A privacy impact assessment is a process to determine the impacts of a proposal on an individual’s privacy and ways to mitigate or avoid any adverse effects.

Provisioning The process used to create identity, associate identities

(33)

PeopleSoft A commercial-off-the-shelf (COTS) system, modified to meet common Government of Canada (GC) HR and legislative requirements that provides an integrated platform for the management of HR information.

Roadmap A tool to enable stakeholders and leaders to better plan

for and make decisions about the future.

SAP Systems, Applications and Products in Data Processing

is a commercial-off-the-shelf (COTS) system, modified to meet common GC financial and legislative

requirements that provides an integrated platform for the management of financial information.

Segregation of duties

A control mechanism whereby a process is broken into its constituent components and the responsibility for executing each component is divided among different individuals. Segregation of duties segments the process so that no individual has an excessive ability to execute transactions or unilaterally cover irregularities without detection.

Stakeholder A stakeholder is anyone who has either a responsibility

for or an expectation from the enterprise’s IT, e.g., senior managers, directors, managers, users and employees.

Privileged User A privileged user or super user who has by virtue of

function, and/or seniority, been allocated powers within the computer system, which are significantly greater than those available to the majority of users. Such persons will include, for example, the system administrator and database administrator.

Threat and Risk Assessment

The objective of a threat and risk assessment is to determine exactly what needs to be protected and why; it aids in the determination of security requirements.

Usercode/Profile An identifier or login identification on a specific resource

(34)

APPENDIX D: CMS User Access Information

The information provided below was generated from the DSS database by CFOB dated January 31, 2012. Although the information below provides some detail in terms of the breakdown of user access it does not indicate which users have transactional and or inquiry access. Due to system limitations a detailed grouping of user access roles in CMS is not easily achieved. In order to determine access levels CFOB would have to manually review each role assigned to the user to determine the level of permission.

CMS User Access Information

User Access Distribution Employees Non-Employees

Atlantic 427 22

CFOB – Enabling Services Renewal Program

27 2

CFOB 924 103

HRSDC & Service Canada (SC) – IITB 374 3

HRSB 663 8

Labour 125 2

NHQ 560 7

Ontario 632 110

Processing & Payment Services Branch 109 4

Quebec 599 92

SC – Chief Operating Officer Roll-up 2 0

SC – Citizen Service Branch 54 0

SC – Service Management 83 5

SC Assistant Deputy Minister Integrity Services Branch

63 6

Western Canada & Territories 969 44

Total 5611 408

[NORMAL] Audit of Access to the Corporate Management System. Audit Report

Audit of Access to the

Corporate Management System

Audit Report

Table of Contents

EXECUTIVE SUMMARY

1.0 BACKGROUND

2.0 AUDIT FINDINGS

3.0 CONCLUSION

4.0 STATEMENT OF ASSURANCE

APPENDIX A: Audit Criteria

APPENDIX B: Glossary

APPENDIX C: Definitions

APPENDIX D: CMS User Access Information