Audit Serve, Inc.

The Worldwide Connection for Audit, Security, Control and SOX Professionals

Software Management Control Requirements

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

                                                             

Low Cost & Highly Skilled 
IT Audit and SOX Consulting Resources Available Immediately
Call Mitch Levine at (203) 972-3567 or 
email levinemh@auditserve.com for additional information

INTRODUCTION

Traditionally, a review of software management entailed a security review of the libraries used in the change management process. This article is intended to focus on the other critical components that need to be reviewed to ensure the integrity of software being developed. The controls that are discussed attempt to distinguish between a manual process and an automated process provided by software management systems. An analysis of the controls provided by specific software management products is discussed in the next article. Although this article is written with a bias towards software management controls required in an IBM MVS environment, you should be able to apply most of the controls to any operating system that you are responsible for reviewing.

SOURCE MANAGEMENT

The management of source modules (e.g., source code, JCL, procedures, and a copybook member) is the most critical component of any software management process. The first step in responding to a software change request is for the programmer to retrieve the current version of the source module that is required to be changed.

Before the existence of software management systems, programmers required read access to the library containing the production source modules which allowed them to make as many copies of the module as they desired.

There are two concerns when having an open environment for retrieving source code. A programmer could potentially overlay the changes of another programmer when they are both changing the same module to resolve two separate software requests. The other concern is that a programmer might use the module in their personal library to address a future software request which is not the current production version.

The conflicts over the use of the same module to address two separate software requests needs to be coordinated by the development manager. An upfront analysis is required to identify source modules that need to be changed for a particular request. When possible, multiple software change requests that use the same source module, should be assigned to one programmer.

Conflicts over the use of the same module to address two separate software requests is referred to as "parallel development". Parallel development also exists in environments where installations apply new releases of a third party vendor software which conflict with inhouse customized modules.

Regardless of the type of parallel development that occurs, a process needs to be in place to analyze differences between two modules and incorporates the changes of both versions into one combined version (i.e., retrofit changes). A source management system can be used to maintain a permanent record of the lines of code that came from a particular version. The tools that are used to identify the changes in a module cannot be dependent on comparing changes based on line numbers since a deletion or addition of a line from one of the two modules being compared will disrupt the compare process and erroneously identify changes that never occurred. In addition, the compare function must be able to compare modules that have variable record lengths that exceed 80 character formats (e.g., control cards).

The software management system provides the automated control which restricts the use of a specific module to one programmer at a time. This is accomplished through a checkout process in which the software management system tracks the status of source modules that are currently being worked on. In addition, the programmer that checked out the source module is required to return (i.e., checkin) the source module to the source controlling library before another programmer can use it. When a software management system is used for this purpose, the individual programmer that checks out the code does not require any access to the source controlling library since the access is granted to the software management system.

A manual process, which is less efficient, requires a module assignment log which tracks the programmer currently using a particular source module. The programmer's development libraries should be periodically checked to verify that they only have a copy of the source module that they have been assigned.

Many installations feel that these source management controls are too restrictive which would result in slower development and inconvenience to programmers who need to view modules for reference purposes. A compromise could consist of allowing all programmers to make copies of source modules while tracking the programmer assigned to the current production version, and only allowing that programmer to return the module for promotion to production.

Another component of source management is the deletion of obsolete modules. When the source module is returned to the source holding library, the module that resides in the programmers library should be automatically deleted to prevent its accidental use in the future. However, this control can easily circumvented by renaming the module or copying the module to another library which is not be monitored by the source management system. Many source management systems attach identifiers to the modules under its control to negate this weakness.

CHANGE MIGRATION

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

When promoting a program change to production, the person responsible for migrating the change traditionally required update access to the library where changes are being migrated and read access to the libraries where modules are copied from. The audit trails provided by the external security anagers (e.g.,RACF, Top Secret, and ACF2) will identify the library that was updated. However, the actual modules that were changed will not be identified unless a member level security system (e.g., PDSMAN) is used. Based on the sensitivity of the promotion process the dependency on a detective control is inadequate. Therefore, a preventive control, containing a secured predefined path from which all changes are migrated, is required.

The use of a software management system, would no longer require the person responsible for the migration to have any access to the libraries used in the change promotion path through their personal ID. Consequently, the migration would not have the ability to edit a module within a library used in the promotion process. In addition, the software management system should provide the ability to migrate changes from libraries that are only part of the promotion path. This control would prevent unauthorized changes from occurring by migrating changes from unsecured libraries.

Another critical component of the change migration process is the recompilation of source code during the migration process. This recompilation is required to ensure that the source/load relation is maintained. Prior to the use of software management sy stems, a manual process was used whereby a person compiled a source module with the correct compile options and specified the load library to store the executable version. This process would enable a person to insert unauthorized modules with no accountability for their actions. Software management systems provide the ability to convert source into an executable format using standard source translators (i.e., pre-compilers, compilers, assemblers, linkage editors) which are predefined in installation defined JCL and is selected based on the classification of the source code. The end result is an automated control which prevents unauthorized changes and erroneous translation of source code to its executable form.

Since programs are required to pass through several libraries during the promotion process, it is not cost effective to recompile the source as it is migrated to each library. However, a mechanism must be in place to ensure the integrity of the source/lo ad relation. Typically, software management systems insert identifiers into the CSECTs created during compilation and insert identifiers into the source directories to maintain the source/load integrity. A reconcilement would need to be performed during each step of the migration whenever a recompile is not performed to prevent a module from being migrated to production whenever the source/load version is not the same. The source/load reconcilement which checks internal references within the code also prevents modules that were altered outside of the software management system's control from being migrated to production.

When a program abend occurs, which necessitates the program to be changed and resubmitted, existing software management controls need to be bypassed. However, since this program change is an unapproved version and may only be a temporary fix, it is not a divisible to migrate the module to production. Therefore, a mechanism need to be available to allow the program to be executed without having it migrated to production. One method, is to alter the production JCL to execute the program from a non-production load library. Another approach includes: front-ending the production load libraries or JCL libraries with emergency libraries whereby the emergency libraries are searched for a specific load module or JCL member before searching the production libraries.

Another alternative for handling program abends is to restore the previous load version. The software management system must provide a complete version back-up for all load modules. Having a complete version of source (i.e., full copies maintained or consolidating delta/base), would not be sufficient for restoring previous versions since the entire application system would need to be compiled and link-edited.

In order to restore the previous version of a load module, a method needs to be in place to track its location. A manual process of storing previous version of load modules in separate libraries can used, however, the software management system should have the capability to automatically track the levels of a load module.

CONFIGURATION MANAGEMENT

With the abundance of code that is being written, there is a natural duplication of work which has brought about the sharing of code between various modules. The sharing of code necessitated the need for an automated management system that tracks the modules that are dependent on common code (i.e., COBOL copybooks, assembler macros, called subroutines).

The following are some examples of uses of common code:

Working Storage section within Cobol programs
Terminal Control Table (TCT) within CICS

If a change is made to a common member, a process is required to propagate these changes to their dependent modules which would require each of modules to be recompiled. Therefore, a software management system needs to provide a mechanism to identify all of the modules that are utilizing a common member and prevent changes from being migrated to production unless the modules which utilize these members are analyzed to determine if they need to be recompiled. The key to being able to track modules that are dependent on common code requires the software management system to capture these dependent relations as part of the source translation procedure. This initial step of building these tables of module dependencies would enable a software management system to identify the modules that would potentially need to be recompiled whenever a change is made to the common code.

In the event that it is decided not to apply a newly changed common member after its dependent modules have been recompiled, an automated a control must be in place to ensure that the newly compiled modules are not used. A detective control to identify this occurrence is not adequate enough to prevent this potential disaster. A control which prevents the migration of these newly compiled modules must be implemented.

INVENTORY MANAGEMENT

Other critical modules require version and inventory management besides program source code, which includes: load modules, JCL, procedures, common code, parameter files/tables and control cards. Inventory management controls are needed to ensure that modules are migrated to libraries based on their module type. In addition, the compare utility facility provided by software management systems require the tracking of module types in order to derive record lengths (i.e., column width) of the modules that t hey compare.

Another area in which modules need to be classified is to distinguish between application types. Instead of relying on a standard naming convention for libraries, the software management system can provide the user an automated means of identifying the libraries that are used by a particular application. This process would also ensure that modules are only migrated to the appropriate library based on the application type.

At times it is required to use a previous version of a source module. In environments where source management systems are not available, the previous version of a source module was stored in different libraries or archived to tape which required the installations to manually track the location of the module's levels. However, this method would not provide an automated process for determining the module's version differences.

Source management systems typically uses base/delta technology to track, store, and retrieve previous versions of a source module. Base/delta technology stores the original source in its complete form and compares updated versions to identify the change s made and establishes a change level (i.e., delta level) to reflect the changes. Each delta level represents the changed lines and eliminates the need for storing complete source modules to reflect each version. The reverse delta approach, which is use d by some source management systems, maintains a complete version of the current source module in its original form and captures deltas to reflect the prior versions. Tracking changes by using deltas also provides a mechanism for attaching information (e.g ., programmer that made the change, change request, reason, date/time of the change) about the change for each level.

SECURITY AND INTERFACES WITH EXTERNAL SECURITY SYSTEMS

The controls that are provided by the software management system is based on the ability to restrict access to individuals based on their job function. The access can be granted through defining security within the software management system or by the software management system providing an interface to the external security system where entitlements are defined.

When using a software management system the person should not be provided access to libraries used in promoting a change to production which would allow them to make unauthorized changes outside the control of the software management system. Therefore, the software management system must be provided exclusive access to the libraries used in the migration process. A user can then be granted access to the libraries through the software management system either though internal security tables defined within the software management system or by defining access entitlements within the external security system. If a security interface is used, the software management system would then perform a security call to the external security system to determine whether the individual has access to the specific function requested. Since, the software management system does not have the ability to define specific resource definitions that is unique to its environment, it must use the predefined resource definitions that the external security system provides. However, the software management system must perform the task of interpreting the resource definitions defined on the external security system to the related function that is performed on its system.

CONCLUSION

During the course of this article, many alternative methods were identified for controlling software management. In order to implement these controls, the philosophy that was previously used for software management requires significant change. The implementation of a software management system is not the entire solution but a set of tools that can be integrated within an entire software management process. It is important to understand the controls offered by each software management product, which is discussed in the next article.

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

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

This article appeared in a past issue of the Audit Vision E-Mail Newsletter.

Technical Articles | Conferences | Audit Programs | Audit Serve Seminars | Consulting Services | Audit Vision Newsletter | What's New | Contact US

This website has been optimized for Netscape and Internet Explorer 4.0 and above.  Your comments and suggestions are always welcome, please email webmaster@auditserve.com.
Copyright © 2000  All rights reserved.  27 Pine Street, Suite 700, New Canaan, CT 06840 USA.