ENDEVOR AUDIT PROGRAM
Contributed by Pamela Jerskey, Boston College
(This audit program was created with special assistance and guidance from Connie
Balodimos-Bank of Boston)
I. BACKGROUND INFORMATION:
I.1 Through interviews, note the current flow of change control including Stage I and Stage 2
transactions. Identify and evaluate the specific steps an application must go through prior to
being converted to Endevor.
I.2 Determine the file name/names that contain the start-up /sysgen jobs for Endevor.
Determine what files contain the defaults table, security table, and user exits. Determine what
files contain the Master Control files. Determine what files contain Stage 1 and Stage 2 files;
source and load files; and approval groups.
I.3 Determine what release of Endevor is currently installed.
I.4 Determine how many environments are defined.
I.5 Identify the systems and sub-systems for each environment.
I.6 Identify which systems and sub-systems go with which applications.
I.7 Identify the Endevor System Administrators (via RLIST).
I.8 Determine if dual approval is required. Determine what "quorum" is required for approvals.
I.9 Determine if ESI (External Interface Security-RACF) is used. If not used, determine how
Endevor is defined to RACF.
I.10 Determine whether the signout override action would be reported.
I.11 Determine whether the System Management Facility (SMF) security violation and activity
reports are activated. Identify the review procedures for these reports.
I.12 Determine whether the footprint (audit trail) reports are generated and reviewed.
I.13 Since a programmer who makes a change has update access to the program while it is in
Stage 1, determine when acceptance testing is performed. It should be performed after the
package is cast.
I.14 Endevor 3.5 does not move all components (e.g.; source, object, jcl) of a software change
into production at the same time. Therefore, components which must be synchronized, may not
be. Endevor release 3.6 will automatically ensure all components are present before the change
can be moved into production. If 3.5 is currently utilized, what compensating factors are used.
I.15 Identify who sets up users in the approval groups and specific Endevor actions. It should
be Data Security and the application owner, respectively. A formal "request for access" form
should be used. Identify and evaluate the procedures for maintaining the lists ( changes and
terminations).
I.16 All "packages" are stored in a package dataset. This dataset needs to be cleaned out
periodically and production changes that have been successfully executed need to be deleted.
Determine through interviews who is performing this task since they will have to be in the
approval groups.
II. SYSTEM GENERATION PARAMETERS:
II.1 Start-up/Sysgen Jobs:
II.1.1 Determine the job (BC1JDEFT) that contains the defaults table C1DEFLTS. This defines
the system defaults and sysgen parameters. (Refer to Endevor/MVS Installation Guide, pp.
1-24-1-34).
In job/member (BC1JDEFT), table C1DEFLTS, look for the following parameters:
Under the TYPE=MAIN section:
ACCSTBL=XXXXXXX tells you the name of the access security table. It must be
defined if you are using external (RACF) security.
APRVFLG=Y tells you whether approval processing groups are required. Without it
defined, dual control will not be system enforced.
ESSI=#### where #### is some number. This is the control password. It must be
defined if you are using ESI (external security interface-RACF) security.
SITEID=0 is a one character name that identifies the site. This is used with the footprint.
Therefore, any change in this may compromise the footprint. The footprint is the audit trail.
SMFREC=##### tells you if you are capturing SMF information. If it is equal to zero,
then you are not using SMF interface or capturing SMF records.
PKGCSEC=Y tells you if package security is required. If it is not defined then there is
no security checking when a package is cast.
Under TYPE=ENVRNMNT section, for each environment, the following parameters
should be defined:
RSCETBL=XXXXXXXX defines those elements which can be accessed within each
system and subsystem.
If it is blank, then no security checking is performed. It must be defined if you are using
ESI (External Interface Security-RACF).
USERTBL=XXXXXXXXXX defines the systems and subsystems a user has access
to for each environment. If it is blank, then no security checking is performed. It must be defined
if you are using ESI (external Interface Security-RACF).
SMFACT=YES and SMFSEC=YES tells you if you are using SMF to capture
activity and security information, respectively. These must be defined for SMF action and
security records to be written.
STG1ME=xxx and STG2NME=yyy. If you are sharing files for different environments,
then each environment must have a unique stage 1 name (STG1NME) and a unique stage 2 name
(STG2NME). Different environments should not share the same stage 1 or stage 2. These
parameters define the Master control files for stage 1 and 2.
II.1.2 Determine the job (BC1JNEQU) that contains the External Security Interface (ESI).
It correlates RACF capabilities to Endevor actions.
In job/member (BC1JNEQU?) look for the following parameters:
In the FUNCEQU parameters, look at the SAFAUTH=xxxx and C1ACTNS=yyy,
where xxx will identify the RACF capability and yyy will identify the Endevor action that it is
related to. This will be used to review the RLIST FACILITY report from RACF Interface
portion of this audit program. For example:
FUNCEQU SAFAUTH=READ
CIACTNS=(DISPLAY)
This relates to the RACF READ capability. If a user has the RACF READ access, they
can DISPLAY in Endevor.
The NAMEQU section will define the naming convention for the facilities ( to be
used with the RACF
Interface section-RLIST section of this audit program). The L# tells you the position of the
facility qualifier (e.g.: I1 is the first qualifier, L2 is the second, and so on). For example:
NAMEQU FORMAT1,
L1=('BKBAUTH'),
L2=('ENDEVOR'),
L3=('ENVIRON'),
L4=(ENVIRONMENT),class='FACILITY'
This tells us that the RACF RLIST class will be a facility. Anything in single quotes are
printed literally (exactly as is); anything not in single quotes must be filled in. In the above
example, the facility naming convention for this one format is:
BKBAUTH.ENDEVOR.ENVIRON.environment, where you must fill in the specific
environment name. Any numbers in the parenthesis tell you character positions of the qualifiers
[e.g.: L5=(system(1,3)].
III. APPROVAL GROUPS
(Refer to Chapter 5 of Endevor/MVS Administrator's Guide)
Notes:
"Quorum" refers to the number of approvers required to implement a change. Note,
that is the quorum is one and the individuals also have access to make the change (via the RLIST
facility) then they can also implement the change without dual control.
If two approval groups are required and each has a quorum of one, then the total
quorum is two and dual control is required.
If a system requires an approval group and it has an asterisk * for subsystems, then all
that system's bus-systems also require that approval group.
You can't compare emergency (EM) approval groups and standard (ST) approval
groups. They are separate.
You will need (CONRPT10) Approval Group Definition Report to review. This
report will show you who (userid) is in which approval group and the quorum for each group. If
there is a quorum of 1 or 0, check CONRPT11 for dual control. You will need (CONRPT11)
Approval Group Usage Report to review. This report will list for each
environment/system/subsystem/type combination which approval groups are required. If dual
control is not required, check CONRPT10 for specific quorum.
III.1 Identify which environment/system/sub-system/type combinations require a total quorum of
zero or one. Therefore, dual control is not required for implementing software changes.
III.2 Determine whether emergency (EM) approval groups have a quorum of one and are able to
MAKE any changes (via RACF RLIST facility). If so, they could implement software changes
without dual control.
III.3 Identify the environment/system/sub-system/type combinations which have quorums of one
or zero for all of their approval groups. Determine if one user is in all of the approval groups.
Determine if one user is in all of the approval groups for any one
environment/system/sub-system/type combination.
This person would then be able to approve the changes without requiring dual control.
III.4 Identify the approval groups for each environment, system and sub-system. There should be
approval group(s) for each application. Otherwise, dual control or approval would not be
required to implement a program change.
III.5 Endevor can require individuals in different approval groups to approve a change before it is
moved into production. Therefore, a program change can require a technical approval. It can
also require specific individuals to approve the change. Determine whether this feature is being
used (i.e., Management Group).
IV. SECURITY FEATURES:
(Refer to Chapter 7 of Endevor/MVS Administrator's Guide)
IV.1. Determine whether processors (e.g., compilers) have "Footprint=Create' and
'Monitor=Components' defined. The 'Footprint=Create' creates the footprint/audit trail. The
'Monitor=Components' allows users to inventory all parts/components of a program and find
related code that may be affected by the program change. In order to do this test, you first must
determine which file/files contains the processors. The using TSO, do a super search of all
members in this file/files looking only for strings of G,F, or M (See attachment A).
IV.2. Alternatively, instead of using a TSO super search, have MIS Librarian run JCL from
Endevor to produce the processor list .
IV.3. Determine whether package security (security in place during the 'create' through the
'commit' phases) is enabled for all environments. This will ensure that packages are properly
protected from unauthorized access.
V. FILE PROTECTIONS:
V.1. Generate RACF LD/LG/LU reports and identify who has access to LOADLIB, CONLIB,
NDVX.STAGE1 and NDVX.STAGE2 prefixed files. Only System Administrators should have
UPDATE, ALTER OR CONTROL access. These files contain the: (1) Master Control File, (2)
Stage 1 and Stage 2 files (3) Approval groups, (4) Source and load files, and (5) Security default
and 'sysgen' tables.
VI. RACF INTERFACE:
VI.1. Determine whether users are restricted by Endevor actions. Identify which RACF actions
(READ, UPDATE, ALTER, CONTROL) relate to which Endevor actions (DISPLAY, ADD,
UPDATE, DELETE, MOVE< SIGNOUT< OVERRIDE, ENVIRONMENT MANAGER). Do
this by looking at the FUNCEQU parameter in job BC1JNEQU. (See p.4, Section II.1.2). This
correlates the RACF access capabilities to Endevor actions. For example:
FUNCEQU SAFAUTH=READ
CIACTNS=(DISPLAY)
This relates to the RACF READ capability. If a user has the RACF READ access, they
can DISPLAY in Endevor.
VI.2. Determine the naming convention for the facilities by looking at the NAMEQU parameter
of the BC1JNEQU (See p.4, Section II.1.2.).
'
VI.3. Identify who has access to what environments, systems, sub-systems and types. To do this,
execute the TSO command in batch:
SEARCH CLASS(FACILITY) MASK(BKAUTH.ENDEVOR)
This will generate a listing of facilities that are prefixed with BKAUTH.ENDEVOR (use the
naming convention for your environment).
Edit the output generated above and extract all the facility names to be used below. Execute
the TSO command in the batch:
RLIST FACILITY name-facility-from-above ALL
This will give you the RACF RLIST protections over environments, systems, sub-systems,
and types. To translate which facility relates to which environment, system, sub-system and type,
refer to the SYSGEN section of the audit program.
The type of RACF access a user has (e.g., READ, UPDATE, ALTER or CONTROL) will
determine what that user can do in that environment, system, sub-system and type. For the
correlation of RACF capabilities to Endevor functions refer to Step 1 above and the SYSGEN
section of the audit program.
VI.4. Identify who can perform sensitive functions, such as:
VI.4.a. The SIGNOUT OVERRIDE: This releases the lock on a program. This override
parameter defaults to the most recent on-line use and can be hard-coded into a batch job.
Therefore, a signout override may occur without the individual realizing it, and the original
programmer would only know that the code was released when he/she tried to add it to stage 1.
Additionally, necessary program changes may be lost and confusion may result as to which
version is actually in production. Only application program management should be able to
override a signout. Override procedures, implications and consequences should be documented.
VI.4.b. ENVIRONMENT MANAGER should be reserved for the Endevor administrators.
VII. EXITS:
If the native security facility of Endevor is used, Exit 1 will be called each time Endevor/MVS
finishes a security check. Before performing a requested action, Endevor/MVS checks against the
access security table, user security table and resource security table to determine whether the user
is authorized to perform the action.
VII.1. Verify that Exit 1 is operational by reviewing that a Y value is in the ECBINTNL field of
the Exit Control Block field (equate is ECB$YES).
VIII. BACKUP:
VIII.1 Determine that Endevor/MVS files are regularly backed up. What is the Regularity of
backup?
ATTACHMENT A
ENDEVOR/MVS IMPLEMENTATION STRATEGY
PROCESSOR NAMES:
POSITION 1-PROCESSOR TYPE
G=GENERATE D=DELETE M=MOVE
POSITION2-4 LANGUAGE TYPE OR UTILITY
ASM=ASSEMBLER
CLI=CLIST
COB=COBOL
DAT=DATA (DOCUMENTATION)
EAS=EASYTRIEVE
FOR=FORTRAN
JCL=JCL
LEC=LINK EDIT CONTROL CARDS
LOD=LOAD
OBJ=OBJECT
PLI=PLI
RPG=RPG
TEL=TELON
TRA=TRANSFORM
POSITION 5 DATABASE ENVIRONMENT
D=DB2 S=IDMS
I=IMS N=NONE
POSITION6-OPERATING ENVIRONMENT
B=BATCH C=CICS
D=IDMS-DC I=IMS-DC
N=NONE
POSITION 7-OUTPUT TYPE
I=IMPACT ANALYSIS SCL
L=LOAD MODULE
K=NCAL LOAD MODULE
O=OBJECT
P=PDS
R=REPORT(S)
N=NONE
POSITION 8-STAGE ID
