AS/400 Change Management Approaches

By: Mitchell H. Levine, CISA
Audit Serve, Inc.

 

Introduction

The focus of this article is to discuss the various methods used within an AS/400 environment which provide software management and more specifically, as it pertains to the migration of program changes through the various libraries used within a change control environment (i.e., change migration process).

Traditional Program Migration Controls

Typically, the libraries that a program change passes through during its migration (i.e., promotion) to the production environment consists of: programmers development libraries, holding libraries, testing libraries, and production libraries.

When promoting a program change to production, the user usually requires update access to the library where the changes are being migrated to and read access to the libraries where modules are copied from. A necessary control when update access is required to migrate changes through the libraries used in the change migration process is a segregation of duties between the programmer who makes the change and the person responsible for migrating the change. However, when using the security provided by AS/400, the only audit trail provided is the date/time of the last change at an object level but not the person who last changed the module.

Alternative Approach Using AS/400 ADOPT Program Facility

The control weakness illustrated in the previous change migration process is such that the person migrating the program changes requires update access to the libraries used in the promotion path through their personal ID. Consequently, the migrator would have the ability to edit the module being migrated or migrate an unauthorized version of the program from an unsecured library.

The AS/400 operating system provides the ADOPT program facility which enables a program to execute under the authority of the owner of the object who has access rights to the libraries used in the change migration process instead of the person executing the program. In order to establish a program with adopted authority, the program must be created or changed to run with adopted rights. This is done with the USRPRF(*OWNER) parameter using the CHGPGM command and program compile commands. Adopted programs that are defined on the system can be identified using the Display Program Adopt command, DSPPGMADP USRPRF(), which shows all programs that use the authority of the specified user profile.

The program ADOPT facility could be used by an installation for the purposes of writing one’s own program which would migrate a program to specific libraries used in the change migration process without assigning the migrator update access to the libraries. This program can be further enhanced to ensure that programs are copied from specific controlled libraries and that an audit trail of the modules that are actually migrated is generated. This ensures that all programs that are migrated are appropriate. Finally, the program should be written to recompile the programs to ensure that source load integrity is maintained. The ADOPT program must be written to provide user prompts for the module to be migrated and the libraries to migrate to and from.

Audit Program For Change Migration Using The Adopt Facility

1) Ensure that the adopted program is contained in a library that restricts all users from having update access. However, if the program is changed by an unprivileged user, the adopted authority of the owner is removed.

2) Ensure that only the individuals responsible for performing the migration are allowed to execute the program.

3) Ensure that the adopted program is written to force the modules to be migrated from pre-specified libraries that are secured from unauthorized updates.

4) Ensure that the adopted program is written to create an audit trail of all modules that are migrated and a independent review process is in place to ensure that all programs that are migrated are appropriate.

5) Ensure that the adopt programs have the proper error recovery functions coded to automatically sign off the user of the adopt program if it should abend (i.e., abnormal termination). Otherwise, the person executing the program would have the access abilities of the owner of the adopt program. This recovery function is performed by having the program monitor for abend messages.


This article was written more than one year ago. 
Events may have changed since this article was written.

 


For a free proposal to perform an audit of your organization or provide SOX support & testing services, contact Mitchell Levine of Audit Serve at (203) 972-3567 or via e-mail at Levinemh@auditserve.com.

Copyright  2006, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.

AuditNet - The Global Resource for Auditors

Free
Audit Vision
Newsletter

Since 1991
Join 3,500 other subscribers

General Data Protection Regulation Seminar

Copyright © 2015. All Rights Reserved.