SAP - Audit Findings

Canadian International Development Agency200 Promenade du PortageGatineau, QuebecK1A 0G4Tel: (819) 997-5006Toll free: 1-800-230-6349Fax: (819) 953-6088(For the hearing and speech impaired only (TDD/TTY): (819) 953-5023Toll free for the hearing and speech impaired only: 1-800-331-5018)E-mail: [email protected]

Audit Report

CIDA SAP Security

April 2003

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


CIDA SAP Security i

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 ii

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 end-user 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 1

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-under-

development 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 2

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. Only authorized users have access to the system. 2. Users have access only to what is required to perform their job functions. 3. Conflicting, excessive or unusual access privileges for employees, even if authorized. 4. Access to sensitive data (e.g., personal, salary, and contract). 5. Access privileges assigned to contracted staff (e.g., to sensitive data). 6. Monitoring of user profiles, users, and use. 7. 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 3

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 firm’s 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 4

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 ID’s 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).

1 The asterick (*) in SAP means that all functions available can be performed by the same individual.


CIDA SAP Security 5

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 ID’s 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 6

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 holder’s 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 7

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 8

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 Branch’s IMO. The effect of this action provided a consultant the right to authorize access to SAP for other consultants.


CIDA SAP Security 9

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 10

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 Agency’s 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



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



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.

Perf

orm

ance

Rev

iew

Bra

nch

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

C

IDA

SAP

Secu

rity

Appe

ndix

I - 1

Sum

mar

y of

Aud

it R

ecom

men

datio

ns 2

002

– C

IDA

SA

P Se

curi

ty

Pr

ojec

t N

umbe

r of

R

ecom

men

datio

ns

Com

plet

ed

Ong

oing

CID

A S

AP

Secu

rity

12

Reco

mm

enda

tions

Re

spon

sibili

ty

Man

agem

ent's

Re

spon

ses

Dat

e St

atus

5.2.

1 C

reat

e an

d ap

prov

e a

form

al se

greg

atio

n of

dut

ies

mat

rix fo

r eac

h of

the

AIS

fu

nctio

nal t

eam

s as w

ell a

s fo

r CID

A m

anag

emen

t. T

he

mat

rices

shou

ld se

rve

as a

gu

idel

ine

for t

he S

ecur

ity

Adm

inis

tratio

n pr

oces

s for

al

l bra

nche

s, in

that

it w

ill

iden

tify

unac

cept

able

co

mbi

natio

ns o

f acc

ess r

ight

s th

at sh

ould

not

be

assi

gned

to

geth

er u

nles

s miti

gatin

g co

ntro

ls e

xist

Dire

ctor

Gen

eral

, In

form

atio

n Te

chno

logy

D

ivis

ion.

Agr

eed.

Und

er th

e au

spic

es

of th

e Se

curit

y an

d A

utho

rizat

ion

Rev

iew

Pr

ojec

t, w

ork

has b

egun

on

impl

emen

ting

the

segr

egat

ion

of d

utie

s in

auth

oriz

atio

n pr

ofile

s, w

ith th

e pr

inci

ples

re

pres

entin

g ea

ch S

AP

func

tiona

l mod

ule.

As

auth

oriz

atio

n pr

ofile

s/ac

tivity

gr

oups

are

refin

ed to

refle

ct

the

segr

egat

ion

of d

utie

s by

each

func

tiona

l mod

ule,

a

new

segr

egat

ion

of d

utie

s m

atrix

will

be

docu

men

ted.

Th

is w

ork

is sl

ated

for

com

plet

ion

by th

e en

d of

M

arch

200

3.

Mar

ch/0

3 U

nder

way

.

Perf

orm

ance

Rev

iew

Bra

nch

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

C

IDA

SAP

Secu

rity

Appe

ndix

I - 2

Reco

mm

enda

tions

Re

spon

sibili

ty

Man

agem

ent's

Re

spon

ses

Dat

e St

atus

5.2.

2 G

rant

use

rs a

cces

s onl

y to

the

spec

ific

func

tions

that

ar

e re

quire

d as

par

t of t

heir

daily

job

func

tions

. A

re

view

of i

ndiv

idua

l job

fu

nctio

ns sh

ould

be

unde

rtake

n fo

r tho

se w

ith

acce

ss to

SA

P pr

ofile

s, w

ith

a vi

ew to

rest

rictin

g ac

cess

rig

hts t

o a

mor

e ap

prop

riate

le

vel

Dire

ctor

Gen

eral

, In

form

atio

n Te

chno

logy

D

ivis

ion.

Agr

eed.

Fin

ance

Mod

ule,

Pr

ojec

t Sys

tem

Mod

ule

and

Hum

an R

esou

rces

Mod

ule

Act

ivity

Gro

ups /

pro

files

w

ere

agre

ed a

nd si

gned

-off

by

the

Func

tiona

l Tea

m

Lead

ers.

The

Mat

eria

l M

anag

emen

t Act

ivity

G

roup

s wer

e co

mpl

eted

by

the

end

of S

epte

mbe

r 200

2.

The

man

agem

ent p

roce

ss h

as

been

form

aliz

ed w

here

by a

ll m

eetin

gs, s

ign-

off

agre

emen

ts, m

inut

es o

f m

eetin

gs, m

odifi

catio

ns o

f SA

P ac

cess

, are

reco

rded

.

Sept

.16/

02

Com

plet

ed.

5.2.

3 R

evie

w a

ll ac

cess

and

au

thor

izat

ion

to th

e sy

stem

to

ensu

re th

at th

ey a

re in

co

mpl

ianc

e w

ith th

e Pr

ivac

y Ac

t. Th

e co

mpl

ianc

e pr

oces

s, in

add

ition

to th

e re

stric

tion

of a

cces

s to

sens

itive

in

form

atio

n, sh

ould

be

appr

oved

and

doc

umen

ted

in

orde

r to

prov

ide

a cl

ear a

nd

conc

ise

unde

rsta

ndin

g an

d co

mpl

ianc

e w

ith th

e Ac

t.

Any

pla

nned

dev

iatio

n fr

om

this

doc

umen

t sho

uld

be

sub j

ect t

o a

revi

ew a

nd

Dire

ctor

Gen

eral

, In

form

atio

n Te

chno

logy

D

ivis

ion.

Agr

eed.

The

SA

P Se

curit

y an

d A

utho

rizat

ions

Uni

t m

onito

rs w

ith th

e H

uman

R

esou

rces

Fun

ctio

nal T

eam

Le

ad to

ens

ure

that

all

acce

ss

is in

com

plia

nce

with

the

Priv

acy

Act o

n an

ong

oing

ba

sis.

May

/02

Com

plet

ed.

Mon

itorin

g on

goin

g.

Perf

orm

ance

Rev

iew

Bra

nch

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

C

IDA

SAP

Secu

rity

Appe

ndix

I - 3

Reco

mm

enda

tions

Re

spon

sibili

ty

Man

agem

ent's

Re

spon

ses

Dat

e St

atus

appr

oval

by

the

appr

opria

te

leve

l of m

anag

emen

t 5.

2.4

Lock

all

inac

tive

acco

unts

and

rem

ove

thei

r pr

ofile

s/ac

tivity

gro

ups.

Dire

ctor

Gen

eral

, In

form

atio

n Te

chno

logy

D

ivis

ion.

Agr

eed.

All

acco

unts

that

are

no

long

er re

quire

d ar

e lo

cked

an

d pr

ofile

/act

ivity

gro

ups

are

rem

oved

. Th

is is

bei

ng

done

on

an o

ngoi

ng b

asis

.

Aug

ust/0

1 C

ompl

eted

.

5.2.

5 D

evel

op fo

rmal

pr

oced

ures

for m

onito

ring

the

stat

us o

f use

r acc

ount

s an

d as

sign

the

resp

onsi

bilit

y fo

r per

form

ing

thes

e du

ties t

o a

spec

ific

grou

p/in

divi

dual

.

Dire

ctor

Gen

eral

, In

form

atio

n Te

chno

logy

D

ivis

ion.

Agr

eed.

Thi

s has

bee

n co

mpl

eted

. Si

nce

July

200

1 fo

rmal

pro

cedu

res a

re in

pl

ace,

resp

onsi

bilit

y ha

s bee

n as

sign

ed a

nd m

onito

ring

occu

rs o

n a

mon

thly

bas

is.

July

/01

Com

plet

ed.

5.2.

6 R

emov

e th

e ab

ility

to

mak

e m

odifi

catio

n to

end

-us

er a

ccou

nts f

rom

all

user

s ou

tsid

e of

the

Secu

rity

&

Aut

horiz

atio

ns G

roup

, IM

TB.

Dire

ctor

Gen

eral

, In

form

atio

n Te

chno

logy

D

ivis

ion.

Agr

eed.

Thi

s has

bee

n co

mpl

eted

. A

s of J

une

2001

, on

ly th

e SA

P Se

curit

y an

d A

utho

rizat

ion

Uni

t has

the

auth

ority

to c

reat

e, m

odify

or

dele

te S

AP

user

acc

ount

s.

The

case

cite

d in

the

repo

rt w

as a

one

tim

e ex

cept

ion

June

/01

C

ompl

eted

.

5.3.

1 Li

mit

the

use

of

impe

rmis

sibl

e pa

ssw

ords

by

incl

udin

g th

e sy

mbo

l “*”

at

the

begi

nnin

g an

d en

d of

ea

ch g

uess

able

pas

swor

d in

or

der t

o pr

even

t any

text

be

ing

used

bef

ore

and

afte

r th

e gu

essa

ble

pass

wor

d.

Add

ition

al e

ntrie

s tha

t ma y

Dire

ctor

Gen

eral

, In

form

atio

n Te

chno

logy

D

ivis

ion.

Agr

eed.

Thi

s has

bee

n co

mpl

eted

as o

f Jul

y 20

01.

Inte

rnal

pro

cess

es w

ere

impl

emen

ted

1 M

ay, 2

002.

May

/02

Com

plet

ed.

Perf

orm

ance

Rev

iew

Bra

nch

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

C

IDA

SAP

Secu

rity

Appe

ndix

I - 4

Reco

mm

enda

tions

Re

spon

sibili

ty

Man

agem

ent's

Re

spon

ses

Dat

e St

atus

be c

omm

only

use

d, su

ch a

s 12

3* o

r AB

C*,

shou

ld a

lso

be in

clud

ed in

the

impe

rmis

sibl

e pa

ssw

ord

tabl

e.

5.3.

2 R

emov

e te

st a

ccou

nts

from

the

Prod

uctio

n en

viro

nmen

t of S

AP.

The

us

e of

test

acc

ount

s may

re

sult

in a

ccou

ntab

ility

is

sues

, as n

oted

abo

ve, i

f tes

t ac

coun

ts a

re n

ot sp

ecifi

cally

as

sign

ed to

use

rs.

Test

ing

proc

edur

es sh

ould

be

carr

ied

out i

n ei

ther

the

Dev

elop

men

t or Q

ualit

y A

ssur

ance

env

ironm

ent

Dire

ctor

Gen

eral

, In

form

atio

n Te

chno

logy

D

ivis

ion.

Agr

eed.

The

test

acc

ount

s ci

ted

wer

e a

one-

time

exce

ptio

n an

d w

ere

rem

oved

. Te

stin

g is

car

ried

out i

n th

e Te

st e

nviro

nmen

t und

er

stan

dard

acc

ess p

rofil

e co

ntro

ls.

This

ens

ures

that

th

e in

tegr

ity o

f the

act

ual

Prod

uctio

n da

taba

se is

not

co

mpr

omis

ed.

July

/01

Com

plet

ed.

5.3.

3 En

sure

onl

y ap

prop

riate

C

IDA

em

ploy

ees a

utho

rize

requ

ests

for a

cces

s to

the

SAP

syst

em

Dire

ctor

Gen

eral

, In

form

atio

n Te

chno

logy

D

ivis

ion.

Agr

eed.

Thi

s has

bee

n co

mpl

eted

. C

ontro

ls w

ere

in

plac

e ef

fect

ive

June

200

2.

July

200

2 C

ompl

eted

Perf

orm

ance

Rev

iew

Bra

nch

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

C

IDA

SAP

Secu

rity

Appe

ndix

I - 5

Reco

mm

enda

tions

Re

spon

sibili

ty

Man

agem

ent's

Re

spon

ses

Dat

e St

atus

5.4.

1 In

clud

e m

onito

ring

proc

edur

es in

the

Age

ncy’

s St

anda

rd S

ecur

ity P

roce

dure

s G

uide

; pro

vide

wee

kly,

m

onth

ly a

nd q

uarte

rly

mon

itorin

g ac

tiviti

es, a

s ap

prop

riate

; and

repo

rt th

e re

sults

of p

erio

dic

mon

itorin

g ac

tiviti

es to

CID

A

man

agem

ent f

or a

ctio

n, a

s ap

prop

riate

Dire

ctor

Gen

eral

, In

form

atio

n Te

chno

logy

D

ivis

ion.

Agr

eed.

The

SA

P sy

stem

is

curr

ently

not

con

figur

ed to

ca

ptur

e us

er u

sage

in

form

atio

n fo

r a ti

me

perio

d lo

nger

than

one

day

. Due

to

tech

nica

l diff

icul

ty a

nd

reso

urce

s tha

t wou

ld b

e in

volv

ed in

add

ress

ing

this

m

atte

r, it

is p

refe

rabl

e to

aw

ait t

he c

ompl

etio

n of

the

pend

ing

upgr

ade

to S

AP

ver.

4.6,

whe

re u

ser l

ogs m

ay b

e re

tain

ed fo

r a lo

nger

per

iod.

To B

e

Det

erm

ined

C

omm

ence

men

t of t

he

actio

n pl

an a

wai

ting

com

plet

ion

of th

e up

grad

e to

SA

P ve

r. 4.

6, in

Feb

ruar

y 20

03.

5.5.

1 C

ompl

ete,

app

rove

and

di

strib

ute

AIS

Sec

urity

Po

licie

s and

Pro

cedu

res t

o cl

early

def

ine

the

proc

ess a

nd

resp

onsi

bilit

ies o

f gra

ntin

g ac

cess

to A

IS in

secu

rity

polic

ies a

nd p

roce

dure

s do

cum

enta

tion,

incl

udin

g th

e re

quire

men

t to

keep

all

such

do

cum

enta

tion

curr

ent a

nd a

m

onito

ring

regi

me

requ

ired

to e

nsur

e co

mpl

ianc

e to

this

po

licy.

Dire

ctor

Gen

eral

, In

form

atio

n Te

chno

logy

D

ivis

ion.

Agr

eed.

The

SA

P A

cces

s Po

licy

is c

ompl

ete

and

awai

ting

form

al a

ppro

val i

n N

ovem

ber 2

002.

In

terim

pr

oced

ures

are

in p

lace

and

ar

e be

ing

adm

inis

tere

d by

IM

TB.

Nov

./02

Form

al a

ppro

val

pend

ing.

Perf

orm

ance

Rev

iew

Bra

nch

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

____

C

IDA

SAP

Secu

rity

Appe

ndix

I - 6

Reco

mm

enda

tions

Re

spon

sibili

ty

Man

agem

ent's

Re

spon

ses

Dat

e St

atus

5.5.

2 Id

entif

y an

d fo

rmal

ly

upda

te d

ocum

enta

tion

rela

ted

to c

hang

es to

AIS

pr

ofile

s/ac

tivity

gro

ups i

n or

der t

o re

flect

all

chan

ges i

n th

e sy

stem

.

Dire

ctor

Gen

eral

, In

form

atio

n Te

chno

logy

D

ivis

ion.

Agr

eed.

All

chan

ges o

r re

visi

ons t

o us

er p

rofil

es /

activ

ity g

roup

s are

do

cum

ente

d in

the

appr

opria

te S

ervi

ce R

eque

sts

Dat

abas

e. T

he S

ervi

ce

Req

uest

is th

e m

etho

dolo

gy

used

to im

plem

ent c

hang

es to

th

e SA

P ap

plic

atio

n in

clud

ing

auth

oriz

atio

ns.

Th

is p

roce

ss h

as b

een

in

plac

e si

nce

Aug

ust 1

999.

All

min

or a

djus

tmen

ts to

use

r pr

ofile

s are

now

kep

t on

file

by th

e A

IS S

ecur

ity a

nd

Aut

horiz

atio

ns G

roup

.

Aug

./01

Com

plet

ed.

SAP - Audit Findings

Documents

Transcript of SAP - Audit Findings