Software Change Migration
(OS/390 RACF specific but can be used across all platforms)

Control Point Ref #: chmgraab

Programmers have separate development libraries which are secured
from unauthorized updates

Audit Steps
-----------
1) Determine if separate development libraries have been
established for programmers.

1.1) Ask management if programmers are assigned their own
development library or if a common development library
shared by all programmers used.

1.2) On a sample basis, identify programmers IDs and determine
the datasets that multiple programmers have access to.
Based on these datasets, determine whether any of the
datasets have source members.

Note:
This method does not necessarily guaranty that the identified
datasets are being used for the purpose of a shared development
environment.

2) If programmers are assigned separate development libraries,
determine if update access to the library is restricted from
all individuals.
 

F1 - Info Screen Ref # chmgraab
Background
----------
There should be no reason for any person even the
programmer'smanager to have update access to the programmer's
development library since READ access allows modules to be
copied. PROCS areone exception to the rule where common
libraries are requiredsince all PROC libraries must be defined in
the JES2 concatenation and for performances purposes you cannot
have a PROC library defined for each individual programmer.

Audit Step Info
---------------
Identifying the programmer's development libraries is an
important part of the compliance test that is discussed in this
control point. Instead of asking the program manager for the
names of the libraries, another method is to identify all of the
programmer's TSO IDs by using the TSO 3.4 option, enter the TSO
ID in the DSNAME field (DSNAME==> <TSOid>) and leave the option
field blank. This step will identify all of the dataset names
associated with the TSOids high level prefix. Since all users
are granted update access to their TSOids high level prefix,
these are the libraries where the programmer can define their own
personal development libraries in addition to any specific
development libraries that the programmer has been assigned.

Since common libraries there are shared by programmers in most
cases would not be a dataset with their own high level prefix,
the only way to systematically identify these common libraries is
to review all of the datasets that a programmer has update access
to determine whether there are program modules present.

It should be noted that a programmer would have more than one
development library since source, JCL, and load modules are
required to be in separate libraries.

Control Point Ref #: chmgraac

Controls are in place which identifies whether an unauthorized
change is made during the program change migration process to
production

Audit Steps
-----------
1) Identify the libraries used in the migration process to
production (e.g., programmers library - staging libraries -
Acceptance Test environment - Production).

2) Ensure that all changes that are migrated through the
change migration process are authorized.

2.1) Determine whether management identifies the modules that are
required to be changed to meet the requirements of a
software request at the onset of the project.

2.2) Ensure that there is an automated audit trail (e.g., member
level security product) which identifies the modules that
have been migrated through the various libraries of the
program migration process to ensure that unauthorized
changes were not made.

2.3) Ensure that there is a audit trail which identifies modules
that are not migrated from the libraries in the migration
process.

2.4) Determine if there an audit trail which identifies whether a
module has been edited in place within the libraries used in
the change migration process.

2.5) Ensure that there is a review process in place which
identifies whether unauthorized updates have been made based
on the detective controls previously described.

3) Ensure that approvals are obtained to support the migration
of modules to the acceptance and production environments.

3.1) Determine whether there is a process in place for management
to approve the migration of modules to the acceptance test
and production environments.

3.2) Select a sample of projects and ensure that approvals were
obtained for the migration of modules to the acceptance test
and production environments.

3.3) Review the module assignment log or other methods that are
used to identify the modules that are required to be changed
to meet the requirements of the request and compare the
modules listed to the modules that were approved to be moved
to the acceptance test and production environments.

F1 - Info Screen Ref # chmgraac
Background
----------
The libraries used within the change migration process consists
of all the stages that a program goes through from the point that
the programmer completes their coding and declares the programs
associated with a project ready for the Testing Phase to the
program's ultimate migration to the production libraries.

In previous steps we required a control in place to track the
modules that were being checked out to ensure that it is
associated with a particular project. In many development shops
this control is not complied with to the point where the manager
is making an analysis of the modules that are required to be
changed based on the project.

Regardless if the control is being complied with, the list in
many cases does not include newly created modules that were
required to be developed which need to authorized by management
in addition to the changed modules that the manager previously
authorized. Therefore, a final evaluation is performed prior to
the module's migration to testing and production libraries to
ensure that all the modules being migrated were as required by
the specifications of the project.

Within your environment where there is no automated change
management package or internally development change management
software which migrates modules without the migrator requiring
update access to the library. The process for migrating changes
using a manual process can consist of the following:

o ISPF/TSO panels which prompt the user for the member to
copy, from which library to obtain the module, and the
library to copy the module

o IBM IEBCOPY utility which copies modules to the appropriate
library

o CLISTs which can be coded in a manner to semi-automate the
change management process whereby performing the move to the
appropriate library. However, since the migrator of a
change requires update access to the library where the
migration occurs, unauthorized changes can still be made.

When using a manual process, there would be no system provided
audit trail which identifies when the program migration actual
occurred. Therefore, a method would be required to identify when
the libraries used in the change migration process were updated.
The external security systems (i.e., ACF2, RACF, Top Secret) can
only be set to identify changes at a library level which provides
no control since there can be hundreds a modules in a library.

Other methods used for identifying updates at a module level
include:

TSO STATS

TSO statistics identifies the date/time of the last time the
module was saved and the person who saved it. However, if the
user who last saved the module did not have TSO STATS enabled
there would be no audit trail of the date/time of the last save
and the person who saved it. In addition, the date/time can be
changed by all users that have update access to the library.

Member level security system

Member level security and control products (e.g., Goal System's
PDSMAN and Action Software's Change Action products) have the
ability to log and restrict access to individual members in a
library or all of the modules within a library.

Based on not using an automated change migration product it is
very unlikely that your installation has the ability to identify
whenever a module is migrated from a library which is not part of
the change migration path. This control is of great importance
since the person who is responsible for performing the migrations
would have the ability to use their own coded modules that is
copied from their personal library. This control weakness can be
resolved in part if the migrator's ID is not granted update
access to any libraries except the libraries used in the change
migration process. In addition, controls which ensure that only
authorized code is being migrated (i.e., source code review) and
controls which identify any changes to a module while it is being
migrated (i.e., load module size compare if modules are
recompiled when it is migrated) can provide compensating
controls. These controls are discussed in other control points.
In addition, if member level security product is used, reports
can be generated which identifies the modules within a library
that has been updated and identifies the library where the module
was copied from.

Another critical control that needs to be in place is to identify
whenever updates are directly made to the modules within the
libraries used in the change migration process. The control is
required since the migrator of changes to the libraries used in
the change migration process would have update access to all
libraries. Therefore, they can directly edit a module. There
should never be a case where the migrator needs to directly edit
the module. Based on the change control process that is being
used, no method would be available to distinguish between a
library that has been updated based on a copy/move which is an
authorized action and a library's module that has been edited
(i.e., update in place) which is an unauthorized action. Some
member level security products (e.g., Goal System's PDSMAN) can
distinguish between an update based on a copy and an update in
place.

Audit Step Info
---------------
The approval process that is discussed is limited to the
migrations to the Acceptance Test and production environments
since these are the two points in the SDLC process where the
integrity of the change must be preserved. However, your
installation may choose to require an approval for module
migrations in the early stages of the change migration process.

The compliance test associated with ensuring that all modules
that are migrated to the acceptance and production environments
includes the verification that the approval represents their
concurrence that the modules being migrated were those that
needed to be changed to meet the request. If the module
assignment log does not identify modules that are changed in
relation to a project, then this test cannot be performed.

Control Point Ref #: chmgraad

All libraries used in the change migration process are restricted
to those individuals responsible for migrating changes

Audit Steps
-----------
1) Identify the libraries used in the migration process to
production after it is migrated from the programmer's
development library (e.g., staging libraries - Acceptance
Test environment - Production).

2) Ensure that only the individuals responsible for performing
the program migrations have update access to the libraries
used in the change migration process.
F1 - Info Screen Ref # chmgraad
Background
----------
In previous control points a review was performed to determine
whether audit trails were available to identify unauthorized
changes during a program's migration through libraries used in
the change migration process. This control point addresses the
control of ensuring that only those individuals responsible a
program's migration have update access to the libraries used in
the migration process.

Since an automated migration product is not in place which allows
migrations to occur without the person themselves's having update
access, these users that are responsible for this function are
required to have read, update, and delete access to the modules
within a library.

Audit Step Info
---------------
Audit Steps are not provided to ensure that there is segregation
of duties between the individual performing the program change
and the person performing the migration since if sufficient audit
trails are in place as discussed in the previous control point
there is no significant exposure.

Another critical control over the migrator's function is
restricting their ability to update modules within the
programmers library. This control is required since in most
cases the audit trails discussed in the previous control point
would not include the monitoring of changes to the programmer's
library. However, steps are not provided to address this control
since there is a separate control point devoted to ensuring that
only the programmer themselves have update access to their own
development libraries.

Control Point Ref #: chmgraae

All module types are included in the change management process

Audit Steps
-----------
1) Ensure that all of the following types of modules go through
the formal change migration process:

o source code
o JCL
o procedures (PROCS)
o control cards
o copybooks (copy members)

1.1) Identify the libraries that are used in the change migration
process and ensure that a library is specified for each of
the described module types.
F1 - Info Screen Ref # chmgraae
Background
----------
A. Source Modules

Source modules are the programs that are high level languages
(COBOL, Fortran, C, Basic, PL1), low level languages (assembler)
or 4th Generation Languages.

B. JCL

In most installation Procedures (PROCS) are used to run the
applications. JCL is used to execute PROCS which run the
application.

C. Procedures (PROCS)

PROCS are JCL members that are used to run the batch
applications.


D. Control Cards

Control Cards are used for specifying sort routines, VOLSERS,
dates but also can be used as data input based on the
requirements of the application.

E. Copybooks

Copybooks is a common member that is used by programs instead of
having to include the code directly in the program.

Audit Steps Info
----------------
Other modules that are used in a program's development should
also be included in the change management process but are not
specifically mentioned which includes data base changes (e.g.,
data dictionary). CICS module changes are reviewed as part of
the CICS Transaction Processing Main Section.

Control Point Ref #: chmgraaf

A process is in place to ensure that the source and load
integrity is maintained during the module's migration to
production

Audit Steps
-----------
1) Determine the various libraries that source is migrated to
during the change migration process (e.g. programming to
test, test to production).

2) Identify the stages which the change migration process where
the module is recompiled and if there are stages in the
migration path that the load version is copied directly.

3) If load is directly copied to the next stage in the change
migration process, determine the process that is used to
ensure that source and its load version remain in synch:

o using the time/date stamps as a means of ensuring that the
sources time/date does not exceed the time/date of the link
edited version

o load module size compare between the load module size from
the libraries used in the prior stage of the change
migration process

4) Ensure that there is a review process in place to compare
the load module size at each stage of the change migration
process to ensure that the source and load are not changed.

Note:
This compare is still required even if the module is recompiled
through all stages of the change migration process.
F1 - Info Screen Ref # chmgraaf
Background
----------
Ensuring that load module and source module are kept in synch
(i.e., load derived from source) is a critical component of
software integrity. The most full proof method to ensure that
source and load remain in synch is to recompile the code as the
modules are migrated through the change migration process.
However, since you are not using a change migration package which
enables the migrator not to have update access to the libraries
used in the change migration process, a load module size compare
is the only method available to ensure that the source or load
module was not changed as a module was migrated through the
change management process.

There may be instances where a module is not recompiled as it is
moved through the change migration process. One instance may be
the case where a load version is not required to be present
because the stage of the migration process is only a holding
library. There are two stages in the change migration process
where source and load both must be present. That is during
acceptance testing and the move to production. There also may be
cases where migration consist of moving the source and load
independently without recompiling due to the amount of time
required to perform a recompile.

Audit Step Info
---------------
Using Time/Date stamps of the last save date of the source module
and the link edit date of the load module is not an accurate
method for determining whether a source module was changed after
the fact. If TSO STATS is used as the mechanism for deriving
this information, anyone having update access to the library
where the module is contained can alter the time/date. In
addition, the person performing the migration can turn off TSO
STATS within their logonid which would eliminate the time/date
stamp recording.

The load module size compare to the load module size of a
previous stage in the migration process is not a fullproof method
either since a programmer can make an equal number of addition
and deletion or a few changes to code that would not change the
load module size. In addition, unless the same compilers are
used and the same compile/link options are specified through all
stages of the change migration, the load module size could differ
although the module itself was not changed.

It should be noted that source load integrity only appliesto
source and copybook module types.

Control Point Ref #: chmgraag

All modules associated with a request are migrated together
through the change migration process

Audit Steps
-----------
Compare a list of modules (i.e., programs, JCL, PROCS, control
cards, copybooks) that were identified as being required to be
changed to meet the request to the forms that support a project's
migration to the acceptance test and production environments and
ensure that no modules were added or missing.


F1 - Info Screen Ref # chmgraag
Background
----------
All modules that were required to be changed to meet the
requirements of a request should be moved together as they go
through the change migration process. This is required
especially when the modules are migrated to the test environment
in order to ensure that all modules were tested. In addition,
all modules should be migrated together when they are put into
production to ensure that all required changes take effect at the
same time.

Control Point Ref #: chmgraah

A code review is performed for modules that are migrated to
production to identify unauthorized changes

Audit Steps
-----------
1) Ensure that a process is in place to perform a code review
for all module types (source, JCL, PROCS, control cards) to
identify unauthorized changes. Refer to the F1 - INFO for
specific items that should reviewed based on the module
type.

2) Ensure that the method used for identifying changes to
existing program identifies all of the changes

2.1) Based on the method used to identify changes to a module,
ensure it will work under the following conditions:

o adding a line of code

o Resequencing of the lines of code

4) Ensure that the code review is performed according to sample
criteria established by your company.

5) Ensure that there is a segregation of duties between the
individual who developed the code and the person who reviews
the code.
F1 - Info Screen Ref # chmgraah
Background
----------
Code review of modules being migrated to production is the only
fool-proof method for determining whether unauthorized changes
have been made. However, based on the time required to perform a
code review, many installation may feel that this is a
non-essential function. The basis for requiring a code review
should be according to the risk level of an application. If an
individual cannot embezzle money from a system through an
unauthorized program change then the only exposure is malicious
code to disrupt system processing.

Some installations feel that a complete code review, especially
for new modules that are developed which contain thousands of
lines of code, is not practical and therefore perform this review
on a sample basis.

Code reviews are not only performed to ensure that no
unauthorized code is present but to ensure that structured coding
techniques are used and to appraise the quality of the
programmer's work.

The integrity of the code review is important. There are many
methods used to identify changes in a module which is referred to
as source to source compares. Some of the old comparison
utilities were based on line number comparisons which would not
work when a user resequenced the numbering within the program or
added a line. The change migration products that are used have a
proven method for preserving the integrity of the source compare.

Code Review Requirements
-------------------------
A. Source Modules

Source modules are the programs that written the use high level
languages (COBOL, Fortran, C, Basic, PL1), low level languages
(assembler) or 4th Generation Languages.

o variables are used in the program as opposed to hardcoded
entries and literals (e.g., hardcoded account numbers)

o all changes to name & address files are appropriate

o any calls to system dates are valid

o ensure that programs that were changed were as required by
the request

identify opening of new datasets to ensure that all new
datasets were as specified by the program request


B. JCL

In most installation Procedures (PROCS) are used to run the
applications. JCL is used to execute PROCS which run the
application.

o instream data is only used for passing VOLSERS, date
parameters, and sort routines and does not append records to
files

o all concatenations of datasets are appropriate

Note:
concatenation of datasets consists of two datasets that are
merged where one of them can potentially contain unauthorized
data

C. PROCS

PROCS are used to run the batch applications.

o all load modules are executing from production load
libraries

o ensure that all concatenations of datasets are appropriate

o ensure that all new datasets are as required by the
functional specifications

D. Control Cards

Control Cards are used for specifying sort routines, VOLSERS,
dates but also can be used as data input based on the
requirements of the application.

The only review that is required for control cards is when they
are used as data input to an application. In this case, a review
of the data is required to ensure that it is appropriate.

Audit Step Info
---------------
There is no automated method for determining whether the program
manager is actually performing the code certifications. Some
installations force the manager to sign a form which signifies
that a review took place but this does not prove that the manager
actually performed the review.

One approach that can be used consists of interviewing the
individuals responsible for performing the code reviews to
determine whether they understand what the code review consists
of. Anoher method that can be used is to force the manager to
document the instances within the program that a determination
had to be made if a action within the program was appropriate
(e.g., document each added data set, subroutines used).

Control Point Ref #: chmgraai

A naming convention is used for all module types to distinguish
between the various applications

Audit Steps
-----------
1) Identify the various application that are contained on the
system.

2) Determine if each of the application areas share acceptance
test and production libraries based on module type (e.g.,
JCL, source, load, PROCS) or if separate libraries are
established for each application area.

3) Determine if there is a naming convention established to
distinguish modules used by each application.

3.1) Based on documented naming conventions, review each of the
libraries by module type to ensure that it is being used.

F1 - Info Screen Ref # chmgraai
Background
----------
Due the number of applications that are potentially run on your
system, in many cases it is impracticable to establish separate
libraries for each application area. Therefore, it is imperative
that a standardized naming convention be in place to distinguish
between each application area. Otherwise, applications may
overlay each others modules.

There will always be a separation of libraries based on module
type since each module type (i.e., source, load, JCL, PROCS,
copybooks, control cards) have different format requirements.
For instance, a source module cannot be in a library defined for
load modules.

Control Point Ref #: chmgraaj

The method for retrieving PROCS ensures that the proper version
is being executed

Audit Steps
-----------
1) Determine the method that is used by execution JCL to fetch
PROCS from their proper libraries

o establishment of a unique naming convention between the
modules that reside in production, acceptance test, and
system test libraries in order to select the proper module
from the PROC00 DDname of the JES2 concatenation.

o specify the DDname within the execution JCL (/*JOBPARM
P=<JES DDname>) and use a unique naming convention to
distinguish between the modules that reside in production,
acceptance test, and system test libraries in order to
select the proper module from the specified DDname of the
JES2 concatenation.

o assign each environment (e.g., acceptance test, system test,
production) a separate DDname in order not have a unique
naming convention

o assign each environment (e.g., acceptance test, system test,
production) a separate DDname but all environments are
specified in the concatenation. However, whichever DDname
an environment is assigned, their libraries will be the
first entry in the concatenation.

2) Obtain a copy of the JES2 startup PROC from SYS1.PROCLIB
which specifies all of the PROC DDnames and their
corresponding PROCLIBs.

If PROC00 is used to search for PROCS for all environments
3) Ensure that all environments (e.g., production, System test,
and acceptance test) have a unique naming convention.

3.1) Review the PROC libraries specified in the PROC00 and
identify all of the libraries specified.

3.2) Obtain a listing of each library and ensure that there are
no duplicate modules specified across all of the libraries.

If the JES2 DDname is referenced from the execution JCL
4) Ensure that all environments (e.g., production, System test,
and acceptance test) have a unique naming convention.

4.1) Review the PROC libraries specified in the all PROC DDnames
and identify all of the libraries specified.

4.2) Obtain a listing of each library and ensure that there are
no duplicate modules specified across all of the libraries
within each DDname.

If a JES2 DDname is assigned to each environment (e.g.,
production, test)
5) Ensure that all environments (e.g., production, System test,
and acceptance test) have a unique DDname.

5.1) Review the PROC libraries specified in the all PROC DDnames
and identify all of the libraries specified and through
discussions with the applications group verify that each
environment has been assigned their own DDname.

5.2) Review the execution JCL libraries for each environment and
ensure that there is a /* JOBPARM P=<DDname assigned to
application> specified.

Note:
There is no systematic method for identifying JCL libraries.
Therefore this information must be obtained from the applications
area.

If a JES2 DDname is assigned to each environment (e.g.,
production, test) with all environments specified in the
concatenation.

6) Ensure that the environments library is the first dataset in
the concatenation.

6.1) Review the JES2 concatenation and ensure that for the DDname
assigned to the application, verify that their PROCLIB is
the first dataset specified in the concatenation.

6.2) Determine the DDnames assigned to each environment through
discussions with the application manager.

6.3) Review the execution JCL libraries for each environment and
ensure that there the correct DDname was specified in the /*
JOBPARM P=<DDname assigned to application>.

Note:
There is no systematic method for identifying JCL libraries.
Therefore this information must be obtained from the applications
area.
F1 - Info Screen Ref # chmgraaj
Background
----------
Procedure JCL (PROCS) is the method used for execution programs
which update datasets during batch processing. Execution JCL is
used to execute these PROCS. PROCS are defined in PROCLIBS which
are defined to JES2 which controls the method of extracting the
PROC from correct set of PROCLIBS. The JES2 startup PROC is
where all PROCLIBS are defined. The PROCLIBS are organized in
grouping which is referenced by the //DDname.

Execution JCL which executes the PROC, can instruct JES2 to
search a specific grouping for the PROCLIB to fetch the PROC by
specifying /* JOBPARM P=<DDname assigned to application> in the
execution JCL. If no JOBPARM is specified in the execution JCL
then only the //PROC00 DDname within the JES2 startup is searched
for the PROC. Within all DDnames, multiple PROCLIBS can be
specified. When multiple datasets are specified in a DDname this
is referred to as a dataset concatenation. JES2 will search the
concatenation based on the sequence that the datasets are
defined.

The exposure of executing the wrong PROC is limited to the
production environment since if a PROC was executed that is used
for Acceptance Testing, test datasets would be updated. If a
production PROC was mistakenly executed by the Acceptance Test
environment, then the job would abend assuming that the user in
the Acceptance Test environment does not have update access to
production datasets.

Audit Step Info
---------------
There are many methods for organizing PROCLIBS in the JES2
startup PROC in order to search for a particular PROC. Based on
the approach that is used, audit steps are provided to ensure
that controls are in place to verify that the correct PROC is
fetched.

Control Point Ref #: chmgraba

Emergency changes contains the necessary controls the ensure that
only authorized program changes have occurred

Audit Steps
-----------
1) Determine the method that is used to migrate an emergency
change for execution.

o perform a JCL override to pull the emergency module from a
non-production load library

o move the emergency change into the production load library

2) Ensure that controls are in place to maintain to ensure the
integrity of the code developed which includes the
following:

o permanently capture the source code used for the emergency
change

o controls to ensure that the source and executable versions
remain in synch (e.g., recompile is a secured library)

3) If the method used to install an emergency change is a JCL
override to pull the emergency module from a non-production
load library, ensure that the load library is secured to the
personnel that are required to migrate the emergency change
and audit trails are available which identify whether the
module was changed or deleted after it was executed which is
reviewed by management.

4) Ensure that an after the fact code review is performed to
ensure that all changes that were made were appropriate.

Note:
If the method used to perform an emergency change is to pull the
module from a non-production load library then you must ensure
that the library is secured and there was a corresponding source
library defined in order to recompile the module before it was
executed.
F1 - Info Screen Ref # chmgraba
Background
----------
Emergency changes are a reality of software development.
Traditional controls that are required to migrate a change to
production should be maintained in terms of preserving the
integrity of the code developed. However, since an emergency
change in most cases occurs after business hours or require
immediate installation, the management review processes must be
performed after the install process.

Audit Step Info
---------------
The review to ensure that a change was actually an emergency
change and the follow-up testing to ensure that the emergency
change was tested to ensure that is function as required is
performed in the SDLC main section.

************************************************************************
Copyright 1991 - 2009, Audit Serve, Inc. All rights reserved. All Audit
Programs are copyrighted and may not be posted electronically or
redistributed unless written permission is granted by Audit Serve, Inc.
The Audit Programs may be used for internal use within organizations.
Audit Programs may not be resold.
************************************************************************

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.