Audit Serve, Inc.

The Worldwide Connection for Audit, Security, Control and Euro Project Professionals.

Global Pre-Audit Steps Ref #: mgpasaab min/1.2
----------------------
Determine the names used for critical system datasets

Audit Steps
-----------
For MVS/SP
1) Obtain the MSTJCL00 member from SYS1.LINKLIB

For MVS/XA & ESA
Determine the MSTJCLxx suffix that is used by your
installation by reviewing the IEASYS00 member of
SYS1.PARMLIB and determine the setting for MSTRJCL=xx
and obtain the MSTJCLxx member from SYS1.LINKLIB.

2) Identify the following datasets names (DSN= ) that are
specified in their corresponding DDnames:

DDname Dataset Name
------ ------------
//SYSUADS xxxx.UADS
//IEFPDSI xxxx.PROCLIB
//IEFPARM xxxx.PARMLIB

Note:
In most cases the high level prefix (xxxx) will be SYS1

F1 - Info Ref #: mgpasaab
Background
----------
MSTJCLxx is a batch job that is used to start the master
scheduler address space, which is submitted in the early stages
of the IPL. The MSTJCLxx defines the critical datasets that
store members that are used to define the system environment.

The critical datasets consist of the master system PROCLIB
(xxxx.PROCLIB) which stores Started Tasks, xxxx.PARMLIB which
contains all of the MVS parameter files, and xxxx.UADS which
contains the TSO IDs and passwords. The names of these datasets
is the basis for performing any type of review.

The Master JCL is a member that is stored in SYS1.LINKLIB whose
version is defined based on the MSTRJCL=xx parameter within the
IEASYS00 member of SYS1.PARMLIB. Although the name used for
PARMLIB is derived from the MSTRJCLxx member, during the IPL, MVS
will first search SYS1.PARMLIB to determine the MSTRJCL=xx
version that is to be used. After the Master JCL has completed
its execution, all other searches for a member in PARMLIB would
then be based on what is defined in the MSTRJCLxx member.

Although it seems unlikely that an installation would deviate
from the standard high level qualifier, "SYS1", as a
precautionary measure, this global pre-audit step should be
performed. Since throughout the audit programs it is assumed
that the "SYS1" high level qualifier is used, you should
substitute the qualifier used by the installation if a different
is being used.

Audit Step Info
---------------
Based on the audit steps that are specified, there is no
assurance that the disk file that you are reviewing has not been
changes since the last IPL. Therefore, you would be reviewing the
MSTRJCLxx version that will be used in future IPLs but not
necessarily the version that is currently being used by the
system.

In order to identify the system libraries defined by the
MSTRJCLxx member that was loaded in during the last IPL, obtain
the SYSLOG (i.e., console log) from the last IPL and identify the
IEF816I message number which specifies the Master JCL member that
was used and lists the JCL with the associated system datasets.

Example:

IEF816I MASTER SCHEDULER JCL FROM THIS IPL TAKEN FROM MEMBER
MSTJCL00
MN JOBNAMES
MN SESS,T
IEF196I 1 //MSTJCL00 JOB MSGLEVEL=(1,1),TIME=1440
IEF196I 2 // EXEC PGM=IEEMB860,DPTRY=(15,15)
IEF196I 3 //STCINRDR DD SYSOUT=(A,INTRDR)
IEF196I 4 //TSOINRDR DD SYSOUT=(A,INTRDR)
IEF196I 5 //IEFPDSI DD DSN=SYS1.PROCLIB,DISP=SHR
IEF196I 6 //IEFPARM DD DSN=SYS1.PARMLIB,DISP=SHR
IEF196I 7 //SYSUADS DD DSN=SYS1.UADS,DISP=SHR
IEF196I 8 //SYSLBC DD DSN=SYS1.BROADCAST,DISP=SHR
MN JOBNAMES,T
MN SESS,T
IEF196I IEF236I ALLOC. FOR MASTJCL00

Global Pre-Audit Steps Ref #: mgpasaac new/1.2
----------------------
Identify the MVS system parameter members that were loaded in
during the last IPL

Audit Steps
-----------
1) Obtain a copy of the console log (SYSLOG) from the last IPL.

2) Determine the system configuration dataset that was loaded
during the last IPL.

Determine the LOADxx member that was used by reviewing the
console log and identify the message "IEA246I LOAD ID xx
SELECTED" (i.e., where xx is the suffix appended to the
LOAD member).

Note:
The LOADxx member is required.
If the console log cannot be obtained refer to the F1 - Info
Screen for the steps to determine the LOADxx member that is
loaded.

3) Obtain a copy of the IEASYSxx member that was automatically
loaded during the IPL.

3.1) Determine the IEASYSxx member that was loaded in
automatically during the last IPL

Determine the IEASYSxx member that was used by reviewing the
console log and identify the message "IEA247I USING
IEASYSxx" (i.e., where xx is the suffix appended to the
IEASYS member).

3.2) Review the SYS1.PARMLIB dataset for the IEASYSxx member that
was loaded in during the last IPL.

4) Determine if other versions of the initialization parameter
file (IEASYSxx), other parameter files, and individual
parameter overrides that occurred during the last IPL.

4.1) On the console log, identify the system prompt "IEA101A
SPECIFY SYSTEM PARAMETERS". Following this prompt is the
operators response "R00,SYSP=xx (Note: xx is the suffix that
is appended to the IEASYS member being loaded into the
system during the IPL).

If the operator does not load in another IEASYSxx version
then ENTER is pressed and just the IEASYSxx version that was
automatically defined to be loaded will be used by the
system.

Note:
During the IPL, the operator will only be prompted to specify
system parameters overrides if during the initial stages of the
IPL that occurs at the hardware console they specified "a" in the
five character parameter (i.e., PARM) which is entered in the
System or Operator Control Frame.

4.2) Determine whether sub-parameter files and individual
parameters were overridden during the last IPL.

Determine whether the operator specified sub-parameter file
suffix overrides individual parameter overrides after the
system prompt "IEA101A SPECIFY SYSTEM PARAMETERS". For
example, the operator could have responded
"R00,CMD=06,APF=04" where the COMMND06 and IEAAPF04
parameter files could have been loaded into the system
during the IPL.

Note:
The operator will only be able to specify the subparameter files
(parameter files whose suffixes are defined in the IEASYSxx
parameter file) if OPI=YES is specified in the IEASYSxx that was
loaded in during the IPL.

Notes:
The "R00" operator response may not be directly after the
"IEA101A SPECIFY SYSTEM PARAMETERS" system message since at the
time that the operator enters the response there is no active
system log because JES is not active at that stage of the IPL.

The commands entered by the operator (i.e., all commands entered
at the console are identified by a 2 digit entry on the left side
of the command) is stored in a buffer that is allocated to memory
by the Nucleus Initialization Program (NIP) as it starts to build
the system. Every command that is entered and every job that is
started gets written to the buffer that NIP will write to the
system log as soon as the system log becomes active.

Therefore, to identify the start of the IPL where operator
overrides could have occurred the console log should be browsed
until the first time that "NIP" appears on the left side of the
message number. After the first appearance of NIP, the system
parameters that are specified by the operator would then be
present by identifying "R00," and the PARMLIB override (e.g.,
SYSP= xx) which is the reply to the SPECIFY SYSTEM PARAMETERS
message.

However, if no operator overrides occurred, the command which
replies to the SPECIFY SYSTEM PARAMETERS system message may not
be identified since all system replies during or after the IPL
can range from R00 to R99.

5) Determine the parameter files and parameter overrides that
occurred based on the loading a different IEASYSxx versions.

5.1) Obtain listings from SYS1.PARMLIB for the IEASYSxx that was
automatically loaded during the IPL and the other IEASYSxx
members that were loaded based on operator overrides.

5.2) Determine the differences in the parameters that were
loaded in by the IEASYSxx that was automatically loaded
during the IPL and the other IEASYSxx members that were
loaded based on operator overrides.

Note:
The last IEASYSxx that was loaded would override the previous
IEASYSxx versions and the IEASYSxx member that was automatically
loaded during the IPL.

6) Based on the subparameters and individual parameter that
were overridden during the last IPL, identify their
differences from the other IEASYSxx members and the IEASYSxx
that was automatically loaded during the last IPL.

If parameter overrides occurred, then obtain listings if the
parameter calls another parameter file (e.g., APF=01 pulls
parameter file IEAAPF01. However, an override of
LNKAUTH=LNKLST does not pull in a parameter but all datasets
in LNKLSTxx would be APF authorized).

Appendix:
Parameter Member name Default Value if not
in IEASYSxx in SYS1.PARMLIB Contained in IEASYSxx
------------ ---------------- ---------------------
APF=xx IEAAPFxx None
CMD=xx COMMNDxx 00
(2) CON=xx CONSOLxx None
(2) LNK=xx LNKLSTxx 00
(2) LPA=xx LPALSTxx 00
MLPA=xx IEALPAxx 00
MSTJCL=xx MSTRJCLxx 00
(1) PROG=xx PROGxx None
(2) SCH=xx SCHEDxx None
SMF=xx SMFPRMxx 00
SSN=xx IEFSSNxx 00
(2) SVC=xx IEASVCxx None


(1) Available with MVS Release 4.2.2 and greater
(2) Starting with MVS SP4.3, the content of these members can be
displayed on the console log if ",L" operand is specified in the
IEASYSxx parameter of the member. Therefore, instead of
obtaining the disk version of the member which could have been
changed since the last IPL, the contents of the member listed in
the console log should be used instead if this option has been
used.

F1 - Info Ref #: mgpasaac
Background
----------
The hardware IPL (Initial Program Load) process is just one phase
that occurs during the overall operating system initialization
process. The actual hardware IPL has remained unchanged
throughout the technological advances that have been made in the
System/370 architecture. However, the methods to retrieve
components used in the system initialization has significantly
changed in the last four releases of MVS (MVS/ESA release 4.3,
4.2.2, 4.2, and 4.1).
The main processes performed during system initialization is
the creation of the system component address spaces, the
initialization of subsystems, and the loading of components which
tailor the system. The SYS1.PARMLIB dataset and the SYSn.IPLPARM
datasets (i.e., made available in release 4.2), are read by NIP
(Nucleus Initialization Program) during the IPL. These datasets
are the main components of the system initialization that defines
that parameters of a particular system.
Although starting with MVS/ESA 4.1, IBM provided an
automated process to load the system parameter files which
reduces the need for operator's to override the pre-set system
parameters at the MVS console at various points during the
overall IPL process, operators still have the ability to override
these parameters which can only be detected through the review of
the console log from the last IPL.
Since parameters are used throughout the Operating System
Review audit programs in addition to
other audit programs, the process of identifying the individual
system parameters that were loaded into the system during the
last IPL is performed as a Global Audit Steps to eliminate the
need to perform these repetitive steps.
The IEASYSxx member is the focal point of an auditor's
operating system review since it identifies other modules which
impact the integrity of the operating system. The IEASYSxx
member is the initialization parameter file which is loaded into
the system memory during the Initial Program Load (IPL).
IEASYSxx is stored in SYS1.PARMLIB and contains parameters that
customizes how the operating system components functions from a
performance and processing standpoint. In addition, the IEASYSxx
member provides suffix references to other source PARMLIB
parameter files which are loaded into system memory during the
IPL which also controls system processing. In many cases these
referenced parameter files define system libraries to MVS.
MVS/ESA 4.x introduced extensive changes relating to
SYS1.PARMLIB. SYS1.PARMLIB is no longer required to be on the
SYSRES volume and is now located through the master catalog.
There is a new parameter in the 3090 console control frames that
are used to IPL the system, allowing the operator to specify the
IPL volume. During the IPL, the IPLPARM volume is searched for
SYSn.IPLPARM or SYS1.PARMLIB dataset in order to locate the
LOADxx and NUCLSTxx members.
As of version 4.1 of MVS/ESA, the LOADxx PARMLIB member has
been added, reducing the operator intervention that is required
during the IPL. With the LOADxx member, an installation can
specify the volume which contains SYS1.PARMLIB (i.e., the volume
to IPL from), the master catalog to use, whether to prompt the
operator for additional system parameters, and to specify an
alternate IEASYSxx member to use during the IPL. LOADxx
specifies the IEASYSxx version to use, which can be exclusive of
IEASYS00. This capability eliminates the need for operators to
specify SYSP=xx override in order to load a different IEASYSxx
version. However, the operator can override the disable feature
which prevents them from entering system parameters during the
IPL when using the 3090 console IPL frame.
Since the operator can override the pre-set measures which
were to eliminate operator overrides, the console log needs to be
reviewed to determine the overrides that occurred during the last
IPL in order to determine alternate IEASYSxx member that were
loaded.

Alternate IEASYSxx member can be loaded by specifying SYSP=xx
(i.e., xx is the two character suffix of the IEASYSxx member).
If OPI=YES is set in the IEASYS00 member, then individual
parameters within the IEASYS00 can be changed. These parameter
changes can include parameters which load in libraries (APF=02
would load in IEAAPF02) or parameters that do not reference other
PARMLIB member.
All parameter references within the IEASYSxx member that are
loaded would replace or be appended to the parameter settings in
the IEASYS00. An example of a replacement would be individual
parameters that do not reference versions of other parameter
files (e.g., LNKAUTH=LNKLST). An example of parameters that
reference other parameter files which would append definitions
that were initially defined in the IEASYS00 would be the APF=xx
parameter which references IEAAPFxx. The APF=xx reference within
IEASYSxx would define additional APF libraries that were
originally defined in the APF=xx parameter set in the IEASYS00.
However, even parameters that reference other parameter members
can override settings in the referenced parameter file (e.g.,
CONSOLxx which specifies console definitions can have settings
which change the characteristics of a defined system console).
In the past, auditors were mistaken in thinking that an OPI=NO
setting would prevent a different version of IEASYSxx from being
loaded.

Audit Step Info
---------------
The following methods could be used for identifying when the last
IPL occurred:

o If Examine/MVS is available, execute option 1.1.
o Have the operator press the View log button on the system
console and scroll through the log to determine if an IPL
occurred recently (F SYSCONTROL).
o Ask the system programmer when the last IPL occurred.

The initialization parameter file, IEASYS00 and other IEASYSxx
version (i.e., based on the operator override) that are used by
your installation needs to be identified for the basis of
auditing the operating system. Since we do not have the ability
to display the initialization parameters that are currently
contained on the system (i.e., with the exception of some members
which can be defined to have their contents listed in the console
log during the IPL), you are given audit steps to identify the
initialization parameters that are defined on the disk file based
on whether it was overridden during the IPL. It should be noted
that Examine/MVS does not derive the PARMLIB settings that are
currently defined on the system. Therefore, our method is more
appropriate accurate in identifying the settings that are
currently defined on your installation.
It should be noted that certain parameters within IEASYSxx
and other parameter files can be dynamically changed after the
IPL which can circumvent the accuracy of your review. When
performing the control points, we always try to
provide audit steps which would display current system settings.


Steps to obtain PARMLIB members based on the unavailability of
the console log from the last IPL:
---------------------------------
The LOADxx member is selected through the use of the load
parameter on the system control (SYSCTL) frame of the system
console. Although, there is an online history of commands
entered and messages displayed at the system console, there is no
hard copy log. Therefore, the only method for determining
whether an operator override of the LOADxx member occurred during
an IPL is to have the operator display the online log which may
only contain a months worth of history depending on the amount of
activity that has occurred by the system being reviewed.

If the auditor is unable to review the console log from the last
IPL or view the online history of the system console, then it
must be assumed that operator did not override the LOADxx member.
Therefore, the LOAD00 member needs to identified within the two
IPL datasets and reviewed to locate the xx suffix of the IEASYS
member that is used by the system.
As of MVS 4.2 a second IPL dataset, SYSn.IPLPARM was added
where IPL members can be stored as an alternative to
SYS1.PARMLIB. Since the operator overrides cannot be detected,
it must be assumed that SYS1.IPLPARM is used. If the LOAD00
member appears in both IPL datasets then there differences should
be identified and decision made of which member will be used for
the purposes of the review being performed.
Based on the LOAD00 member the obtained, it needs to be
reviewed for the SYSPARM statement to determine the two character
that are specified which are appended to the IEASYS member. If
SYSPARM statement is not specified then the system prompts the
operator to specify the IEASYSxx member of SYS1.PARMLIB to use.
Once again, since the auditor is unable to determine the
overrides that occurred during the last IPL, it must be assumed
that IEASYS00 was entered. All remaining PARMLIB members that
are referenced in the audit steps should be obtained based on the
assumption that IEASYS00 was used.

Global Pre-Audit Steps Ref #: mgpasaae min/1.2
----------------------
Obtain a listing of the JES2 startup procedure and the JES2
initialization parameter files that were loaded into the system
during the last IPL

Audit Steps
-----------
1) Determine if JES2 is automatically started during the IPL.

1.1) Review the IEFSSNxx member that was loaded in during the
last IPL (Ref GL PAS mgpasaad) and determine if JES2 is
automatically started by NOSTART not being specified in the
ssname=JES2 definition.

Notes:
Starting with MVS/XA 2.2 most installations start JES
automatically by defining the subsystem JES2 in the IEFSSNxx
using the ssname=JES2 statement and not specifying the NOSTART
parameter which indicates that an automatic start is not to be
issued.

If your installation uses Netview to start JES2, therefore,
NOSTART can be specified in IEFSSNxx member.

2) Determine whether the JES parameter file was overridden.

2.1) Review the console log from the last IPL and identify S JES2
and determine if a symbolic override was specified to use a
different JES2 initialization parameter file.

Note:
Symbolic overrides can be specified in a START command which can
be used to override a dataset or a member name.
(e.g., //HASPARM DD DSN=SYS1.CTRCARD(&xxxxxx),DISP=SHR where
"&" is the symbolic and "xxxxxx" is the symbolic name. This
symbolic can be overridden in one of three ways:

o in the PROC statement (//JES2 PROC xxxxxx=JES2PARM)

o by the operator at the console only if JES2 is started
manually at the console

o within the Start command specified within one of the two
methods for issuing Start commands during an IPL (i.e.,
IECMD00, COMMNDxx).

2.2) Determine if individual parameters were overridden in the
JES initialization parameter file by locating the system
prompt for JES overrides "HASP426 SPECIFY OPTIONS" and
determine whether individual parameters were specified.

Note:
Individual parameters within the JES initialization parameter
file can only be overridden if the PROMPT parameter is specified.

3) Obtain a copy of the JES2 STC procedure from SYS1.PROCLIB.

4) Obtain a copy of the JES2 initialization parameter files.

4.1) Identify the JES parameter file using the PROC that was
automatically submitted or if the JES PROC was overridden at
the console during the IPL and use the member specified at
console during the IPL if it was overridden.

4.2) Determine if the override parameter member specified in the
//ALTPARM DDname of the JES2 PROC is overriding any JES2
definitions that are contained in //HASPARM DDname.

F1 - Info Ref #: mgpasaae
Background
----------
JES is a MVS subsystem which can be automatically started during
the IPL process by the subsystem parameter file or through
parameter files that issue START commands. The JES2 PROC is
always contained in SYS1.PROCLIB but can be overridden within the
MSTRJCLxx member.

IEFSSNxx is a parmlib member that is referenced by the SSN=xx
parameter within IEASYSxx. MVS subsystems are defined in the
IEFSSNxx member using the ssname parameter. The subsystem can be
automatically started if the NOSTART parameter is not specified.

Audit Step Info
---------------
Many of the JES2 parameters within the parameter files can be
changed dynamically after the IPL using JES commands or
restarting JES itself and overriding the JES parameter file.

If you are running MIM (Multi Image Manager) which was previously
called MSX or Netview, JES2 can be started from these products.

JES2 by default is contained within SYS1.PROCLIB which can be
overridden within the MSTRJCLxx member that is contained within
SYS1.PARMLIB (Ref GL PAS mgpasaab).

Most of the JES2 initialization parameters are not identified for
audit purposes. The JES2 parameters that are currently defined
on the system is determined in the next Pre-Audit Steps.


Global Pre-Audit Steps Ref #: mgpasaaf
----------------------
Obtain a listing of the JES2 initialization parameter settings
that are currently defined on the system

Audit Steps
-----------
1) Determine the JES2 initialization parameters that are
currently in effect by having the operator execute the
following JES commands at the console:

Command Description
------- -----------
$D STCCLASS Started Task options
1 $D JOBCLASS(A) Jobclass options
$D TSUCLASS TSO class
$DINTRDR internal reader options

1 = perform this command for A-Z and 0-9
if MVS/ESA 3.1.3 and higher is used, "*" can be specified to
display all jobclasses

2) Compare the JES2 initialization parameters that are
currently defined to the JES parameters that were loaded in
during the last IPL (Ref GL PAS mgpasaae) to determine the
differences. If any differences are identified, use the JES
parameters that are currently defined when performing the
audit.

F1 - Info Ref #: mgpasaaf
Audit Step Info
---------------
Since the JES2 parameters can be changed dynamically using JES
commands, the currently installed settings should be used instead
of the initialization parameters that are contained in the disk
version which represents the parameters that will be defined
future IPLs.

The commands that are executed, displays some of the JES2
initialization parameters that were loaded during the last JES2
startup from the datasets referenced by the HASPARM and ALTPARM
DDnames of the JES2 PROC.

Global Pre-Audit Steps Ref #: mgpasaag maj/1.2
----------------------
Determine the application and Started Task procedure libraries
that are defined on the system

Audit Steps
-----------
1) Determine the PROCLIB (i.e., procedure library) where the
Started Tasks (STC) are stored.

1.1) Obtain the JES2 startup procedure from SYS1.PROCLIB whose
member name is titled JES2.

Note:
The JES2 startup procedure member name does need to be called
JES2 but it commonly used by all installations. The JES2 member
is identified by the member which has the HASJES20 program
defined in the EXEC statement of the //IEFPROC ddname.

1.2) Determine the other STC PROCLIBs that are defined by
reviewing $D STCCLASS output (Ref GL PAS mgpasaaf) which
identifies the JES parameters set for STCs and determine
what is specified in the PROCLIB=xx parameter.

PROCLIB=xx references the other DDnames within the JES2
startup procedure which contains the other PROCLIBs.

Note:
If operator commands could need be issued to retrieve the current
JES2 settings then review the JES2 initialization parameter file
that was fetched in GL PAS mgpasaae.

1.3) Identify all of the STC PROCLIBs defined in the JES2 startup
procedure based on the //PROCxx DD name identified in the
previous step.

Note:
Multiple PROCLIBs can be concatenated within the //PROCxx

Example of concatenated PROCLIBs:

//PROC01 DD DSN=SYS1.PROCLIB,DISP=SHR
DD DSN=SYS2.PROCLIB

2) Determine the application PROCLIBS that are defined.

2.1) Identify all of the datasets specified in the various PROCxx
DDnames from the JES2 startup procedure.

F1 - Info Ref #: mgpasaag
Background
----------
Started Tasks (STC) are procedures that are started from the
console which remain in own address space. All MVS subsystems
are started as a STC (e.g., VTAM, TSO). Most system software
products (e.g., CICS) are typically started as a STC instead of a
batch job.

Application jobs typically utilize procedures in order to the to
define repetitive execution steps that are used through the job
stream. These procedures are also stored in PROCLIBs whose
procedure references are resolved by searching the specified list
of PROCLIBs that are concatenated in the PROCxx DDname of the
JES2 Start procedure.

In many installation STC and procedure are in separate libraries
but are referenced by the same PROCxx DDname.

This information is gathered at this stage of the review since it
is used by the operating Main Section Pre-Audit Systems,
Operating System review control points and Change Management
control points within the Software Development type of review.

Audit Step Info
---------------
Procedures reside in PROCLIBs which are identified in the
//PROCxx DD statement of JES2 start procedure. Started task and
application PROCLIBs can be separated by being defining them in
different JES2 PROCxx DDnames.

By default SYS1.PROCLIB (i.e., unless overridden in MSTRJCLxx)
is a started task procedure PROCLIB but multiple libraries can be
STC PROCLIBs. The PROCLIBs that are specified are concatenated
data sets that are searched when a STC is executed. If a STC
member is specified in multiple PROCLIBs, the STC member that
appears first in the concatenated data sets will be executed.

The //PROCxx DDname suffix that is used to define the dataset
concatenation of system started task procedures is determined by
the 2 characters specified in the PROCLIB= field within the
STCCLASS statement of the JES2 initialization parameter file. If
no entry is present it defaults to 00.

Application procedures references from execution JCL are resolved
by locating the procedure using the following method:

o If CLASS= parameter used in the job card of the execution JCL
then it references the suffix of the JOBCLASSxx statement in the
JES2 initialization parameter file. Within the JOBCLASSxx
statement, the PROCLIB=xx field when then point the //PROCxx
DDname in the JES2 Start procedure to locate the PROCLIB dataset
in which to fetch the procedure.

o If the JOBPARM P=xx parameter is specified after the JOB card
of the execution JCL of a submitted job then the procedure is
fetched from the //PROCxx DDname in the JES2 Start procedure
based on the xx suffix specification on the JOBPARM P= parameter.

The JOBPARM parameter overrides the CLASS= parameter method for
retrieving the procedure. If neither is used, then the PROC00
DDname in the JES2 Start procedure is used to fetch the
procedure.

Since all of the execution JCL used by production Jobs would need
to be searched to determine which PROCxx DDnames are used based
on the two scenarios described above, it is assumed that
potentially all PROCxx DDnames within the JES2 Start procedures
can be used to store application procedures.

The JES2 initialization parameter file is a member within a
partitioned dataset (PDS) that is referenced by the //HASPPARM
DDname whose parameters are overridden by the contents of the
member specified in dataset referenced by //ALTPARM DDname.

Example:

//JES2 PROC VERSION=20,M=JES2PARM,STARTUP=WARM
//HASPARM DD DSN=SYS1.JESPARM(&M),DISP=SHR
//ALTPARM DD DSN=SYS1.JES2PARM(JESPARM),DISP=SHR

Based on this example SYS1.JESPARM is the dataset in which the
JES2PARM initialization parameter file is stored in. JES2PARM is
retrieved based on the symbolic &M that is specified. The
alternate parameters are stored in the SYS1.JES2PARM dataset
within the JESPARM file.

Example of JES2 Start Procedure:

//JES2 PROC VERSION=20,MEMBER=JES2PARM,ALTMEM=JES2PARM
//IEFPROC EXEC PGM=HASJES
//PROC00 DD DSN=SYS1.PROCLIB,DISP=SHR
// DD DSN=IPO1.PROCLIB,DISP=SHR
// DD DSN=CAI.PROCLIB,DISP=SHR
//HASPARM DD DSN=IPO1.PARMLIB(&MEMBER),DISP=SHR
//ALTPARM DD DSN=SYS1.PARMLIB(&ALTMEM),DISP=SHR

Example of JES2 Initialization file:

STCCLASS
PROCLIB=00

In this example SYS1.PROCLIB, IPO1.PROCLIB, and CAI.PROCLIB are
STC PROCLIBs

Global Pre-Audit Steps Ref #: mgpasaah min/1.2
----------------------
Determine the Commands, Started tasks, and PROCS that are
automatically issued/started during the IPL

Audit Steps
-----------
1) Determine the START commands that are issued through MVS
provided PARMLIB members that automatically issue commands
and start PROCS and Started Tasks.

1.1) Review the following members (i.e., where their suffixes
were obtained in GL PAS mgpasaad) that were loaded into the
system during the last IPL and identify where Start commands
are issued (e.g., S JES2):

COMMNDxx
IEACMD00 (MVS/XA and ESA only)

Perform this step if Top Secret used
2) Determine the START commands that are issued through Top
Secret AUTOCMD member.

2.1) Identify the Top Secret started task that is issued through
one of the methods described in Step 1 and identify S TSS
(i.e., S TSS is the default name that can be changed by
your installation).

2.2) Obtain the Top Secret Started Task which is contained in the
Started Task PROCLIBs (Ref GL PAS mgpasaag for JES
environments or mgpasabg for JES3 environments).

2.3) Identify the dataset and member that is specified in the
//AUTOCMD DD name.

2.4) Review the member for the Start commands that are issued.

F1 - Info Ref #: mgpasaah
Background
----------
There are many methods available during the IPL to start PROCS,
Started Tasks, and commands. This information will be used
throughout the audit.

The sequence of members which execute commands automatically
during the IPL is as follows:

o IEACMD00

o COMMNDxx

Commands can also be automatically executed through the following
products:

CARIM - Computer Associates Resource Initialization Manager
NETVIEW - IBM
MIM - Multi Image Manager (previously called MSX

Global Pre-Audit Steps Ref #: mgpasaai
----------------------
Determine the APF libraries that are defined

Audit Steps
-----------
Perform steps 1 - 3 for MVS/XA and MVS/ESA environments
Perform steps 3 - 4 for MVS/SP environments

1) Determine if LNKLST is configured to specify libraries
within the LNKLSTxx PARMLIB member are APF authorized.

1.1) Review the IEASYS00 and other IEASYSxx members (Ref GL PAS
mgpasaad) that is loaded in the system and determine if
LINKAUTH=LNKLST is specified. If APFTAB is specified then
members specified in LNKLST are not authorized.

Note:
If the LINKAUTH= parameter is not specified in the IEASYS member,
it defaults to LNKLST.

Perform this step if LNKLST is configured to have its libraries
APF authorized
2) Determine the APF libraries specified in the LNKLST.

2.1) Determine the LNKLSTxx that was loaded during the last IPL
(Ref GL PAS mgpasaac or mgpasaad).

2.2) Obtain a list of the LNKLSTxx members from SYS1.PARMLIB.

Note:
The method described obtains the LNKLSTxx members that are
defined on disk which could have been changed since the last IPL
which loaded the LNKLSTxx members into MVS system storage. If you
are using Examine/MVS, you can display the LNKLSTxx members that
are currently in MVS storage using option 2.4.2.

3) Determine the APF libraries specified in the IEAAPFxx member
(Ref GL PAS mgpasaad) of SYS1.PARMLIB.

Note:
The method described obtains the IEAAPFxx members that are
defined on disk which could have been changed since the last IPL
which loaded the IEAAPFxx members into MVS system storage. If you
are using Examine/MVS, you can display the IEAAPFxx members that
are currently in MVS storage using option 2.4.1.

4) Determine the APF libraries specified in the LNKLSTxx member
(Ref GL PAS mgpasaad) of SYS1.PARMLIB.

F1 - Info Ref #: mgpasaai
Background
----------
Most of IBM system programs are stored in APF libraries which can
gain authorization which allows a programs to run as privileged
programs.

SYS1.LINKLIB and SYS1.SVCLIB are the only libraries that are
automatically authorized during and after the IPL. SYS1.LPALIB
is APF authorized during the IPL but is not APF authorized after
the IPL unless it is specified on the IEAAPF or LNKLST member
list. IEAAPF and LNKLST member lists is a facility provided by
MVS to enable installations to specify the libraries that should
be APF authorized after the IPL. For MVS/XA and MVS/ESA,
libraries specified in LNKLSTxx are APF authorized if the
LNKAUTH=LNKLST parameter is specified in the IEASYS00 or the
other IEASYSxx members that are loaded in during the IPL. Within
MVS/SP, the libraries defined in the LNKLSTxx PARMLIB member is
always APF authorized.

Global Pre-Audit Steps Ref #: mgpasaaj
----------------------
Establish a RACF userid for each auditor that is participating in
the review

Audit Steps
-----------
1) Have the security administrator who has the SPECIAL
authority establish a userid for each member of the audit
team with the following access authorities:
*
o The ability to read all datasets on the system which would
require the auditor's connect group to be defined with READ
access to all dataset generic and discreet profiles.

o The ability to execute RACF list commands which would
require the group-auditor attribute whose scope is limited
to a group which owns no resources.

*
If security interfaces are not in place to encrypt password
files of system software products using internal security (e.g.,
CA-7, Omegamon), then the auditors should not be granted READ
access to those datasets.

F1 - Info Ref #: mgpasaaj
Background
----------
Each auditor that is a participant in the audit should have their
own userid established. If you are unable to have an audit
userid established, then you will not be assured that all
listings requested reflect the current operating environment.

The group-AUDITOR attribute is requested for each Auditor's
userid to enable them to list profiles using the RACF list
command. The system-AUDITOR attribute is not requested since it
would enable the auditor to modify the manner in which system
activity will be logged. However, by assigning the group-AUDITOR
attribute to each auditor which is established whereby the scope
of the auditor's connect group owns no resources, prevents the
auditor from issuing the SETROPTS command to alter logging
related system options.

Global Pre-Audit Steps Ref #: mgpasaba maj/1.2
----------------------
Determine the naming standards that are used to distinguish
between the resources defined on the system

Audit Steps
-----------
1) Ask the system programmer and application managers for the
naming conventions that are used for the following resources
which includes how to distinguish between production,
development, and testing and between each application:

o JCL libraries

o Procedure libraries

o Load libraries

o Source libraries

o Datasets (i.e., data files)

2) Ask the system programmer for the naming conventions that
are used to distinguish between tape volumes and disk
volumes.

3) Ask the system programmer for the naming conventions that
are used to distinguish between production and development
tape datasets.

4) Ask the application programmer for the naming convention
used for production and QA test modules. The module types
include:

- compilable program names
- copybook names
- Job names (i.e., execution JCL and PROCS (i.e., procedures)
- control card names

5) Ask the security administrator for the naming convention
used to distinguish between the various type of resources
that are installation defined.

F1 - Info Ref #: mgpasaba
Background
----------
Naming conventions are required in all installations in order to
identify the use of each resource. Without naming conventions
there can be no management of resources,

During the course of the audit, you will need to determine the
sensitivity of a person having access to a specific resource.
The main criteria for determining the sensitivity of the resource
is based on being able to distinguish between production and
development resources and the resources that are used by the
various applications in your installation.

Audit Step Info
---------------
Naming convention standards should provide mechanism for
identifying resources. The naming standards that are used varies
by resource type.

- dataset names

datasets can have 44+ characters which are separate by
qualifiers. Since security systems restrict access based on the
highest qualifier first, the first high level is critical to
distinguish one time a resource from another. Otherwise,
security access restricted would need to be developed at the
lower qualifier level which makes it more difficult to manage.
An effective naming standard assigns special meaning to each
character position of a qualifier.

An example of a dataset naming standard is as follows:

xxxxyz.aaaaaa.

xxxx = the first four characters of the first qualifier
represents an application (e.g., payroll) or system resource
owner (e.g., CA7).

y = the fifth character of the first qualifier represents the
processing environment in which the dataset is part of

Processing Environment:

P = Production
Q = Quality Assurance Test
T = Program System Test
S = System
P = Personal dataset
O = Other

z = the sixth character of the first qualifier represents the
processing environment dataset type

Dataset Types:

B = BDAM
L = Library (PDS)
Q = QSAM
V = VSAM
S = Sequential

aaaaa = second qualifier is an abbreviation of the datasets
purpose (e.g., BACKUPS).

the third and subsequent qualifiers are used to provide
additional relevant information pertaining to the dataset.


Since dataset names consist 44+ characters, an organized naming
convention is required for each high level qualifier. This
especially required by external security systems in order to
provide a separation when establishing security requirements for
various types of resources.

Global Pre-Audit Steps Ref #: mgpasabc maj/1.2
----------------------
Obtain a listing of the RACF installation options

Audit Steps
-----------
1) Obtain a copy of the DSMON reports by submitting the
following JCL:

//<jobname> JOB <installation required job statement parameters>
//<stepname> EXEC PGM=ICHDSM00
//SYSPRINT DD SYSOUT=*
//SYSUT2 DD SYSOUT=*

2) Obtain a copy of the Global System Resource Options
(SETROPTS).

2.1) Execute the SETROPTS LIST RACF command.

or

Submit the following JCL:

//<jobname> JOB <installation required job statement parameters>
//<stepname> EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSTIN DD *
SETROPTS LIST
//

F1 - Info Ref #: mgpasabc
Background
----------
DSMON (Data Set Monitor) is a batch utility that generates the
following reports:

o System Report

Identifies the CPU-ID, CPU model, operating system level, system
residence volume (i.e., DASD volume where IPL occurred from), SMF
ID assigned to the CPU, and the RACF version that is installed.

o Group Tree

Lists superior groups and their subgroup profile hierarchical
relation. The USEROPT control statement can be used by an
installation to define the superior group, otherwise SYS1 is the
superior group used.

o RACF Authorized Caller Table

Lists the names of the programs that are authorized to access any
data set profile which bypasses security validation. This
programs that are defined are not reviewed since the program must
be contained in an APF
authorized library which is the basis of the review.

o RACF Exits Report

Lists the installation defined RACF exits that are being used on
the system.

o Selected User Attribute Report

List the users that have access to sensitive RACF attributes
(e.g., SPECIAL).

o RACF Started Procedures Table Report

Identifies the userid associated with Started Tasks on the
system.

o RACF Class Descriptor Table Report

Lists the class name for the resources that are protected by RACF
which is activated in this table.

o RACF Global Access Table Report

Lists the datasets and resources that all users will have access
to. This simplifies the process of assigning resources that all
users require access to instead of having to define the resource
and access at a profile level for all users.

o Selected Data Set Report

Lists the universal access and protection status for critical
system and RACF datasets. This list can be modified by an
installation to define their own critical datasets.

o Program Properties Table

Used during an MVS review although not a function of Audit Serve,
Inc. audit programs since access to the APF libraries is the
control issue and not the PPT entries that are defined. The
Program Properties Table simplifies the process of identifying
the PPT entries. Otherwise, a job would need to be submitted
which ZAPS CSECTS to identify the PPT entries.

The SETROPTS list contains installation options that impact the
manner in which security is installed in your environment. The
review of each critical setting will be reviewed in separate
control points.

Audit Step Info
---------------
The individual issuing the commands or submitting the job to
print the DSMON and SETROPTS listing will require the RACF
AUDITOR attribute.

Global Pre-Audit Steps Ref #: mgpasabi maj/1.2
----------------------
Determine the installation JCL requirements

Audit Steps
-----------
Ask the system or application programmer if there are any
specific JCL requirements for submitting jobs.

The most common JCL requirements are within the JOB statement.
Some of the installation specified parameters include:

Job Statement
-------------
The JOB statement is used to identify the JOB to the operating
system and starts the JOB.

The following is a list of commonly used key parameters used
within the JOB statement:

o CLASS=

CLASS specifies the job scheduler input class (i.e., Job class)
that is to be used which correlates to an initiator that the
system uses to execute a job. Job classes range from A to Z.
Installations establish a default job class when the CLASS
parameter is not specified in the JOB statement. Some
installations require that specific groups of users utilize
specific job classes in order to control the performance and
priority of jobs that are submitted.

o MSGCLASS=

MSGCLASS specifies the job scheduler output class. The output
class is a single character. The installation sets a default
when an output class is not specified in the job statement. Each
installation has a specific output class that is used hold the
output. SDSF could then be used to view the output from the job.

o NOTIFY=<userid>

NOTIFY specifies the userid that is sent a message when the job
is completed.

o PRTY=

PRTY indicates the job's execution priority. 0 - 15 can be
specified.

EXEC Statement
--------------
Each job steps begins with an EXEC statement that either invokes
a cataloged procedure or the specifies the program to execute.

The following is a list of commonly used key parameters used
within the EXEC statement:

o PARM

PARM passes parameters to the job step. This is commonly used to
override the symbolic parameters that are used through the job
which provides flexibility with the job itself.

DD Statement
------------
The following is a list of commonly used key parameters used
within the DD statement:

o DISP

DISP indicates the data set disposition.

F1 - Info Ref #: mgpasabi
Background
----------
Throughout the audit you will be required to submit jobs in order
to obtain listings which are used to verify the controls on the
system.

Installations at times require a specific format for coding the
job statement especially with the accounting parameters (e.g.,
TIME) otherwise they will abend the job being submitted using a
JES exit.

JCL standards are different for each installation. Many times,
installations use system exits to enforce these standards.
Therefore, prior to the coding of any JCL member, the
installation JCL standards should be requested.

Global Pre-Audit Steps Ref #: mgpasaca
----------------------
Obtain a listing of the STAGE I System Generation from the last
SYSGEN

Audit Steps
-----------
Request a copy of the last Stage 1 System Generation from the
system programmer. If the last SYSGEN was not a full SYSGEN,
obtain the Stage 1 System Generation for the last I/O Generation.

F1 - Info Ref #: mgpasaca
Audit Step Info
---------------
The System Generation (SYSGEN) builds the system libraries that
are used by your operating system.

There are three types of SYSGEN's

o a complete System Generation - SYSGEN
o I/O device generation - IOGEN
o eligible device generation - EDTGEN (i.e., device
allocation)

Unless the STAGE I System Generation is executed through a
control process there is no systematic method available to ensure
that the listing that you received is the current production
version.

If you are using Examine/MVS version 3.0 and higher, you can
display the date of the last EDTGEN and its name. For
Examine/MVS prior to 3.0, it will identify the date & time of the
last EDTGEN, IOGEN, or full SYSGEN that occurred. These dates
and actual names can be used to confirm the listing that you
obtained from the system programmer.

The functions that are performed by the SYSGEN have changed based
on the release of MVS that you are running. In release MVS/XA
2.2 the IOGEN is no longer part of the SYSGEN and is now
performed by the MVS configuration program, PARMLIB members and
SAMPLIB members. The eligible device table generation is also no
longer part of the SYSGEN and is performed by the configuration
program.

The information that is obtained is used based on the MVS release
that you are currently running. For MVS releases prior to MVS/XA
2.2, this information is used to identify the following:

o installation installed SVCs
o installation installed I/O appendages
o System consoles that are installed
o Devices (e.g., DASD) that are installed

If you are running MVS/XA 2.2 or later we use this information to
only identify the devices that are installed at your
installation.


Global Pre-Audit Steps Ref #: mgpasacb
----------------------
Obtain a listing of the TSO users logon PROC and TSO attributes
that they have been assigned

Audit Steps
-----------
Determine the TSO attributes and LOGON PROC assigned to each
user.

Perform this step if running ACF2 5.2, MVS/XA or ESA and TSO 1.4
----------------------------------------------------------------
Determine if ACF2 is controls the parameters entered through the
logon and the TSO attributes by reviewing the ACF2 Global System
Options (Ref GL PAS mgpasabe or execute SHOW ACF2) and determine
whether UADS=BYPASS is specified.

If TSO UADS is defined to ACF2, then identify the logon PROC
defined for each user by reviewing the logonid listing (Ref GL
PAS mgpasabj) and identify the member specified in the TSOPROC
field on the TSO operand. Determine the users that can submit
operator commands and jobs by reviewing the logonid listing and
identify the users that have OPERATOR and JCL specified within
the TSO operand. Determine the users that access TSO by
identifying the users that have TSO specified in the PRIVILEGES
operand of the user's logonid record.

Perform this step if running Top Secret 4.3, MVS/XA or ESA and
TSO 1.4
----------------------------------------------------------------
Determine if the TSO UADS has been defined to Top Secret by
executing TSS WHOOWNS TSOACCT(*), TSS WHOOWNS TSOPROC(*), and TSS
WHOOWNS TSOAUTH(*).

If TSO UADS is defined to Top Secret, determine the logon PROCS
assigned to each user by using the LOGON PROCS that were owned
and execute TSS WHOHAS TSOPROC(<procname>).

If TSO UADS is defined to Top Secret, determine the TSO
attributes assigned to each user by using the TSO attributes
(i.e., ACCT, JCL, OPER, MOUNT, RECOVER) that were owned and
execute TSS WHOHAS TSOAUTH(<TSO attribute>).

Perform this step if running RACF 1.8, MVS/XA or ESA and TSO 1.4
----------------------------------------------------------------
Determine if RACF is used to protect TSO resources by determining
whether the following resources classes are defined within the
RACF Class Descriptor Table (Ref GL PAS mgpasabc) with an active
status:

PERFGRP - TSO performance groups
TSOPROC - TSO logon procedures
ACCTNUM - TSO account numbers
TSOAUTH - TSO user attributes (OPER, JCL, ACCT, MOUNT, REVOVER,
PARMLIB, TESTAUTH)

Determine the TSO logon procedures that have been defined for
each user by reviewing the RACF Generic Resource profiles (Ref GL
PAS mgpasacd), and identify the profiles defined with TSOPROC
specified in the Class field. Identify the TSO logon procedure
which is defined in the NAME field of the TSOPROC Class and
identify the users that have READ or UPDATE access.

Determine the users that have been assigned the OPER TSO
attribute by reviewing the RACF Generic Resource profiles (Ref GL
PAS mgpasacd), and identify the profiles defined with TSOAUTH
specified in the Class field and OPER specified in the Name
field. Identify the users that have READ or UPDATE access.

Perform this step if TSO UADS not defined to external security
system and Examine/MVS is used for the audit
---------------------------------------------------------------
Execute the 2.5 command to display the TSO UADS.

Note:
Examine version 3.1 does not display the TSO attributes that have
been assigned therefore use other steps.

Perform this step if TSO UADS not defined to external security
system and Examine/MVS is not used for the audit
---------------------------------------------------------------
Have the security administrator who has the TSO ACCOUNT privilege
execute the following JCL:

//JOBNAME JOB <installation required job card operands>
//SAST10 EXEC PGM=IKJEFT01,DYNAMNBR=50
//SYSIN DD DUMMY
//SYSUADS DD DSN=SYS1.UADS,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=D
//SYSTSIN DD *
account
list(*)
/*

F1 - Info Ref #: mgpasacb
Background
----------
TSO users are defined with TSO assigned access privileges which
includes the ability to issue MVS commands (i.e., TSO OPER
attribute). With the current releases of MVS (i.e, MVS/XA and
ESA), TSO (TSO 1.4), and external security system products (i.e.,
Top Secret 4.3, ACF2 5.2, and RACF 1.8), these TSO authorities
can be defined and administered by the external security system.
In some cases, the user's TSO ID must still be maintained in the
SYS1.UADS dataset.

The information that is obtained in this Pre-Audit Step is used
throughout the audit review.

************************************************************************
Copyright 1991 - 2000, 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.
*************************************************************

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.