Audit Report CIDA SAP Security

April 2003

Canadian International Development Agency 200 Promenade du Portage Gatineau, Quebec K1A 0G4 Tel: (819) 997-5006 Toll free: 1-800-230-6349 Fax: (819) 953-6088 (For the hearing and speech impaired only (TDD/TTY): (819) 953-5023 Toll free for the hearing and speech impaired only: 1-800-331-5018) E-mail: info@acdi-cida.gc.ca

Performance Review Branch

TABLE OF CONTENTS

Executive Summary ........................................................................................................................ i 1. Background ............................................................................................................................... 1 2. Audit Objectives ....................................................................................................................... 1 3. Audit Scope............................................................................................................................... 2 4. Audit Approach......................................................................................................................... 2 5. Findings..................................................................................................................................... 3 6. Conclusions............................................................................................................................. 11 Appendix I Summary of Audit Recommendations ................................................................. I-1

Performance Review Branch Executive Summary Foreword: The audit report is being issued approximately eighteen months following completion of the conduct or testing phase of the audit. The report timing serves two purposes, as follows: The reporting process is simplified by issuing one SAP security report to address only pertinent findings from audit assessments of SAP development over an extended period. It is a generally recognized industry-wide best practice to audit large system development projects in three distinct phases, namely: a Pre-Implementation Audit before system design begins, an implementation or System-Under-Development (SUD) audit, and a Post-Implementation Audit (i.e., normally conducted 6-12 mo.s following system rollout). PRB applied this standard and, as a result, a comprehensive SUD security review of SAP was performed in early 1999, an SUD security review of the HR Module of SAP was conducted prior to its phased implementation beginning in October 2000, and the post-implementation audit was conducted in June 2001. The integration of SAP development and iterative solutions to audit findings, however, produced a complex chain of action plan items that were often overlapping and sometimes redundant. Outdated action plans are eliminated. Several findings and corrective actions from the previous SAP security assessments have been surpassed by changes in system functionality, new security accountabilities and new control processes resulting from the ongoing and integrated nature of SAP development.

This report reflects the audit findings as of July 2001. As reported by management, the current status of the 12 action plans, is as follows: 9 are completed, 1 have formal approval pending, and 2 are underway. As a result of the action plans being completed over a two-year period, and because the action plans include the implementation of security policy and related practices, a follow-up security audit of SAP is to be scheduled for fiscal 2004-05. A post-implementation audit of Systems Applications and Products in Data Processing (SAP) R/3 security in the Agency Information System (AIS) of CIDA was performed in July 2001 in accordance with the 2001-02 Internal Audit plan. The audit was performed in order to determine whether an appropriate and effective framework governing security access had been designed, implemented and was being maintained. The audit addressed logical or software security for all AIS modules and components of the SAP system in operation. The audit of SAP security focused on logical security and, specifically, the assignment of system access profiles/activity groups to Agency users. The purpose of assessing system profiles/activity groups was to ensure that the access privileges granted to users are consistent with job roles that have been assigned to users in their daily work. Audit activity carried out included the review of policies and procedures supporting the security function, the design and assignment of SAP R/3 security activity groups, and selected testing. Policies and procedures supporting the security function and the design and assignment of SAP R/3 security activity groups provide the framework for the design, maintenance and testing of activity groups, as well as the granting of access rights to end-users. A review of documentation CIDA SAP Security i

Performance Review Branch relating to security monitoring policies and procedures, design documentation, configuration strategies, interpretations of the Privacy Act and interpretations of other statutory requirements covering the privacy of personal information was also performed. Finally, the security approach adopted by CIDA for SAP was compared to generally recognized industry best practices. A summary of the key findings is as follows: Logical Access Security: The audit found that an adequate control framework did not exist for processes affecting SAP security and maintenance. While access was generally granted to AIS users based on business needs and was assigned consistently with documented activity groups, several notable exceptions persist which impacts on the integrity of the existing security processes. For example, a formal segregation of duties matrix should be approved and assessed against SAP profiles, and only the SAP Security & Authorization Group should have the ability to create, modify and delete SAP user accounts. Management has reported having taken action on these and other logical access security issues. User Related Risk: An adequate control framework exists for mitigating the inherent risk of enduser activity in the SAP system, however, further work is recommended to strengthen the existing control framework. For example, only appropriate CIDA employees should authorize requests for access to the SAP system. Management has reported having taken action on this and other user related risks. Security Monitoring and Reporting: The control framework for monitoring and reporting of security risks on an ongoing basis was found to be insufficient to meet security and management needs. Work related to strengthening this area of control should include a process, that is documented and formally approved, for ongoing monitoring and reporting of security risks and incidents. Management has reported having taken action on security monitoring and reporting. Formal Access Security Policy and Procedures: An AIS security policy was developed in draft form at the time of the audit, however, the policy was not in the process of being approved by management or distributed to key stakeholders. Formal AIS security policy and procedures will help to ensure that AIS access is granted consistently throughout the Agency and that all responsibilities for granting access are clearly defined and assigned to the appropriate individuals. Management has reported having taken action on security policy and procedures. In conclusion, to be efficiently and effectively protected from unauthorized access or unintended processing, AIS security must be planned, managed and monitored in a thorough manner. While some pieces of the security framework were in place as of July 2001, and while effort has been invested to resolve security issues arising from this audit and from previous security reviews, ongoing work continues to be needed in the policy, planning, monitoring and reporting areas of SAP security. A number of recommendations have been made to address security access in these areas. Management has reported that corrective actions have either been taken or are underway.

CIDA SAP Security

ii

Performance Review Branch

Audit of SAP Security

1. Background CIDA implemented the enterprise software package Systems Applications and Products in Data Processing/SAP R/3 release 4.0B in June 1999. SAP was implemented by CIDA in order to comply with the Financial Information Strategy and to provide CIDA with an enterprise system that was Year 2000/Y2K compliant. The SAP implementation included the following modules: Financial Accounting/FI, Controlling/CO, Funds Management/FM, Material Management/MM, Project System? PS and, to a lesser extent, Sales and Distribution/SD. In the fall of 2000, CIDA implemented the Human Resource/HR Module of SAP. All modules in the Production environment were within the scope of this engagement. In accordance with the generally recognized industry-wide best practice of auditing SAP systems while they are being designed/configured, the following system-under-development reviews were performed at CIDA: In March 1999, a comprehensive system-under-development security review of SAP was undertaken. The purpose of the review was to determine whether an effective management control framework for security, including adequate and appropriate profile assignments, had been developed and whether appropriate security attributes had been incorporated into the configuration of the application security regime. An overview of findings from this review is reported in Section 5.1 of this audit report. In August 2000, with follow-up work in September and October 2000, a system-underdevelopment review of the HR Module of SAP was conducted prior to its phased implementation beginning in October 2000. The objective of the SAP R/3 HR security review was also to determine whether an effective management control framework for security, including adequate and appropriate profile assignments, had been developed and whether appropriate security attributes had been incorporated into the system. The findings from that review were added to the scope of this post-implementation security audit. In July 2001, a post-implementation audit was conducted, as follows:

2. Audit Objectives The overall objective of the audit was to determine whether an appropriate and effective control framework governing access privileges to the Agency Information System (AIS) had been designed, implemented and maintained. The four objectives of the audit were as follows:

CIDA SAP Security

Performance Review Branch 2.1 To determine if access granted to AIS users was based on documented business need and was consistent with delegation of authority documentation and assigned profiles. 2.2 To determine if a control framework was in place to identify, monitor, record, report and mitigate user-related security risks. 2.3 To determine if a management control framework was in place for the identification, assessment and reporting of access security incidents and risks in and around AIS. 2.4 To determine if security policies and procedures were in place to ensure that access to AIS was granted consistently throughout the Agency and that all responsibilities for granting access were clearly defined and assigned to the appropriate individuals. 3. Audit Scope The audit addressed logical security for all AIS modules and components in production. The Travel component of the Human Resource/HR Module of AIS was also to be included in the audit, unless the extent of development of the HR Module proved insufficient for audit purposes. The scope of the audit addressed key risk areas associated with logical access security for newly implemented enterprise systems. Risk areas for AIS security included the following: 1. 2. 3. 4. 5. 6. 7. Only authorized users have access to the system. Users have access only to what is required to perform their job functions. Conflicting, excessive or unusual access privileges for employees, even if authorized. Access to sensitive data (e.g., personal, salary, and contract). Access privileges assigned to contracted staff (e.g., to sensitive data). Monitoring of user profiles, users, and use. Adequate polices and procedures governing access control.

Audit fieldwork began on June 28, 2001. The findings identified in this audit report are valid as of July 25, 2001. 4. Audit Approach Rationale Auditing SAP security normally focuses on the assignment of system generated profiles for organization users. The purpose of assessing the assignment of profiles is to ensure that the system accesses granted by authorizations are consistent with job roles that have been assigned. Consequently, it is also important to ensure that the basic rationale for the design of authorizations is sound and appropriate documentation is available to describe the intent of job roles and profiles.

CIDA SAP Security

Performance Review Branch Audit Methodology The audit was conducted applying a SAP specific methodology by certified information systems auditors of a large accounting firm who conduct similar audits for other clients. Within this standard methodology, a detailed audit program was adapted in order to ensure that CIDA objectives and risks were addressed. Audit criteria and procedures were determined for each audit objective. Testing of SAP data required the use of the accounting firms proprietary software, due to the complexity involved in accessing and analyzing SAP data. The general approach consisted of interviews with appropriate individuals determined jointly with CIDA, a review and analysis of existing security access profile documentation, policies and procedures for approving access, monitoring and reporting security risks, and control of user related security. Further, a detailed review of the security configuration and user assignments was conducted in the production environment. Some of testing performed included matching of system profiles to CIDA design documents and system change requests, matching of user authorizations to sensitive data, interrogation of changes made to sensitive master records, testing of access privileges granted to security staff, and a segregation of duties analysis including testing of incompatible functions assigned to system users. Specific items considered relevant include the authorization reporting tree, security reports available within SAP/AIS, and the system audit side of the Audit Information System utility within SAP. In addition, end-user transaction assignments from AIS was compared to a segregation of duties matrix established by experts from the consulting firm. Audit Assurance As the audit tests were applied using proprietary software of the consulting firm, the ability of CIDA to replicate the audit test would be contingent upon re-engaging the consulting firm. Further, as the AIS databases and programs in operation at the time of audit testing were not copied and stored, due to the prohibitive cost to undertake such a task, the results of the audit tests can not be repeated. While Internal Audit is confident in the reliability of the results of audit testing performed, in that the risk of an inappropriate conclusion is low, assurance regarding these test results cannot not be provided, as replication of the test results would be prohibitive on a cost/effectiveness basis. 5. Findings 5.1 Follow-up of Previous Review Findings This audit confirmed that as of July 13, 2001, while efforts have been made within CIDA to resolve findings from a previous SAP pre-implementation security review performed in May 1999, and a review of SAP security for the Human Resource Module performed in October 2000, recommendations raised from these reviews have not been fully resolved.

CIDA SAP Security

Performance Review Branch The purpose of this section of the report is to highlight the progress in addressing previous security assessments. Unresolved issues are further addressed, in greater detail, in Sections 5.2 through 5.5 of this report. Prior to the initial AIS "Go-Live" date, a comprehensive pre-implementation security review of SAP was performed. The purpose of the review was to determine whether an effective management control framework for security, including adequate and appropriate profile assignments, had been developed and whether appropriate security attributes had been incorporated into the configuration of the application security regime. The areas covered by this pre-Go-Live security review included application security, as well as both physical and logical security considerations relating to the supporting technology infrastructure. Specifically included in the review were the Unix Operating System (a mainframe equivalent local area network) , the Oracle 8 database, Windows NT, the Local Area Network environment and the policies and procedures supporting the security function. The findings on application security included: i) undocumented security decisions, ii) no sign-off on security, iii) an incomplete conflict matrix, iv) lack of system support profiles, and v) the use of the (*) value in profiles1. The findings on the security of infrastructure components included: i) SAP back-up servers are at the same site as the main server, ii) no formal security policies for end-users, iii) lack of accountability for the use of the ROOT access account, iv) weak control over access to the data centre, and v) weak authentication and monitoring procedures. Significant improvements relating to the resolution of previous review findings were identified in July 2001, including the following: Knowledge of the Security Administrator function has been acquired by the assigned CIDA employees; Computer security policy has been developed, but is not yet approved; Business process owner approval for security changes has been implemented; and The number of users with access to the SAP security profile SAP_ALL, a profile that provides access to all functions in the SAP application, has been significantly reduced. However, some user accounts still have this access that continues to pose a limited risk to CIDA.

The following findings from previous reviews remain unresolved: Some segregation of duty conflicts exist within the AIS Functional Teams system access (see audit finding 5.2); Use of generic user IDs and test accounts in the Production environment continue (see audit finding 5.3); Lack of a formal security strategy and documented naming conventions continue (see audit finding 5.5); and Access in the AIS Production environment is authorized by other than the Security Administrators (see audit finding 5.5).
The asterick (*) in SAP means that all functions available can be performed by the same individual.

CIDA SAP Security

Performance Review Branch

5.2 Logical Access Security The audit found that an adequate control framework did not exist for processes affecting SAP security and maintenance. While access was generally granted to AIS users based on business needs and was assigned consistently with documented activity groups, several notable exceptions persist which impacts on the integrity of the existing security processes. For example, a formal segregation of duties matrix should be approved and assessed against SAP profiles, and only the SAP Security & Authorization Group should have the ability to create, modify and delete SAP user accounts. Management has reported having taken action on these and other logical access security issues. Work related to the improving logical access security in the Production environment should include the following measures: Removal of generic user IDs and test accounts from the Production environment, in order to lower the risk of unauthorized access; Strengthening the controls over SAP delivered user accounts; Modification of user access to ensure proper segregation of duties; Restriction on the access of developers and consultants in the Production environment; Reviewing access rights that generally grant excessive access to users; Improvement in the documentation for SAP security access approval; Ensuring that only SAP security administrators can grant access to the SAP system; and Ensuring that temporary employees and consultants do not have the ability to grant users access to the system.

A segregation of duties risk is defined as any combination of the following tasks; custody, recording, and reconciliation of assets. As a result, segregation of duties conflicts arises with the assignment of incompatible access rights that can lead to misappropriation of assets or errors. We noted that several high-risk segregation of duties conflicts existed in the Production environment. We also noted that several users were assigned a combination of activity groups/profiles (bundles of SAP functionality) that grant broad functional access to incompatible transactions, unless the attributes of these transactions are controlled at a lower level (i.e., the ability to add, change, delete or simply to view data). SAP user accounts that have segregation of functional duty conflicts increase the risk of accidental or intentional unauthorized activities and may result in exposures to CIDA for user access that may be contrary to the Financial Administration Act or other government regulation. In addition, CIDA has not developed a matrix of incompatible functions (i.e., transactions). However, CIDA does have the common knowledge to restrict those activities that would cause a segregation of duties risk. Further, SAP Security & Authorizations Group was, at this time of the audit, in the process of performing an internal review of all existing profiles to ensure that segregation of duties risks are minimized. The AIS/SAP Functional Team Leads were involved in this review process.

CIDA SAP Security

Performance Review Branch

We noted that 18 users in the Production environment had access to SAP profiles that provide broad access, including full functional access. Wide-open functional access leaves the system unrestricted to those users with this access. This could lead to accidental or intentional corruption of financial and transactional data. At the time of the audit, the SAP Security & Authorizations Group was working to reduce the number of users with unnecessarily broad access. During our review of end-user access assignments, a SAP profile/activity group was specifically developed to provide access to all Human Resource (HR) information. This profile was designed to allow HR consultants the right to access only the HR data required by them to perform their HR duties (i.e., using display access). Only CIDA employees can change HR data in the Production environment. HR information by nature is very sensitive and availability to individual users without proper approval, authorization and documentation may be in conflict with the Privacy Act. Consequently, periodic monitoring is required to ensure access to and use of HR transactions and data has been properly approved, authorized, documented and applied. It was noted during the assessment of end user accounts in the production environment that only 5 SAP user accounts were assigned to the Inactive User Group, although there are several hundred inactive accounts in the production environment. User Groups are used in SAP to segregate various classes or types of users in the system. One such application at CIDA, as outlined in the operating procedures, is to assign all inactive user accounts to a separate user group to facilitate the identification and ultimate deletion of these accounts. It was noted during the review of the status of users accounts in production that there were 281 unlocked user accounts with activity groups/profiles assigned that were not used in the past three months. Inactive accounts should be checked with the account holders supervisor, on a periodic basis, to ensure the need for these accounts remains valid. During the assessment of access changes in the Production environment, it was noted that on a number of occasions (267 times) between November 1, 2000 and July 1, 2001 one member of the CIDA Technical Team who was not part of the Security & Authorizations Group (i.e., who did not have the authority to make security changes) made changes to SAP end user accounts. Assigning user profiles without appropriate approval and training could jeopardize the integrity of the system and compromise the confidentiality of information captured within the system. Of these 267 instances, 177 security changes were a series of one-time authorized fixes made by a programmer in June 2001. The remaining 90 changes were made by a senior consultant to meet development deadlines, production deadlines, or on an emergency basis. Recommendations It is recommended that the Director General, Information Technology Division, ensure action is taken to strengthen logical access security, as follows: 5.2.1 Create and approve a formal segregation of duties matrix for each of the AIS functional teams as well as for CIDA management. The matrices should serve as a guideline for the Security Administration process for all branches, in that it will identify unacceptable

CIDA SAP Security

Performance Review Branch combinations of access rights that should not be assigned together unless mitigating controls exist. Management Response Agreed. Under the auspices of the Security and Authorization Review Project, work has begun on implementing the segregation of duties in authorization profiles, with the principles representing each SAP functional module. As authorization profiles/activity groups are refined to reflect the segregation of duties by each functional module, a new segregation of duties matrix will be documented. This work is slated for completion by the end of March 2003. 5.2.2 Grant users access only to the specific functions that are required as part of their daily job functions. A review of individual job functions should be undertaken for those with access to SAP profiles, with a view to restricting access rights to a more appropriate level. Management Response Agreed. Finance Module, Project System Module and HR Module Activity Groups/profiles were agreed and signed off by the Functional Team Leaders. The Material Management Activity Groups were completed by the end of September 2002. The management process has been formalized whereby all meetings, sign-off agreements, minutes of meetings, modifications of SAP access, are recorded. 5.2.3 Review all access and authorization to the system to ensure that they are in compliance with the Privacy Act. The compliance process, in addition to the restriction of access to sensitive information, should be approved and documented in order to provide a clear and concise understanding and compliance with the Act. Any planned deviation from this document should be subject to a review and approval by the appropriate level of management.
Management Response

Agreed. The SAP Security and Authorizations Unit monitors with the Human Resources Functional Team Lead to ensure that all access is in compliance with the Privacy Act on an ongoing basis. 5.2.4 Lock all inactive accounts and remove their profiles/activity groups. Management Response Agreed. All accounts that are no longer required are locked and profile/activity groups are removed. This is being done on an ongoing basis. 5.2.5 Develop formal procedures for monitoring the status of user accounts and assign the responsibility for performing these duties to a specific group/individual.

CIDA SAP Security

Performance Review Branch Management Response Agreed. This has been completed. Since July 2001 formal procedures are in place, responsibility has been assigned and monitoring occurs on a monthly basis. 5.2.6 Remove the ability to make modification to end-user accounts from all users outside of the Security & Authorizations Group, IMTB. Management Response Agreed. This has been completed. As of June 2001, only the SAP Security and Authorization Unit has the authority to create, modify or delete SAP user accounts. The case cited in the report was a one time exception. 5.3 User Related Risk An adequate control framework exists for mitigating the inherent risk of end-user activity in the SAP system. Further work is recommended, however, to strengthen the existing control framework. For example, only appropriate CIDA employees should authorize requests for access to the SAP system. Management has reported having taken action on this and other user related risks. During the review of the standard SAP table that provides a list of passwords that are deemed impermissible by CIDA, we noted that the table has been populated since the last audit in October 2000 HR pre-implementation review. We further noted, however, that the inclusion of additional entries in this table would increase the strength of passwords controls. Creating a table of impermissible passwords ensures that users do not use passwords that are easily guessable or commonly used. During the assessment of end-user accounts, it was noted that there were numerous generic accounts and test accounts identified in the production environment. Generic user accounts are SAP accounts that are not created specifically for a particular user and are often shared among various users. Test user account creation is normally reserved for the Development and Quality Assurance environments only. The presence of generic user accounts and test user accounts in the Production environment is a security risk, as changes to data or programs cannot be traced back to the people who made them. During the review of the access approval process, it was noted that in at least one instance an Information Management Officer (IMO), who is responsible for granting users access to SAP, was not a CIDA employee. In this particular instance, a CIDA Vice-President authorized a consultant to fill the role as that Branchs IMO. The effect of this action provided a consultant the right to authorize access to SAP for other consultants.

CIDA SAP Security

Performance Review Branch

Recommendations It is recommended that the Director General, Information Technology Division, ensure action is taken to strengthen the end-user component of the management control framework for AIS security, as follows: 5.3.1 Limit the use of impermissible passwords by including the symbol * at the beginning and end of each guessable password in order to prevent any text being used before and after the guessable password. Additional entries that may be commonly used, such as 123* or ABC*, should also be included in the impermissible password table. Management Response Agreed. This has been completed as of July 2001. Internal processes were implemented 1 May, 2002. 5.3.2 Remove test accounts from the Production environment of SAP. The use of test accounts may result in accountability issues, as noted above, if test accounts are not specifically assigned to users. Testing procedures should be carried out in either the Development or Quality Assurance environment. Management Response Agreed. The test accounts cited were a one time exception and were removed. Testing is carried out in the Test environment under standard access profile controls. This ensures that the integrity of the actual Production database is not compromised. 5.3.3 Ensure only appropriate CIDA employees authorize requests for access to the SAP system. Management Response Agreed. This has been completed. Controls were in place effective June 2002. 5.4 Security Monitoring and Reporting The control framework for monitoring and reporting of security risks on an ongoing basis was was found to be insufficient to meet security and management needs. Work related to strengthening this area of control should include development of a formal process for ongoing monitoring and reporting of security risks and incidents. Management has reported having taken action on security monitoring and reporting. It was noted during the assessment of policies and procedures that there were no formally documented security monitoring procedures performed on a regular basis by the Security & Authorizations Group, IMTB. The Security & Authorizations Group, however, has been

CIDA SAP Security

Performance Review Branch performing limited security monitoring on an informal basis, such as asking Branches to verify the status of SAP users inactive in the system for three months or more. A lack of proper monitoring controls may lead to an inability to detect or prevent intentional or accidental corruption of financial, human resource or program data. Recommendations It is recommended that the Director General, Information Technology Division, ensure action is taken to develop and implement formal security monitoring procedures for AIS, as follows: 5.4.1 Include monitoring procedures in the Agencys Standard Security Procedures Guide; provide weekly, monthly and quarterly monitoring activities, as appropriate; and report the results of periodic monitoring activities to CIDA management for action, as appropriate. Management Response Agreed. The SAP system is currently not configured to capture user usage information for a time period longer than one day. Due to technical difficulty and resources that would be involved in addressing this matter, it is preferable to await the completion of the pending upgrade to SAP ver. 4.6, where user logs may be retained for a longer period. 5.5 Formal Access Security Policy and Procedures An AIS security policy was developed in draft form at the time of the audit, however, the policy was not in the process of being approved by management or distributed to key stakeholders. Formal AIS security policy and procedures will help to ensure that AIS access is granted consistently throughout the Agency and that all responsibilities for granting access are clearly defined and assigned to the appropriate individuals. Management has reported having taken action on security policy and procedures. During the assessment of security documentation, it was noted that no formally approved standard or policy exists for the naming convention of SAP profile/activity groups. Although a naming convention was adopted during the SAP implementation process, no documented evidence of proper approval was available to indicate its meaning or scope. Lack of formally approved naming conventions related to user and system profiles/activity groups increase the risk of inadvertent assignment of access rights. Our audit work included, on a sample basis, comparison of the CIDA profile/activity group design documentation to the actual configuration set-up in the SAP R/3 Production environment. The test was to determine if security design documentation is up-to-date and if changes have been properly approved. It was noted that changes to the Human Resource (HR) security profiles/activity groups were not always properly approved or documented prior to the implementation of the HR Module. As a result, in several cases the documented design did not agree to the SAP configuration at that time. Since HR implementation, however, the formal System Request (SR) process has documented all HR profile/activity group changes, and the

CIDA SAP Security

10

Performance Review Branch design and approval of these changes can be reviewed and explained on a change-by-change basis. Further, our testing indicated that from a sample of 21 Network Access (request) Forms issued by IMOs to the Security & Authorizations Group, IMTB, 24% of the access requests did not agree to the access that had been given to the user in SAP. The Network Access Form had not always been updated by the IMO as the process required. Recommendations It is recommended that the Director General, Information Technology Division, ensure action is taken to strengthen security policies and procedures for AIS, as follows: 5.5.1 Complete, approve and distribute AIS Security Policies and Procedures to clearly define the process and responsibilities of granting access to AIS in security policies and procedures documentation, including the requirement to keep all such documentation current and a monitoring regime required to ensure compliance to this policy. Management Response Agreed. The SAP Access Policy is complete and awaiting formal approval in November 2002. Interim procedures are in place and are being administered by IMTB. 5.5.2 Identify and formally update documentation related to changes to AIS profiles/activity groups in order to reflect all changes in the system. Management Response Agreed. All changes or revisions to user profiles / activity groups are documented in the appropriate Service Requests Database. The Service Request is the methodology used to implement changes to the SAP application including authorizations. This process has been in place since August 1999. All minor adjustments to user profiles are now kept on file by the AIS Security and Authorizations Group. 6. Conclusion SAP is generally recognized, by clients and implementers alike, to be a complex system to configure, implement and secure. To be efficiently and effectively protected from unauthorized access or unintended processing, AIS security must be planned, managed and monitored in a thorough manner. The audit confirmed that as of July 2001 a comprehensive control framework is not yet in place for processes affecting AIS security and maintenance. While some pieces of the security framework are in place, and while effort has been invested to resolve security issues arising from this audit and from previous security reviews, ongoing work continues to be needed in the

CIDA SAP Security

11

Performance Review Branch policy, planning, monitoring and reporting areas of AIS security. A number of recommendations have been made to address security access in these areas. Management has reported that corrective actions have either been taken or are underway.

CIDA SAP Security

12

Performance Review Branch

Summary of Audit Recommendations 2002 CIDA SAP Security

Project Completed Ongoing

CIDA SAP Security

Number of Recommendations 12

Recommendations
Director General, Information Technology Division. Agreed. Under the auspices of the Security and Authorization Review Project, work has begun on implementing the segregation of duties in authorization profiles, with the principles representing each SAP functional module. As authorization profiles/activity groups are refined to reflect the segregation of duties by each functional module, a new segregation of duties matrix will be documented. This work is slated for completion by the end of March 2003. March/03

Responsibility

Management's Responses

Date

Status
Underway.

5.2.1 Create and approve a formal segregation of duties matrix for each of the AIS functional teams as well as for CIDA management. The matrices should serve as a guideline for the Security Administration process for all branches, in that it will identify unacceptable combinations of access rights that should not be assigned together unless mitigating controls exist

____________________________________________________________________________________________________________ CIDA SAP Security Appendix I - 1

Performance Review Branch

Recommendations
Director General, Information Technology Division. Sept.16/02 Completed.

Responsibility

Management's Responses

Date

Status

5.2.2 Grant users access only to the specific functions that are required as part of their daily job functions. A review of individual job functions should be undertaken for those with access to SAP profiles, with a view to restricting access rights to a more appropriate level

5.2.3 Review all access and Director General, authorization to the system to Information Technology ensure that they are in Division. compliance with the Privacy Act. The compliance process, in addition to the restriction of access to sensitive information, should be approved and documented in order to provide a clear and concise understanding and compliance with the Act. Any planned deviation from this document should be subject to a review and

Agreed. Finance Module, Project System Module and Human Resources Module Activity Groups / profiles were agreed and signed-off by the Functional Team Leaders. The Material Management Activity Groups were completed by the end of September 2002. The management process has been formalized whereby all meetings, sign-off agreements, minutes of meetings, modifications of SAP access, are recorded. Agreed. The SAP Security and Authorizations Unit monitors with the Human Resources Functional Team Lead to ensure that all access is in compliance with the Privacy Act on an ongoing basis. May/02

Completed. Monitoring ongoing.

____________________________________________________________________________________________________________ CIDA SAP Security Appendix I - 2

Performance Review Branch

Recommendations

Responsibility

Management's Responses
August/01 Completed.

Date

Status

approval by the appropriate level of management 5.2.4 Lock all inactive accounts and remove their profiles/activity groups. Director General, Information Technology Division. July/01 Agreed. All accounts that are no longer required are locked and profile/activity groups are removed. This is being done on an ongoing basis. Agreed. This has been completed. Since July 2001 formal procedures are in place, responsibility has been assigned and monitoring occurs on a monthly basis. June/01 Completed.

5.2.5 Develop formal Director General, procedures for monitoring Information Technology the status of user accounts Division. and assign the responsibility for performing these duties to a specific group/individual. Director General, Information Technology Division.

5.2.6 Remove the ability to make modification to enduser accounts from all users outside of the Security & Authorizations Group, IMTB. Director General, Information Technology Division.

Completed.

5.3.1 Limit the use of impermissible passwords by including the symbol * at the beginning and end of each guessable password in order to prevent any text being used before and after the guessable password. Additional entries that may

Agreed. This has been completed. As of June 2001, only the SAP Security and Authorization Unit has the authority to create, modify or delete SAP user accounts. The case cited in the report was a one time exception Agreed. This has been completed as of July 2001. Internal processes were implemented 1 May, 2002.

May/02

Completed.

____________________________________________________________________________________________________________ CIDA SAP Security Appendix I - 3

Performance Review Branch

Recommendations

Responsibility

Management's Responses

Date

Status

Director General, Information Technology Division. July/01

Agreed. The test accounts cited were a one-time exception and were removed. Testing is carried out in the Test environment under standard access profile controls. This ensures that the integrity of the actual Production database is not compromised. Agreed. This has been completed. Controls were in place effective June 2002. July 2002

Completed.

be commonly used, such as 123* or ABC*, should also be included in the impermissible password table. 5.3.2 Remove test accounts from the Production environment of SAP. The use of test accounts may result in accountability issues, as noted above, if test accounts are not specifically assigned to users. Testing procedures should be carried out in either the Development or Quality Assurance environment 5.3.3 Ensure only appropriate CIDA employees authorize requests for access to the SAP system Director General, Information Technology Division. Completed

____________________________________________________________________________________________________________ CIDA SAP Security Appendix I - 4

Performance Review Branch

Recommendations
Agreed. The SAP system is currently not configured to capture user usage information for a time period longer than one day. Due to technical difficulty and resources that would be involved in addressing this matter, it is preferable to await the completion of the pending upgrade to SAP ver. 4.6, where user logs may be retained for a longer period. Agreed. The SAP Access Policy is complete and awaiting formal approval in November 2002. Interim procedures are in place and are being administered by IMTB. Nov./02 To Be Commencement of the Determined action plan awaiting completion of the upgrade to SAP ver. 4.6, in February 2003.

Responsibility

Management's Responses

Date

Status

5.4.1 Include monitoring Director General, procedures in the Agencys Information Technology Standard Security Procedures Division. Guide; provide weekly, monthly and quarterly monitoring activities, as appropriate; and report the results of periodic monitoring activities to CIDA management for action, as appropriate

5.5.1 Complete, approve and Director General, distribute AIS Security Information Technology Policies and Procedures to Division. clearly define the process and responsibilities of granting access to AIS in security policies and procedures documentation, including the requirement to keep all such documentation current and a monitoring regime required to ensure compliance to this policy.

Formal approval pending.

____________________________________________________________________________________________________________ CIDA SAP Security Appendix I - 5

Performance Review Branch

Recommendations
Agreed. All changes or revisions to user profiles / activity groups are documented in the appropriate Service Requests Database. The Service Request is the methodology used to implement changes to the SAP application including authorizations. This process has been in place since August 1999. All minor adjustments to user profiles are now kept on file by the AIS Security and Authorizations Group. Aug./01 Completed.

Responsibility

Management's Responses

Date

Status

5.5.2 Identify and formally Director General, update documentation related Information Technology to changes to AIS Division. profiles/activity groups in order to reflect all changes in the system.

____________________________________________________________________________________________________________ CIDA SAP Security Appendix I - 6