Audit of System Access Controls

Internal Audit and Accountability Branch
Citizenship and Immigration Canada
Final Report
May 2012

Table of Contents

• List of Acronyms
• Executive Summary
• 1.0 Introduction
  • 1.1 Background
    • 1.1.1 Organization
    • 1.1.2 About System Access Controls
    • 1.1.3 Environmental Context
  • 1.2 Audit Risk Assessment
  • 1.3 Audit Objective
  • 1.4 Audit Criteria
  • 1.5 Audit Scope
  • 1.6 Audit Methodology
• 2.0 Audit Conclusion
• 3.0 Observations and Recommendations
  • 3.1 Control Environment
    • 3.1.1 Governance and Strategic Direction
    • 3.1.2 Accountability
    • 3.1.3 Results and Performance
    • 3.1.4 Risk Management
  • 3.2 Internal Control Framework
    • 3.2.1 Stewardship
      • 3.2.1.1 Identification and Authentication
      • 3.2.1.2 Authorization and Control
      • 3.2.1.3 Review and Detection
    • 3.2.2 People
• Appendix A: Detailed Criteria for the Audit
• Appendix B: Management Action Plan
• Appendix C: Audit Time Line

List of Acronyms

ACU

Access Control Unit

ASC

Access Security Coordinator

CBSA

Canada Border Services Agency

CIC

Citizenship and Immigration Canada

COBIT

Control Objectives for Information and Related Technology

CPIC

Canadian Police Information Centre

CRP

Corporate Risk Profile

CSQ

Client Status Query

FOSS

Field Operations Support System

GCMS

Global Case Management System

HR

Human Resources

SAP/IFMS

Integrated Financial Management System

IPAR

Immigration Program Accounts Receivable

IM/IT

Information Management and Information Technology

IMTB

Information Management and Technologies Branch

IT

Information Technology

MAF

Management Accountability Framework

MITS

Management of Information Technology Security

NCMS

National Case Management System

NHQ

National Headquarters

HRMS

Human Resource Management System

RBAP

Risk-Based Audit Plan

SIMB

Solutions and Information Management Branch

TBS

Treasury Board Secretariat

TRA

Threat and Risk Assessment

Executive Summary

The Citizenship and Immigration Canada (CIC) Internal Audit and Accountability Branch Risk-Based Audit Plan (RBAP) identifies audit and advisory engagements to be undertaken during the current year by weighing a combination of departmental priorities and risks. The 2011–2014 RBAP, which was approved by the Departmental Audit Committee in April 2011, identified the need for an audit of system access controls. This audit on the internal controls in place over system access controls.

As part of the Corporate Services Sector, the Information Management and Technologies Branch (IMTB) is responsible for planning, building and operating the applications, and the information and technology infrastructure needed to support the delivery of CIC services and programs to Canadians, immigrants and refugees, and to administer and manage the Department. On April 1, 2012, IMTB and the Global Case Management System (GCMS) amalgamated to form the Solutions and Information Management Branch (SIMB).

The objective of this audit was to assess the strength of the control environment and the adequacy of the related internal controls framework in place over system access controls. The criteria used in the audit were based on applicable Treasury Board Secretariat (TBS) and CIC legislation, policies and directives, along with components from a generally accepted information technology (IT) governance framework.

The audit concludes that policies outlining the governance structure and strategic direction for system access controls were in place.

Specifically, we found that our expectations were partially met for the control environment and the internal control framework. The extent to which our expectations were met varied according to the systems that we examined.

Management’s attention is required in a number of areas outlined in section 3.0 of this report where detailed observations and recommendations are highlighted to strengthen areas of concern. These include:

• To further strengthen accountabilities related to system and data ownership;
• To monitor and report results related to indicators and outcomes to senior management, as planned;
• To ensure that risk assessments regarding access to systems are in place and documented for systems;
• To strengthen controls regarding access to systems, including password controls, granting system access, monitoring inactive accounts and monitoring unauthorized access; and
• To improve the guidance provided to those charged with managing access to systems.

The report includes responses to our recommendations, a management action plan and proposed implementation dates to address the recommendations.

The audit was conducted in accordance with the Internal Auditing Standards for the Government of Canada and the International Standards for the Professional Practice of Internal Auditing.

1.0 Introduction

The CIC Internal Audit and Accountability Branch Risk-Based Audit Plan identifies audit and advisory engagements to be undertaken during the current year by weighing a combination of departmental priorities and risks. The 2011–2014 RBAP, which was approved by the Departmental Audit Committee in April 2011, identified the need for an audit of system access controls over CIC’s IT applications. This audit on the internal controls in place over system access controls. The examination phase was conducted between June 2011 and January 2012.

1.1 Background

1.1.1 Organization

As part of CIC’s Corporate Services Sector, IMTB is responsible for planning, building and operating CIC’s IT applications, the information and technology infrastructure needed to support the delivery of CIC services and programs to Canadians, immigrants and refugees, and to administer and manage the Department.

On April 1, 2012, IMTB and GCMS amalgamated to form the Solutions and Information Management Branch.

Within SIMB, the Information Technology Directorate’s responsibilities include desktop support, IT security, database administration, release management, certification, IT asset management, access control, IT mobility, non-Shared Services Canada engineering, and the domestic and international Help Desk.

In general, access to systems is controlled by SIMB for both national headquarters (NHQ) and regional offices. However, the Financial Operations Branch and the Human Resources Branch both have some responsibilities for system access related to certain finance- or administration-specific IT systems. Access security coordinators and super users throughout the Department are also involved in the administration of systems access.

1.1.2 About System Access Controls

CIC relies heavily on various electronic systems to deliver its mandate. As a result, effective access controls are critical to ensure that the data contained within these systems are duly safeguarded and secured from unauthorized access. These systems are used domestically and internationally.

The government’s requirements for departments that establish system access controls are outlined in the TBS Policy on Government Security and the related Operational Security Standard: Management of Information Technology Security (MITS). MITS defines the baseline security requirements that government departments must meet. It also expands on the policy regarding IT security, including system access controls. MITS includes standards for preventative safeguards, including identification and authentication safeguards and authorization and access controls, as well as risk-based detective control requirements. The requirements outlined in these two documents formed the basis for developing our audit criteria.

1.1.3 Environmental Context

The mission of information management and information technology (IM/IT) at CIC is to empower our clients by providing access to information and technology solutions anytime and anywhere. CIC is committed to maintaining a high quality, global (IM/IT environment that develops business solutions by exploiting advances in technology and government-wide initiatives such as shared services.

Information technology is ubiquitous, easy to use and fully integrated within CIC’s work. The work environment leverages an evolving suite of collaborative tools to engage with internal and external partners. Information sharing and collaboration both within the Department and with partners are being emphasized and expanded through social media tools and similar services as they emerge. CIC (IM/IT capitalizes on information analysis, knowledge management tools and applications for core business functions to further the goals of client service modernization, refugee reform and management excellence.

Identity and access management are the centrepieces of IT and information security. Of prime importance and consideration to securing CIC’s information are the access permissions granted to personnel: when, for which systems and information, and for how long.

1.2 Audit Risk Assessment

During the planning phase of this audit, a preliminary risk assessment was completed through planning interviews and meetings at NHQ, and a review of documents. This information was analysed against core management controls categorized by the Management Accountability Framework (MAF) element, as well as other applicable frameworks and standards such as the Control Objectives for Information and Related Technology (COBIT) and MITS, to identify and assess areas of particular risk. The analysis was conducted to determine the scope of the audit, to form audit criteria and to establish audit methodology to gather sufficient, reliable, relevant and useful evidence in support of the audit observations and findings.

Based on this analysis, the following areas were recommended for inclusion in the scope of the audit (see a further explanation of the audit scope below).

1.3 Audit Objective

The objective of this audit was to assess the strength of the control environment and the adequacy of the related internal controls framework in place over system access controls.

1.4 Audit Criteria

Criteria are benchmarks against which audit engagement objectives are assessed. The audit criteria were based on applicable TBS and CIC legislation, policies and directives, along with components from a generally accepted IT governance framework. The detailed criteria for the audit, provided to management at the outset of this engagement, are presented in Appendix A.

1.5 Audit Scope

The audit covered the management of system access controls at NHQ while also considering regional procedures that involve NHQ. The scope was limited to activities controlled by CIC.

CIC has 135 business, corporate, information management and online systems. However, a significant number of them have limited risks associated with their operation, are accessed mainly by users external to CIC, or have been subject to recent audit activities in the controls area.

In order to focus the audit resources on CIC’s higher risk, business-critical systems, the audit team excluded a large number of these systems from the audit scope. Online IT applications were excluded to focus the audit on internal-use IT applications rather than public access applications. The Computer-Assisted Immigration Processing System was excluded because of coverage in mission audits and since its use has been reduced due to the roll-out of GCMS overseas.

From the remaining systems, the audit team on the largest and most significant^{Footnote 1} systems to arrive at the eight systems listed below. The National Case Management System (NCMS) was included at the suggestion of management, as was the Client Status Query (CSQ) because of its link to NCMS.

The systems selected for inclusion in this audit are the following:

• Global Case Management System (GCMS)
• Field Operations Support System (FOSS)
• Integrated Financial Management System (SAP/IFMS)
• PeopleSoft Human Resource Management System (PeopleSoft HRMS)
• Immigration Program Accounts Receivable (IPAR)
• National Case Management System (NCMS)
• Client Status Query (CSQ)
• Canadian Police Information Centre (CPIC)

The period of the scope included control activities related primarily to the 2010–2011 fiscal year.

With respect to CPIC, NCMS and CSQ, our examination was limited to areas of system access for which CIC is responsible. For NCMS, system user roles are assigned by the Canada Border Services Agency (CBSA) after CIC has set up individual accounts for access to the system, and access to CSQ is query-only. Therefore, our review of these systems on the creation and monitoring of accounts by CIC. CPIC is managed by the National Police Service and administered by the RCMP. The review of this system was limited to the responsibilities of the Access Control Unit (ACU), primarily those related to the administration of user accounts.

The audit on the administration of access controls for user applications, at the application level. It was not intended to encompass controls at the network, database or operating system levels.

1.6 Audit Methodology

The audit was conducted in accordance with the Internal Auditing Standards for the Government of Canada and the International Standards for the Professional Practice of Internal Auditing.

There were two lines of enquiry:

• the control environment; and
• the internal control framework.

During the planning phase of the audit, the audit team conducted interviews and a preliminary review of documents to identify and assess areas of particular risk. The risk assessment enabled us to focus the audit scope and criteria on the areas of greatest risk. In addition, it helped us to establish our audit procedures to gather sufficient, reliable, relevant and useful evidence to support our audit observations and findings.

As part of our examination of the control environment and the internal control framework, we conducted further interviews with management and staff, reviewed documents, conducted audit testing, reviewed files and analysed our observations and findings.

2.0 Audit Conclusion

We found that with respect to the control environment and the internal control framework, our expectations were partially met. The extent to which they were varied depending on the systems we examined. We found that policies outlining the governance structure and strategic direction for system access controls were in place.

Management’s attention is required in a number of areas outlined in the next section of this report. Detailed observations and recommendations are highlighted to strengthen these areas of concern. The report includes management’s responses, an action plan and proposed implementation dates to address the recommendations.

3.0 Observations and Recommendations

3.1 Control Environment

The objective for this line of enquiry was to assess the adequacy of the governance and risk management frameworks in place at CIC to implement system access controls, focusing on the following areas:

• governance and strategic direction;
• accountability;
• results and performance; and
• risk management.

We expected to find that there were departmental policies in place that set out expectations related to system access controls; that there were clearly defined roles and responsibilities regarding data and system ownership to ensure that system access control is managed in line with the organization’s objectives; that procedures were in place to measure, and to report to senior management, the effectiveness of system access controls performance; and that risks associated with system access controls had been identified and assessed, and mitigating controls had been implemented.

Overall, the control environment in place for system access controls partially met our expectations.

3.1.1 Governance and Strategic Direction

We expected to find an overarching policy or framework in place that set out departmental expectations regarding system-level access control policies, and that guided the use of IT in the achievement of the organization’s objectives.

We found that CIC’s IT Security Policy (“the Policy”) addressed the requirements related to the system access controls prescribed by MITS.

The Policy sets out the requirements for ensuring the confidentiality, availability and integrity of information technology assets in order to sustain departmental programs and those of departmental partners and stakeholders. The Policy includes the requirement to identify and categorize information and IT assets, and to limit access to and use of IT applications based on appropriate security levels and an individual’s need-to-know level. In addition, the Policy specifically requires that the Department establish processes for reviewing and adjusting access to and use of privileges.

3.1.2 Accountability

We expected to find that departmental or system-level policies defined the roles and responsibilities regarding data and system ownership.

We found that the extent to which system-level policies or documents were in place for the systems that we examined ranged from nonexistent to policies being in place that clearly defined the roles and responsibilities regarding data and system ownership.

For PeopleSoft HRMS, we found security procedures and guidelines that clearly defined the roles and responsibilities for its users.

With respect to GCMS, we found that a statement of sensitivity and a threat and risk assessment (TRA) were in place. These documents contain key elements of what we would expect to find in a system-level policy regarding the definition of roles and responsibilities, including identifying the business owner; rating the security objectives related to confidentiality, integrity and system availability; and providing information to senior management to enable them to make informed decisions regarding the security of GCMS. In addition, we found that GCMS’s guidance for establishing user accounts defined the base roles for the immigration and citizenship programs, along with the functional roles for the Immigration and Health Management branches.

With regard to SAP/IFMS, we noted that system-level policies are under development and therefore not in place. As for FOSS, there is no system-level policy or document that defines the roles and responsibilities regarding data and system ownership. It is unclear who has the authority to determine access levels and few restrictions are set, leaving this determination to the user’s manager and the Access Security Coordinator within each office. Similarly, system-level policies and documents were also not available for IPAR, NCMS and CSQ.

CIC is not responsible for the policies and procedures on system and data ownership for CPIC. As a result, we did not examine these policies.

Recommendation 1

SIMB, in conjunction with Finance where appropriate, should ensure that policies and procedures outlining system and data ownership are in place for all IT systems.

Management Response

SIMB will review its suite of governance products to ensure that system and data ownership for SAP/IFMS, FOSS and IPAR is captured appropriately. In conjunction with Finance where appropriate, SIMB will prepare such documents where they don’t exist for approval by senior management. The target date is Q4 2012–2013.

CSQ is a query system and not a data repository, and it will be decommissioned in the near future. The ownership of data does not apply in this case

As NCMS is owned by the CBSA, data ownership for this system does not apply to CIC.

Note: Ownership of NCMS was officially transferred to the CBSA on December 1, 2011. However, the system remains on CIC’s network. While accounts are still created by CIC, the CBSA retains ownership of the data.

3.1.3 Results and Performance

We expected to find that performance results were assessed and communicated to senior management.

We found that outcomes and indicators related to system access controls were defined in IMTB’s business plan. However, based on our discussions with management, these outcomes and indicators were not actively monitored and therefore not reported to senior management in the departmental quarterly reports and their related dashboards.

Every year, CIC submits a MITS assessment to TBS that is used to provide input into the MAF assessment. CIC’s assessment includes a section on the Department’s compliance with MITS related to “Authorization and Access Controls.” In its December 2010 submission under the Authorization and Access Controls section, CIC assessed both “Management of Access Privileges” and “Control of Access to Information and IT Systems” as partially compliant.

CIC’s revised Policy on IT Security (effective April 1, 2011) sets out the monitoring and reporting requirements that were not explicitly addressed in the previous version. These requirements include responsibilities for ensuring implementation of the policy across CIC, monitoring overall departmental compliance and periodically evaluating its effectiveness.

Recommendation 2

SIMB should ensure that indicators and outcomes that have been developed for system access controls are monitored and that the related results are reported to senior management on a periodic basis as planned.

Management Response

SIMB will monitor valid active application accounts and report incidence or instances of unauthorized access to senior management in the quarterly dashboards. The target date is Q4 2012–2013.

3.1.4 Risk Management

We expected to find that management identified risks associated with system access controls, that risks associated with system access controls had been assessed, and that mitigating controls had been implemented.

The Department identified the key risks related to the achievement of its corporate objectives, including those related to (IM/IT, within CIC’s Corporate Risk Profile (CRP). In addition, risks were assessed and mitigation measures were identified in the CRP. Progress against milestones associated with the CRP is reported through the Corporate Services Sector’s quarterly report. Unauthorized access to IT systems is specifically identified as a potential risk within the CRP. We noted that the IMTB business plan indicated that (IM/IT also played a contributing role in the management of other departmental risks, including those related to program integrity and delivery.

Risks are also identified and reported to senior management and TBS through the annual MITS compliance submission which provides input into the MAF assessment for IT security.

On a system-by-system basis, we expected to find certification and accreditation documents, statements of sensitivity, and TRAs that identify and assess specific risks associated with the system, along with mitigating controls. CIC is not responsible for risk management for CPIC. As a result, we did not examine risk management for this system.

With regard to GCMS, we found that certification and accreditation documents, statements of sensitivity and TRAs were in place.

We did not find any certification and accreditation documents, statements of sensitivity or TRAs available for FOSS, PeopleSoft HRMS, NCMS, CSQ or IPAR. This weakness or risk area was highlighted in the MITS compliance submission.

Recommendation 3

SIMB, in conjunction with Finance and Human Resources (HR) where appropriate, should ensure that risk assessments regarding access to systems are prepared and documented for all IT systems.

Management Response

The PeopleSoft TRA has been drafted and work will continue, in conjunction with HR, until completion. The target date is Q3 2012–2013.

Since both a TRA and a Privacy Impact Assessment exist for SAP/IFMS, which are both still valid, this requirement has been met. These will be submitted as requested.

TRAs will not be completed for FOSS since it will reach its end of life in two to three years; for NCMS since the CBSA is now the owner of this IT system and responsibility for the TRA was transferred with it; for IPAR because this system will be decommissioned within 18 months; and for CSQ since this system will also be decommissioned within 18 months.

3.2 Internal Control Framework

The objective for this line of enquiry was to assess the adequacy of the internal control framework over the implementation of system access controls, focusing on stewardship and people.

We expected to find that an appropriate control framework was in place to ensure that access to systems was granted to uniquely identifiable users; that access was controlled by appropriate authentication controls; that access was granted to properly screened and authorized users; that system access was monitored to ensure that user access levels remained appropriate over time; that unauthorized access could be detected; and that employees and managers had the training and tools to effectively perform their responsibilities related to system access control.

Overall, the internal control framework in place for system access controls partially met our expectations.

3.2.1 Stewardship

3.2.1.1 Identification and Authentication

We expected to find that identification and authentication safeguards were incorporated into the systems based on the level of risk assessed for the IT system. These safeguards should include the unique IDs assigned to specific users along with password controls appropriate for the identified risks and sensitivities related to the IT system and its data.

With regard to identification safeguards, we found that they were in place for two of the eight systems that we examined. For the remaining systems that we examined, we noted instances of existing generic accounts and instances where users had been assigned multiple accounts.

With respect to PeopleSoft HRMS and CPIC, we found that all users had individual and unique IDs that would allow their activities to be recorded and reviewed.

In SAP/IFMS, we found a few generic accounts not assigned to a specific user. We noted that all these generic accounts had their functionality permissions removed and all but one were locked so that these accounts could not be used to access the system and its data.

In NCMS and CSQ, we found a few IDs for accounts that had not been assigned to specific, identifiable users. However, we noted that none of these accounts had been accessed.

In IPAR, we found that five percent of IDs for active accounts were not assigned to specific, identifiable users. We were unable to determine whether these accounts had been accessed due to a lack of system functionality to track user access.

Regarding GCMS, we found nine percent of user accounts had not been assigned to specific employees but rather to a job title or a region. As a result, user access cannot be tied to specific individuals for these accounts. We further noted that some of these accounts had been accessed and used.

In FOSS, we noted that 1% of “active” (non-suspended) and “regular” (non-emergency) generic accounts were in place and for which specific users were not immediately identifiable. Of these, some appeared to have been used for emergencies (although not classified as “emergency” accounts, which have additional controls), some accounts were used for test or system development purposes, and the purpose of the remaining accounts was unclear.

Moreover, we noted that a small percentage of GCMS (2%), FOSS (<1%), PeopleSoft HRMS (7%), IPAR (5%) and NCMS/CSQ (<1%) users appeared to have multiple accounts.

With respect to authentication safeguards, we did not examine CPIC as the password parameters and requirements to change passwords are the responsibility of the RCMP. For GCMS, we found that the authentication requirements (i.e., password parameters and password change requirements) were determined on a risk-basis based on management’s identification of risks and sensitivities related to the system and its data. For the remaining systems that we examined, we found that the authentication requirements were not determined on a risk basis as risks and sensitivities for the respective systems were not identified by management. As a result, management cannot be certain that the level of password protection for these systems is appropriate.

Recommendation 4

SIMB, in conjunction with Finance and HR where appropriate, should identify the risks and sensitivities for each IT system and its related data to ensure that the system’s password controls are appropriate.

Management Response

Where they exist, SIMB ensures that the system password controls are appropriate as recommended by the TRA performed on the system. New TRAs will identify the risks and sensitivities for each IT system for which a TRA is to be performed.

For SAP/IFMS, the one generic account not assigned to a specific user is necessary for system interaction. Generic accounts for CSQ will be deleted if not being used as an interface with another system. For FOSS, SIMB will work with partners to better classify or delete the accounts identified where appropriate.

Since GCMS was recently fully deployed to overseas and in-Canada offices, user accounts were initially bulk-loaded after verification with office managers. GCMS has initiated a process with the Operations Sector to send user account information by office to all offices across the network and NHQ for validation. This exercise to validate user accounts by office is to be carried out on a regular basis. The first set of lists was sent at the end of January 2012. Once offices and NHQ have reviewed the lists, any necessary changes will be made according to established procedures for changes to user accounts.

The target date for review of FOSS and GCMS user accounts is Q3 2012–2013.

3.2.1.2 Authorization and Control

We expected to find that users were screened, authorized, identified and authenticated prior to granting system access, and user access was monitored on an ongoing basis for appropriateness.

We expected to find a completed account access authorization form on file for each individual user, authorized by an appropriate departmental official. The account access request form should be designed to clearly outline the access level required by user type for a particular system, along with areas for the identification and signature of the proposed system user and the identification and authorization of the appropriate authorizing departmental official.

We found that the user access request forms for the various systems that we examined were properly designed with respect to user identification and sign-off, and authorizing officer identification and authorization. With respect to the required access level by user type, we found that the access request forms were appropriate for all systems that we examined with the exception of SAP/IFMS. For SAP/IFMS, the access request form does not contain a section on the access requirements specific to the user’s needs.

With respect to our examination of a sample of account access authorization forms, we noted that forms could not be located for a significant number of our sample items ( SAP/IFMS: 3%; PeopleSoft HRMS: 10%; GCMS: 33%; and FOSS/NCMS/CSQ: 12%). In addition, for those selected forms that could be found, we noted a number of them that were not properly authorized with a signature from an appropriate departmental official ( SAP/IFMS: 15%; PeopleSoft HRMS: 11%; GCMS: 5%; and FOSS/NCMS/CSQ: 13%). In some cases, forms were missing one of the two required signatures, while in a small number of others, the Access Security Coordinator (ASC) and manager were the same person.

With respect to monitoring user account activity, we expected to find procedures in place for the regular monitoring of user account activity to ensure that the user’s access level remained appropriate for an individual user’s needs over time.

We found that inactive account procedures were in place for SAP/IFMS and PeopleSoft HRMS. However, there were no inactive account procedures in place for GCMS, FOSS and NCMS/CSQ. With the latter group of systems, the ACU relies on ASCs across the Department to request that access privileges be withdrawn from individuals who leave the organization or revised when individuals move to jobs that do not require the same level of access. With no inactive account policies in place, we found that 11% of FOSS accounts (for FOSS users at CIC and in other government departments), 18% of GCMS accounts, 7% of NCMS and 8% of CSQ had not been accessed since before January 1, 2010.

In addition, we found that accounts appearing to belong to employees who left the Department in 2010–2011 and had not returned as of August 2011 remained in many of the systems reviewed. This included 5% of CIC FOSS accounts, 3.5% of in-Canada GCMS accounts, and a small number CPIC, NCMS, CSQ and SAP/IFMS accounts.

Recommendation 5

SIMB, in conjunction with Finance and HR where appropriate, should ensure that a properly authorized system access request form is kept on file for all system users.

Management Response

SIMB, in conjunction with Finance and HR where appropriate, will ensure that request forms are kept on file for all system users to effectively manage authorized system access. The target date is Q4 2012–2013

Recommendation 6

SIMB, in conjunction with Finance and HR where appropriate, should ensure that procedures are put in place to regularly monitor inactive user accounts and ensure that access privileges remain appropriate for user needs.

Management Response

SIMB, in conjunction with Finance and HR where appropriate, will develop and document a process to monitor inactive user accounts and to ensure that access privileges remain appropriate for user needs. The target date is Q4 2012–2013.

3.2.1.3 Review and Detection

We expected to find that processes were in place to enable monitoring, review and detection of unauthorized access. We expected to find a process in place to monitor unauthorized access attempts, unusual activity, and access to sensitive transactions through the examination of security logs or system-generated reports regarding user access attempts.

CIC is not responsible for monitoring access to CPIC. As a result, we did not examine the unauthorized access monitoring process for that system.

In the remaining systems, we found no processes in place to monitor access on a regular basis. No security logs or unauthorized access reports are generated or reviewed on a regular basis. For SAP/IFMS, a review of locked accounts is performed once a week to determine whether locking was due to three unsuccessful login attempts or due to user inactivity.

We found instances, as noted above, of inactive accounts, accounts belonging to former employees, generic accounts and duplicate accounts. Furthermore, there was limited guidance available to ASCs to determine the access levels on a "need-to-know" or "least privilege" basis, and therefore limited information to facilitate monitoring and to control access.

Recommendation 7

SIMB, in conjunction with Finance and HR where appropriate, should ensure that formal procedures to review unauthorized system access for all IT systems are implemented.

Management Response

SIMB presently uses the TBS Incident Management Plan procedure to review and report unauthorized system access for all IT systems. SIMB will document this procedure for internal use. The target date is Q4 2012–2013.

3.2.2 People

We expected to find that CIC provided employees and managers with the necessary training, tools, resources and information to support the discharge of their responsibilities for system access control.

The ACU of the Information Technology Services Directorate of SIMB administers access to the legacy systems (FOSS, NCMS, CSQ and CPIC) within the scope of this audit, as well as GCMS. ASCs are representatives of each office or branch and are responsible for coordinating between the branch and the ACU regarding access to systems.

We found that guidance on the roles of the ASCs and ACU is available and that ACU has documented standard operating procedures. However, there is no direction provided to ASCs regarding least-privilege and need-to-know access.

With respect to SAP/IFMS and PeopleSoft HRMS, super users receive on-the-job training. In the regional offices, super users can unlock user accounts and change passwords. However, they do not receive formal training.

Recommendation 8

SIMB should provide guidance to access security coordinators to enable them to perform their roles in managing system access, particularly with respect to assigning the appropriate level of access for a specific user’s needs based on the user’s position and responsibilities.

Management Response

SIMB will update and provide existing documented guidance to access security coordinators. It currently has a dedicated electronic mailbox in place for answering questions. The target date is Q2 2012–2013.

Appendix A: Detailed Criteria for the Audit

Appendix B: Management Action Plan

Appendix C: Audit Time Line