//* DOC: THIS JOB RUNS SDSF AS A BATCH JOB. 00045000
//* 00046000
//STEP001 EXEC PGM=SDSF 00047000
//ISFOUT DD SYSOUT=* 00048000
//DDNAME DD DISP=SHR,DSN=XSYS.KTOMIAK.VB255(TSMPBACK) 00049009
//ISFIN DD * 00050000
PRE TSMPBACK 00060009
OWNER * 00070000
H 00080007
SORT CRDATE D 00081005
S TSMPBACK JOB33361 00082010
F TSMPBACK 00090009
++? 00120007
F SYSPRINT 00121007
++S 00122007
PRINT FILE DDNAME 00130000
PRINT 1 999999999 00140000
PRINT CLOSE 00150000
END 00160000
/* 00170000
// 00180000
The IBM utility IDCAMS can encrypt and decrypt data sets. The key to be used can be provided as parameter or through a separate DD statement.
1 - Key provided as parameter
Encryption
//ENCRYPT EXEC PGM=IDCAMS
//SYSIN DD *
REPRO IFILE(IN01) -
OFILE(OT01) -
ENCIPHER( PRIVATEKEY -
DATAKEYVALUE('ABCDEFGJ') -
)
//IN01 DD *
RECORD 1
RECORD 2
RECORD 3
/*
//OT01 DD SYSOUT=*,
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)
//SYSPRINT DD SYSOUT=*
Decryption
//DECRYPT EXEC PGM=IDCAMS,
// COND=(0,LT)
//SYSIN DD *
REPRO IFILE(IN01) -
OFILE(OT01) -
DECIPHER( DATAKEYVALUE('ABCDEFGJ') )
/*
//IN01 DD DSN=enciphered dataset,
// DISP=SHR
//OT01 DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
2 - Key provided through DD statement
Encryption
//ENCRYPT EXEC PGM=IDCAMS
//SYSIN DD *
REPRO IFILE(IN01) -
OFILE(OT01) -
ENCIPHER( PRIVATEKEY -
DATAKEYFILE(KEY) -
)
//KEY DD *
C1C2C3C4C5C6D1
/*
//IN01 DD *
RECORD 1
RECORD 2
RECORD 3
/*
//OT01 DD SYSOUT=*,
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)
//SYSPRINT DD SYSOUT=*
Decryption
//DECRYPT EXEC PGM=IDCAMS,
// COND=(0,LT)
//SYSIN DD *
REPRO IFILE(IN01) -
OFILE(OT01) -
DECIPHER( DATAKEYFILE(KEY) )
/*
//KEY DD *
C1C2C3C4C5C6D1
/*
//IN01 DD DSN=enciphered dataset,
// DISP=SHR
//OT01 DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//S1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DEFINE ALIAS (NAME(PHIL01) RELATE(USERCAT.TSO))
//NEWID EXEC PGM=IKJEFT01,DYNAMNBR=75,TIME=100,REGION=6M
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSTERM DD DUMMY
//SYSUADS DD DSN=SYS1.UADS,DISP=SHR
//SYSLBC DD DSN=SYS1.BRODCAST,DISP=SHR
//SYSTSIN DD *
DD 'PHIL01.*'
DU PHIL01
AU PHIL01 NAME('PHIL') PASSWORD(PASSW0RD) -
OWNER(SYS1) DFLTGRP(SYS1) UACC(READ) OPERATIONS SPECIAL -
TSO(ACCTNUM(ACCT#) PROC(ISPFPROC) JOBCLASS(S) MSGCLASS(X) -
HOLDCLASS(X) SYSOUTCLASS(X) SIZE(4048) MAXSIZE(0)) -
OMVS(HOME(/u/phil01) PROGRAM(/bin/sh) UID(0))
PERMIT ACCT# CLASS(ACCTNUM) ID(PHIL01)
PERMIT ISPFPROC CLASS(TSOPROC) ID(PHIL01)
PERMIT DBSPROC CLASS(TSOPROC) ID(PHIL01)
PERMIT JCL CLASS(TSOAUTH) ID(PHIL01)
PERMIT OPER CLASS(TSOAUTH) ID(PHIL01)
PERMIT ACCT CLASS(TSOAUTH) ID(PHIL01)
PERMIT MOUNT CLASS(TSOAUTH) ID(PHIL01)
AD 'PHIL01.*' OWNER(PHIL01) UACC(READ) GENERIC
SETROPTS REFRESH RACLIST(TSOPROC)
MKDIR '/u/phil01'
LOGOFF
//S1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DEFINE ALIAS (NAME(PHIL) RELATE(USERCAT.CAT01))
//PRINT EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSUT1 DD PATH='/tmp/file.out',PATHOPTS=ORDONLY
//SYSUT2 DD SYSOUT=*,DCB=(LRECL=121,RECFM=FBA,BLKSIZE=1210)
//SYSTSIN DD DATA
OCOPY INDD(SYSUT1) OUTDD(SYSUT2)
//*
To resume a revoked userid and revoke it again 1 day later. The user's ID
will be resumed at 00:00 on the 14th and revoked at 00:00 on the 15th.
ALU ZOSAEP RESUME(01/14/11) REVOKE(01/15/11)
(1) Pack
//STEP01 EXEC PGM=TRSMAIN,PARM=PACK
//SYSPRINT DD SYSOUT=*
//INFILE DD DISP=SHR,DSN=FILE.TO.TERSE
//OUTFILE DD DSN=FILE.TERSED,
// DISP=(NEW,CATLG),
// SPACE=(CYL,(5,5)),RECFM=FB,LRECL=1024
//*
(2) Unpack
//STEP01 EXEC PGM=TRSMAIN,PARM=UNPACK
//SYSPRINT DD SYSOUT=*
//INFILE DD DISP=SHR,DSN=FILE.PACKED
//OUTFILE DD DSN=FILE.UNPACKED,
// DISP=(NEW,CATLG),
// SPACE=(CYL,(200,50))
Are you using the new Dynamic Scripting Feature Pack? If so, you must be running CICS/TS 4.1 … There was only a limited SupportPac for CICS/TS V3, and IBM just announced that the Dynamic Scripting Featue Pack is not supported on CICS/TS 4.2.
CICS/TS 4.2 supports only 64-bit JVM’s, and the feature pack has environment variables set for using 31-bit JVM’s. We will be watching for an update from IBM soon, as supporting dynamic scripting was listed on the CICS/TS 4.2 Announcment Letter‘s Statement of Direction.
Below is a list of listserv commands you may find handy should you subscribe. All of these commands are issued by sending an email from the email address that is or that you wish to be subscribed to the CICS-L listserv.
Subscribe: Send a message to LISTSERV@LISTSERV.UGA.EDU, with the following in the text (not the subject): SUBSCRIBE CICS-L
Temporarily Leave: If, for example, you are going on vacation, send a message to LISTSERV@LISTSERV.UGA.EDU, with the following in the text (not the subject): SET CICS-L NOMAIL
Rejoin: When you are back from your vacation, send a message to LISTSERV@LISTSERV.UGA.EDU, with the following in the text (not the subject): SET CICS-L MAIL
Leave Permanently: Send a message to LISTSERV@LISTSERV.UGA.EDU, with the following in the text (not the subject): SIGNOFF CICS-L
For More Information: Send a message to LISTSERV@LISTSERV.UGA.EDU, with the following in the text (not the subject): HELP or INFO … HELP will have a short help message sent to you, where INFO will have a list of documents that you can order with more extensive help sent to you.
A few notes on listserv etiquette:
Let’s step away from CICS for a minute and look at an issue that comes up from time to time … You want to delete a file, perhaps an old, uncataloged version of a dataset that is always open – say, SYS1.PROCLIB. If you go to the DSLIST screen in TSO (option 3.4) and enter the dataset name and volume, and try to delete it, you will be informed that the delete failed because the dataset was in use. There is a SYS1.PROCLIB in use, but it’s not the one you are trying to delete. You know what you are doing, but z/OS doesn’t trust you, it seems. (Actually, it’s just that z/OS enqueing is by dataset, not dataset and volume.) The way around this is to “zap” the VTOC to change the name of the dataset to something else that is not in use; then you can delete it.
To zap the VTOC of the volume containing the dataset to be deleted, first we need to find out exactly where the text specifying that name is. To do so, run the AMASPZAP utility, specifying the ABSTDUMP ALL paramter. Here is some sample JCL to dump the VTOC on volume VOL999:
//STP1 EXEC PGM=AMASPZAP,REGION=4096K
//SYSLIB DD DISP=OLD,DSN=FORMAT4.DSCB,
// UNIT=3390,VOL=SER=VOL999,
// DCB=(KEYLEN=44)
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
ABSDUMPT ALL
In the output from this utility, find the dataset name that you wish to change. The hardware address (CCHHR) will be shown for it. Enter that, along with the text to be changed, in another AMASPZAP job. Let’s assume that the output showed the VTOC entry to be at CCHHR 0517000507, and all we want to do is change the first letter, S (hex E2), to a Z (hex E9). Here is some sample JCL to accomplish this:
//STP1 EXEC PGM=AMASPZAP,REGION=4096K
//SYSLIB DD DISP=OLD,DSN=FORMAT4.DSCB,
// UNIT=3390,VOL=SER=VOL999,
// DCB=(KEYLEN=44)
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
CCHHR 0517000507 VER 00 E2 REP 00 E9 /*
Anytime that AMASPZAP is used to change data, be very careful. I usually run such a job with just the VER (verify) statements to ensure that I am hitting the data I expect before adding the REP (replace) statement.
Finally, the VTOC index needs to be changed to the old “OS” format before the dataset can be deleted. To do this, use the ICKDSF utility:
//CNVTOS EXEC PGM=ICKDSF
//DD1 DD UNIT=3390,DISP=OLD,
// VOL=SER=VOL999
//SYSIN DD *
BUILDIX DDNAME(DD1) OS NOPURGE
Find the new dataset name for the file, ZYS1.PROCLIB in this example, and delete it using the DSLIST panel or any other way in which you feel comfortable. Then, convert the index back to “IX” format:
//CNVTIX EXEC PGM=ICKDSF
//DD1 DD UNIT=3390,DISP=OLD,
// VOL=SER=VOL999
//SYSIN DD *
BUILDIX DDNAME(DD1) IX
That’s it! Put this little process away into your systems programmer bag of tricks, as it is all but certain you will need it one day.
alter table tablename change oldname newname varchar (10) ;
Add a column to an existing table:
(1) ALTER TABLE contacts ADD email VARCHAR(60); to the end of the table(2) ALTER TABLE contacts ADD email VARCHAR(60) AFTER name; the new column after a specific column(3) ALTER TABLE contacts ADD email VARCHAR(60) FIRST; the new column to be firstBackuping a single table from a databasemysqldump -u -p database_one table_name > /var/www/backups/table_name.sql
Restoring the table into another databasemysql -u -p database_two < /var/www/backups/table_name.sql
Following was contributed by (Rey LeClerc) at rey@mass-usa.net
Omegamon/MVS Review
Objective: To ensure that adequate security procedures have been established
over OMEGAMON/MVS.
General Description: Omegamon/MVS is a system management aid that allows users
to analyze, control and dynamically modify the MVS/JES system.
Audit Program
1. Identify the Omegamon/MVS environment and controls regarding the
availability and access to powerful Omegamon/MVS commands.
a. Determine whether powerful Omegamon/MVS commands can be used at this site.
These commands are provided only when Omegamon/MVS product has been installed
as APF authorized.
APF authorization for Omegamon/MVS product can be determined by either:
- Verifying that the Omegamon/MVS product library is defined as APF
authorized library.
- Executing the '.APF' immediate command from an Omegamon/MVS sessions.
If Omegammon/MVS has been installed without APF authorization, additional
audit steps are not necessary use the powerful commands in Omegamon/MVS require
that the product be installed as APF authorized.
b. Obtain the listing for the Omegamon/MVS security update program -
'OMSECUP', using the control statements of 'LIST=YES', 'UPDATE=NO'.
c. To determine the type of security used, note the setting for the 'MODULE =
' control statement.
Where there is no entry for this control statement Omegamon/MVS's internal
security facility is being used. Alternatively, the Omegamon/MVS external
security interface is specified here.
d. Obtain and review the source code for the exit routine defined in the
'MODULE = 'control statement. Ascertain what impact the active exit routine
has on security for Omegamon/MVS environment at this location.
The Omegamon/MVS product is provided with two modules that can be used
without modification -'OMRACF', for RACF environments, and 'OMACF2', for ACF2
environments. Because installations can customize these modules, the auditor
must also review the source code even with 'OMRACF' or 'OMACF2' specified.
2. Determine whether access to powerful Omegamon/MVS commands are adequately
controlled and are they provided only on an as needed basis.
a. Using the listing for the Omegamon/MVS security update program - 'OMSECUP'
obtained in the previous step, review the command control statement
specifications set for sensitive Omegamon/MVS commands. These commands include:
DSA - sets and displays authorization to list or zap non-sharable data-only
spaces;
APFU - updates the APF library list;
CONS - displays the MVS operator console;
KILL - terminates an address space;
LPAM - adds, deletes or lists LPA members;
MCHN - scans common area tables;
MLIST - displays storage;
MSCN - scans storage;
MZAP - modifies storage;
OCMD - executes MVS or JES2 primary console commands;
PEEK - collects information about a single address space;
SCHN - scans data-only spaces;
SSCN - scans data-only space storage;
SZAP - modifies the content of data-only space storage;
XMLS - displays MVS storage;
XMSC - scans internal table;
XMZP - modifies storage;
ALIB - (minor command of the SYS command) - displays the defined APF library
names.
MNSW (minor command) - marks job as non-swappable;
External security can be set to use the Omegamon/MVS security levels to
specify access authorization (alternatively, external security authorization
can be established for each individual command, i.e. commands are defined as
resource profiles/rule sets).
If either this method, or internal security is being used, identify 'LEVEL'
settings for each of the sensitive command s - this can be set to either 0, 1,
2, 3 or DISABLE ( this command is inactive) (the default is 0).
Minor commands are protected at the major command level unless the MINOR
control statement is specified; when the MINOR ( and EXTERNAL = YES) control
statements is specified; when the MINOR (and EXTERNAL = YES) control statement
is used, the minor command is protected of major commands.
Note whether external security is activated for each command - 'EXTERNAL = '
YES or NO must be specified. NO is the default. If external security is
inactive for a command, Omegamon/MVS internal security facility is used for
that command.
Also, consider where the 'AUDIT = ' control statement is used. The default
is NONE. This feature can be activated to audit the execution of any
Omegamon/MVS command. When used, either: a message can be sent to the master
console ( the parameter, WTO); and SMF record can be written (the SMF
parameter); or both (the BOTH parameter).
c. For the sensitive OMEGAMON/MVS command authorities (identified in the above
procedure), evaluate whether access has been provided only to those individuals
that require it in performing their daily job functions.
Based on how much security facility is being used (internal or external
security), review the access control definitions to the powerful Omegamon/MVS
commands and determine whether access is adequately restricted.
Perform those procedures below which apply to this environment; if external
security is used, the performance of this audit step should be coordinated with
the auditor responsible for reviewing RACF, to avoid duplication and assigned
to one individual only.
Review the Omegamon/MVS resource class rules (type OMS) that control these
commands for which external security is being activated.
Note: In ACF2 or RACF resource rules can be set up for either individual
commands, or for Omegamon/MVS command levels (resource rule sets of INITIAL,
INITIAL0, INITIAL1, INITIAL2, and INITIAL3).
For Omergamon/MVS internal security, review the command levels and find out
which individuals have knowledge of each of the Omegamon/MVS passwords.
Examine the password values and evaluate whether they are set to either
easily guessed values or to the vendor provided default (i.e. CANDEL1, CANDLE2,
and CANDLE3). Also verify that the Omegagamon/MVS passwords are changed on a
periodic basis.
3. Verify that the Omegamon/MVS product library has adequate data set
protection.
a. Obtain the name of the Omegamon/MVS executable libraries. Also, using the
listing for the Omegamon/MVS security update program - 'OMSECUP', obtained in
the first audit step, obtain the name of the data set specified on the
'AUTHLIB=' control statement
b. Determine the individuals that are directly responsible for maintaining
the product (i.e. system programmers).
c. Examine the data set access rules/profiles to ensure that update access to
the Omegamon/MVS executable library and the AUTHLIB data set are restricted
only to those individuals directly responsible for maintaining the product.
Following was contributed by (Rey LeClerc) at rey@mass-usa.net
MVS Operating System Review
Objectives: To ensure the adequate installation and maintenance of the MVS
environment.
Audit Program
1. Obtain the listings and/or READ access authority for the system parameter
library:
SYS1.PARMLIB.
(Note: Syntax conventions throughout, this audit program uses the strings of
'xx' or 'x' to refer to member name suffix variables. The actual suffix values
are defined within SYS1.PARMLIB' members of SYS1.PARMLIB used by the MVS IPL to
establish the system parameters.
The actual member suffix is either specified by the computer operator during
the IPL process (using the SYSP=xx parameter) or defaults to '00' (i.e.
IEASYS00).
If multiple members exist, compare them, identify their differences, and
evaluate their potential impact on system controls.
2. Identify the system operator consoles and their command capability groups.
These are defined in the CONSOLxx members of SYS1.PARMLIB (CON=xx parameter of
IEASYSxx).
Determine whether these definitions are being overridden by operator
commands. Operator commands are either entered from the console or executed
automatically at IPL by the CMMNDxx member(s) from the CMD=xx parameter of
IEASYSxx.
Verify the active system console definitions by executing the command DISPLAY
ACTIVE (or D A) from either a real or emulated (e.g. SDSF or OMEGAMON) operator
console. Investigate any discrepancies in the active console device names and
their command groups.
Locate all active consoles that have been defined with any of the console
command groups, other than INFO. Evaluate whether there is adequate physical
security over the console(s) and whether the console command group(s) are
appropriate for each console's location and assigned function.
3. Identify the active System Management Facility (SMF) parameter definitions.
These are provided in the SMFPRMxx member(s) of SYS1.PARMLIB from SMF=xx in the
IEASYSxx member).
Key audit concerns include:
Whether the SMF recording option has been activated. Identify the names of
the SYS1.MANx files defined by the DSNAME() parameter. Verify the update or
alter access has not been provided to anyone (review the dataset access control
lists).
Identify the active SMF exits. Review the nature and purpose of these exits
and their impact on the audit and control environment (special attention should
be given to exits IEFU83 and IEFU84, which can be used to suppress SMF
recording).
Which SMF record types are being collected. The important SMF record types
and their functions are:
0, 90 System IPL
7 SMF lost data
5,35 Job record
4,34 Program record
80,81 RACF and CA-Top Secret
information
60-69 VSAM information
30 Combined record (replacing types
(4,5,34,35)
14,15,17,18 Dataset information
Where operators can override SMF recording (the PROMPT parameter).
The appropriateness of the console logging options defined.
Whether the JOB WAIT TIME parameter is set to an appropriate length of time.
This number represents the amount of time (in minutes) that a job will be
allowed to remain idle before cancellation.
In addition to the system efficiency concerns, this parameter is where the TSO
automatic time-out limit for inactive terminals is defined.
4. Identify the libraries that have been designated as APF authorized. MVS
requires certain specific system libraries to be APF authorized (either
consistently or at IPL time) - e.g. SYS1.CMDLIB, SYS1.NUCLEUS, SYS1.LINKLIB,
SYS1.LPALIB, SYS1.IMAGELIB, SYS1.SVCLIB, and SYS1.VTAMLIB. Also, the
installation designated other libraries as APF authorized by referencing these
libraries in:
- The IEAAPFxx member(s) as defined in the APF=xx parameter of IEASYSxx;
- The LNKLSTxx member(s) as defined in the LNK=xx parameter of IEASYSxx.
For MVS/XA systems, the linklist is APF authorized only when the LNKAUTH
parameter of IEASYSxx is set to LNKLST (this is the default value; the
alternate setting is APFTAB).
- The LPALSTxx member(s) as defined in the LPA=xx parameter of IEASYSxx.
Programs defined in the LPA libraries get APF authorization when moved into LPA
during the system IPL.
Review the libraries designated here as APF with the MVS system programmer
and determine:
- The nature and purpose of each APF library.
- Whether there are any duplicate libraries (by function, similar names,
etc.)
- The necessity of these libraries (only production system libraries should
be defined here.)
- Whether any application program libraries (both test and production) or
data file
libraries have been defined here.
- The individual and suitable backup personnel responsible for maintaining
each
of these libraries.
- The appropriateness of these data set access profiles over the APF defined
libraries. Access to these libraries should be strictly controlled.
In addition to the APF authorized libraries, access controls over the page and
(if defined) swap datasets should be verified (defined as PAGE= and SWAP= in
IEASYSxx).
5. Identify the subsystems defined to MVS. These can be found in the IEFSSNxx
member(s) as defined in the SSN=xx parameter of IEASYSxx. Ascertain whether
these are active, their nature and purpose and their affect on overall MVS
controls.
6. Ensure that the Program Properties Table (PPT) is protected by RACF. The
PPT is included in the SYS1.NUCLEUS dataset and can be modified by the PPT
entries in the SCHEDxx member(s) of SYS1.PARMLIB as defined in the SCH=xx
parameter of IEASYSxx.
In RACF environments, the DSMON Program Properties Table report provides a
comprehensive listing of the PPT.
Identify those entries that are defined to bypass password protection.
Determine the nature and purpose of these programs, access controls over them,
and evaluate their appropriateness.
7. Review the installation defined SVC's (Supervisory Calls) that are supplied
in the IEASVCxx member(s) as defined in the SVC=xx parameter of IEASYSxx.
Identify those SVC's that have been defined with the APF=NO.
Ascertain whether these SVCs perform any sensitive functions.
If so, obtain the source code for the SVC(s) and make sure that the TESTAUTH
macro is used to control the use of the SVC(s).
A number of vendors provide SVCs for their product as load modules only. If
no source code is available, it is necessary to rely on the integrity of
established and reputable vendors.
8. Review access to sensitive MVS utilities and service aids.
These special programs and the standard libraries that they reside in include:
ICKDSF in SYS1.LINKLIB
IAHDASDR in SYS1.LINKLIB
AMASPZAP (SUPERZAP) in SYS1.LINKLIB
IEHINITT in SYS1.LINKLIB
Determine whether these programs reside in their standard libraries. List the
index of the default libraries (e.g. SYS1.LINKLIB) to verify that the programs
reside there;
If these programs reside in the standard system libraries (with universal
execute access), ascertain whether the data security software is controlling
execute access to these programs in another manner.
Examples of such controls include the RACF PROGRAM general resource class.
Evaluate the adequacy of the controls in place over the execution of special
programs. Review the established access rules/profiles over these programs.
Verify that execute access is granted only to the appropriate system
programming and computer operations personnel.
* * * * *
Reference Manual
MVS/Extended Architecture System Programming Library: Initialization and
Tuning, GC28-1149-5
Contributed by Pamela Jerskey, Boston College
1. Run IDCAMS to produce Master Catalog Listing (do not print) - use as reference for
looking up libraries for audit tests (MVSMSTR.JCL).
2. Run PDSLIST of SYS1.PARMLIB to produce listing (do not print) - edit as needed for
workpapers for audit tests (MVSPARM.JCL).
3. Run PDSLIST of SYS2.PARMLIB to produce listing (do not print) - edit as needed for
workpapers for audit tests (MVSPARM2.JCL).
4. Run PDSLIST of SYS1.PROCLIB to produce listing (do not print) - edit as needed for
workpapers for audit tests (MVSPROCL.JCL).
5. Obtain RACF DSMON Report and Data Sets Report from Security Administrator.
I. MASTER CATALOG:
Review all data sets in the Master Catalog and determine if protected under RACF.
II. SYS1.NUCLEUS REVIEW:
A. Run IEHLIST of SYS1.NUCLEUS to review for multiple members
(MVSNUC.JCL). Check for IEANUCxx where xx = 00, 01, etc.
B. Determine that SYS1.NUCLEUS is protected under RACF by reviewing RACF
DSMON Report from Security Administrator.
III. SYS1.PARMLIB REVIEW:
A. Edit SYS1.PARMLIB listing for member IEASYS00. Review parameters. Use
of the ,L option within specified IEASYSxx members is encouraged. The
IEASYS00 parameters of audit significance and their associated PARMLIB
members include:
1. APF=(00) IEAAPFxx
2. MLPA=(00,L) IEALPAxx
3. CMD=(00) COMMNDxx
4. LNK=(00,L) LNKLSTxx
5. LPA=(00,L) LPALSTxx
6. MSTRJCL=(00) MSTJCLxx
7. LNKAUTH=LNKLST LNKLSTxx
8. SCH=(00,L) SCHEDxx
9. SMF=(00) SMFPRMxx
10. SVC=(00,L) IEASVCxx
11. PAGE=
Review protection for all datasets listed including PAGE datasets.
B. Authorized Program Facility (APF) is the primary mechanism for security and
control within the MVS Operating System. APF is a facility that identifies
programs authorized to use restricted functions in the MVS Operating System.
Access to APF libraries should be controlled to prevent unauthorized routines
from being inserted in these libraries and run in an authorized state. Nonexistent
data sets or volumes which could allow a user to improperly allocate an authorized
library.
Edit SYS1.PARMLIB listing for member PROG00. Run IEHLIST for each data
set in member IEAPF00 (MVSIEAAP.JCL). Determine:
1) that all members exist on the volume specified by reviewing the output.
2) that all members are catalogued by reviewing the Master Catalogue listing.
3) that no duplicate data sets exist by reviewing IEAPF00.
4) that all members are RACF protected by reviewing RACF DSMON report
(Selected Data Sets Report).
5) Review protection for SYS1.IMAGELIB.
C. Edit SYS1.PARMLIB listing for member LNKLST00. Run IEHLIST for each
data set in member LNKLST00 (MVSLKLST.JCL) (volume can be identified by
searching the Master Catalog). Determine:
1) that all members exist on the volume specified by reviewing the output.
2) that no duplicate data sets exist by reviewing LNKLST00.
3) that all members are RACF protected by reviewing RACF DSMON Report
(Selected Data Sets Report).
D. Edit SYS1.PARMLIB listing for member LPALST00. Review as in #C.
(MVSLPALS.JCL).
E. Edit SYS1.PARMLIB listing for member IKJTSO00. Review with systems
programmer the following:
AUTHCMD NAMES (determine what function each command performs)
AUTHPGM NAMES (determine what function each program performs)
IV. SVC REVIEW:
A. Edit SYS1.PARMLIB listing for member IEASVC00.
B. Run IEHLIST report for SYS1.LPALIB and all members in LPALST00.
(MVSLPALB.JCL).
C. Run AMBLIST of SYS1.NUCLEUS (MVSIEANU.JCL) to identify any user
added SVCs (IGCxxx where xxx = 200-255).
D. Using reports from B & C, search listing for members that begin with IGC. Edit
listing for workpapers. Compare IGC listing to IEASVC00 to determine user
added SVCs and if they are active (Note: IGCxxx where xxx = 200-255 are user
added SVCs).
E. Run IEHLIST for SYS1.SVCLIB (MVSSVCLB.JCL). Identify member names
that begin with NSL. Discuss with system programmer.
F. Determine that SYS1.SVCLIB is protected under RACF by reviewing RACF
DSMON Report (Selected Data Sets Report).
G. From IEASVC00, APF(NO), the default, allows any user to invoke the SVC.
Ensure that any SVC available to all users (APF(NO)) respects system integrity
requirements. Discuss with systems programmer.
V. EXIT REVIEW:
JES EXITS:
A. Edit SYS1.PROCLIB for member names JESM and JES. Locate HASPPARM
DSN. Edit SYS2.PARMLIB for JESMPARM and JES2PARM. Locate each
exit (EXITnn). Edit listing for workpapers. Discuss the function of each exit with
system programmer.
SMF EXITS:
A. Edit SYS1.PARMLIB listing for member SMFPRM00. Ensure that the member
that specifies the SMF is ACTIVE. Review the NOPROMPT option.
NOPROMPT offers the operator no choice in the parameters selected.
NOPROMPT is the most secure. List exits. Identify exits in SYS1.LPALIB from
IEHLIST report (see Audit Program IIIB.) (IEFU......). Run AMBLIST for all
exits in SMFPRM00 (MVSDUMP.JCL). Determine:
1) if exit is used.
2) if used, what function it is performing.
3) if used, last linkage date.
4) length.
VI. PROGRAM PROPERTIES TABLE REVIEW:
Edit SYS1.PARMLIB listing for member SCHED00. Obtain DSMON Program
Properties Table Report from Security Administrator. Review programs that
bypass password protection and have a system key=yes from DSMON Report
(from SCHED00, have NOPASS and Key 0-7). Determine what these programs
are doing. Discuss with system programmer.
VII. VTAM REVIEW:
A. Edit SYS1.PROCLIB listing for member NET. Identify VTAMLST DSN and
VTAMLIB DSN. Run PDSLIST of SYS2.ACFVTAM.VTAMLST (dsn of
VTAMLST) to product listing (do not print) - edit as needed for workpapers for
audit tests (MVSVTML.JCL). Review Start-Up VTAM. Review ATCSTR00
to identify which member contains start-up vtam members. Review ATCCON00
(Start-up VTAM). Search and edit entire listing for:
1) AUTH=(ACQ, Can acquire other "LU"
or PASS Can pass LU to another application
or SPO, PPO) Application can issue net commands
2) AUTHEXIT=YES Application exits get control in supervisor
state whether or not authorized.
Identify which members are in Start-up VTAM and which members are not.
Review any of these conditions with system programmer. Discuss how
these members are defined to RACF.
VIII. JES REVIEW:
A. Determine to what level SYS1.HASPACE is protected under RACF.
SYS1.HASPACE is the data set for all spooled input and output. Review with
systems programmer why "alter" level is needed by systems programmers (only
JES needs access).
B. Edit SYS2.PARMLIB for JES2PARM. Locate SPOOL (spooldef) and
CHECKPOINT (ckptdef) volumes. Determine what level of protection exists
under RACF. Review the following parameters:
COMMAND=(execute, ignore or verify). Ignore or verify is best. The console
command allows operators to change JES2 parameters.
OFFLOAD= This should not be turned on. It is a non-standard way of
interrupting data flow in JES2.
RMT1
RMT2, etc. This is remote JES. Check for passwords. How often are they
changed?
MVSMSTR.JCL
//AUDIT JOB,CLASS,MSGCLASS,
// USER=xxxxxx,PASSWORD=xxxxxxx
/*ROUTE PRINT
//*
//* THIS PROGRAM IS USED FOR AUDITING MVS TO ACCESS
//* THE MASTER CATALOG
//*
//SS1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
LISTC ALL
MVSPARM.JCL
//AUDIT JOB,CLASS,MSGCLASS,
// USER=xxxxx,PASSWORD=xxxxxx
/* ROUTE PRINT
//S1 EXEC PGM=PDSLIST,PARM='EJECT,INDEX'
//* PARM= SPACE (SKIP A LINE) - EJECT (A PAGE) - ALPHA (LIST BY NAME)
//* INDEX (INDEX IT) - UPDTE (IEBUPDTE CONTROL)
//SYSPRINT DD SYSOUT=*,OUTLIM=0
//OUTPDS DD SYSOUT=(B,,CHAR),DCB=BLKSIZE=80
//SYSUT9 DD DSN=SYS1.PARMLIB,DISP=SHR
//SYSIN DD *
//
MVSPARM2.JCL
//AUDIT JOB,CLASS,MSGCLASS,
// USER=xxxxxx,PASSWORD=xxxxxxx
/* ROUTE PRINT
//S1 EXEC PGM=PDSLIST,PARM='EJECT,INDEX'
//* PARM= SPACE (SKIP A LINE) - EJECT (A PAGE) - ALPHA (LIST BY NAME)
//* INDEX (INDEX IT) - UPDTE (IEBUPDTE CONTROL)
//SYSPRINT DD SYSOUT=*,OUTLIM=0
//OUTPDS DD SYSOUT=(B,,CHAR),DCB=BLKSIZE=80
//SYSUT9 DD DSN=SYS2.PARMLIB,DISP=SHR
//SYSIN DD *
//
MVSPROCL.JCL
//AUDIT JOB,CLASS,MSGCLASS,
// USER=xxxxxxxx,PASSWORD=xxxxxxxx
/*ROUTE PRINT
//S1 EXEC PGM=PDSLIST,PARM='EJECT,INDEX'
//* PARM= SPACE (SKIP A LINE) - EJECT (A PAGE) - ALPHA (LIST BY NAME)
//* INDEX (INDEX IT) - UPDTE (IEBUPDTE CONTROL)
//SYSPRINT DD SYSOUT=*,OUTLIM=0
//OUTPDS DD SYSOUT=(B,,CHAR),DCB=BLKSIZE=80
//SYSUT9 DD DSN=SYS1.PROCLIB,DISP=SHR
//SYSIN DD *
//
MVSNUC.JCL
//AUDIT JOB,CLASS,MSGCLASS,
// USER=xxxxxxx,PASSWORD=xxxxxxx
/*ROUTE PRINT
//*
//* This program is used to review sys1.nucleus members for mvs audit
//*
//SS1 EXEC PGM=IEHLIST
//SYSPRINT DD SYSOUT=*
//DD1 DD DSNAME=SYS1.NUCLEUS,DISP=SHR
//SYSIN DD *
LISTPDS DSNAME=SYS1.NUCLEUS,FORMAT
MVSIEAAP.JCL
//AUDIT JOB,CLASS,MSGCLASS,
// USER=xxxxxxx,PASSWORD=xxxxxxx
/*ROUTE PRINT
//*
//* THIS PROGRAM IS USED TO LIST MEMBERS IN IEAAPF TO DETERMINE
//* IF ALL MEMBERS EXIST; ALL MEMBERS ARE CATALOGUED, ETC.
//*
//SS1 EXEC PGM=IEHLIST
//SYSPRINT DD SYSOUT=*
//DD1 DD UNIT=SYSALLDA,VOL=SER=(volume name),DISP=SHR
//DD2 DD UNIT=SYSALLDA,VOL=SER=(volume name),DISP=SHR
//DD3 DD UNIT=SYSALLDA,VOL=SER=(volume name),DISP=SHR
//SYSIN DD *
LISTPDS DSNAME=(ieaapf file name),VOL=SYSALLDA=(volume name),FORMAT
LISTPDS DSNAME=(ieaapf file name),VOL=SYSALLDA=(volume name),FORMAT
(list all ieaapf file names in each volume)
MVSLKLST.JCL
//AUDIT JOB,CLASS,MSGCLASS,
// USER=xxxxxxx,PASSWORD=xxxxxxx
/*ROUTE PRINT
//*
//* THIS PROGRAM IS USED TO LIST MEMBERS IN LNKLST00 TO DETERMINE
//* IF ALL MEMBERS EXIST; ALL MEMBERS ARE CATALOGUED, ETC.
//*
//SS1 EXEC PGM=IEHLIST
//SYSPRINT DD SYSOUT=*
//DD1 DD UNIT=SYSALLDA,VOL=SER=(volume name),DISP=SHR
//DD2 DD UNIT=SYSALLDA,VOL=SER=(volume name),DISP=SHR
//DD3 DD UNIT=SYSALLDA,VOL=SER=(volume name),DISP=SHR
//SYSIN DD *
LISTPDS DSNAME=(lnklst file name),VOL=SYSALLDA=(volume name),FORMAT
LISTPDS DSNAME=(lnklst file name),VOL=SYSALLDA=(volume name),FORMAT
(list all lnklst file names in each volume)
MVSLPALS.JCL
//AUDIT JOB,CLASS,MSGCLASS,
// USER=xxxxxxx,PASSWORD=xxxxxxx
/*ROUTE PRINT
//*
//* THIS PROGRAM IS USED TO LIST MEMBERS IN LPALST00 TO DETERMINE
//* IF ALL MEMBERS EXIST; ALL MEMBERS ARE CATALOGUED, ETC.
//*
//SS1 EXEC PGM=IEHLIST
//SYSPRINT DD SYSOUT=*
//DD1 DD UNIT=SYSALLDA,VOL=SER=(volume name),DISP=SHR
//DD2 DD UNIT=SYSALLDA,VOL=SER=(volume name),DISP=SHR
//DD3 DD UNIT=SYSALLDA,VOL=SER=(volume name),DISP=SHR
//SYSIN DD *
LISTPDS DSNAME=(lpalst file name),VOL=SYSALLDA=(volume name),FORMAT
LISTPDS DSNAME=(lpalst file name),VOL=SYSALLDA=(volume name),FORMAT
(list all lpalst file names in each volume)
MVSIEANU.JCL
//AUDIT JOB,CLASS,
// USER=xxxxx,PASSWORD=xxxxx
/*ROUTE PRINT
//SS1 EXEC PGM=AMBLIST
//SYSPRINT DD SYSOUT=*
//SYSLIB DD DSN=SYS1.NUCLEUS,DISP=SHR
//NUCLEUS DD DSN=SYS1.NUCLEUS,DISP=SHR
//SYSIN DD *
LISTIDR DDN=NUCLEUS,OUTPUT=IDENT,MODLIB,MEMBER=IEANUC01
LISTLOAD DDN=SYSLIB,MEMBER=IEANUC01,OUTPUT=XREF
MVSSVCLB.JCL
//AUDIT JOB,CLASS,
// USER=xxxxxx,PASSWORD=xxxxxxxx
/*ROUTE PRINT
//SS1 EXEC PGM=IEHLIST
//SYSPRINT DD SYSOUT=*
//DD1 DD DISP=SHR,UNIT=SYSALLDA,VOL=SER=(volume name)
//SYSIN DD *
LISTPDS VOL=SYSALLDA=(volume name),DSNAME=SYS1.SVCLIB
MVSDUMP.JCL
//AUDIT JOB,CLASS,
// USER=xxxxxx,PASSWORD=xxxxxxxx
/*ROUTE PRINT
//SS1 EXEC PGM=AMBLIST
//SYSPRINT DD SYSOUT=*
//LPALIB DD DSN=SYS1.LPALIB,DISP=SHR
//SYSIN DD *
LISTIDR DDN=LPALIB,OUTPUT=IDENT,MEMBER=IEFU83
LISTIDR DDN=LPALIB,OUTPUT=IDENT,MEMBER=IEFU84
LISTIDR DDN=LPALIB,OUTPUT=IDENT,MEMBER=IEFACTRT
LISTIDR DDN=LPALIB,OUTPUT=IDENT,MEMBER=IEFUJV
LISTIDR DDN=LPALIB,OUTPUT=IDENT,MEMBER=IEFUSI
LISTIDR DDN=LPALIB,OUTPUT=IDENT,MEMBER=IEFUJI
LISTIDR DDN=LPALIB,OUTPUT=IDENT,MEMBER=IEFUTL
LISTIDR DDN=LPALIB,OUTPUT=IDENT,MEMBER=IEFU29
LISTIDR DDN=LPALIB,OUTPUT=IDENT,MEMBER=IEFUJP
LISTIDR DDN=LPALIB,OUTPUT=IDENT,MEMBER=IEFUSO
LISTIDR DDN=LPALIB,OUTPUT=IDENT,MEMBER=IEFUAV
LISTIDR DDN=LPALIB,OUTPUT=IDENT,MEMBER=IEFU85
LISTLOAD DDN=LPALIB,MEMBER=IEFU83,OUTPUT=XREF
LISTLOAD DDN=LPALIB,MEMBER=IEFU84,OUTPUT=XREF
LISTLOAD DDN=LPALIB,MEMBER=IEFACTRT,OUTPUT=XREF
LISTLOAD DDN=LPALIB,MEMBER=IEFUJV,OUTPUT=XREF
LISTLOAD DDN=LPALIB,MEMBER=IEFUSI,OUTPUT=XREF
LISTLOAD DDN=LPALIB,MEMBER=IEFUJI,OUTPUT=XREF
LISTLOAD DDN=LPALIB,MEMBER=IEFUTL,OUTPUT=XREF
LISTLOAD DDN=LPALIB,MEMBER=IEFU29,OUTPUT=XREF
LISTLOAD DDN=LPALIB,MEMBER=IEFUJP,OUTPUT=XREF
LISTLOAD DDN=LPALIB,MEMBER=IEFUSO,OUTPUT=XREF
LISTLOAD DDN=LPALIB,MEMBER=IEFUAV,OUTPUT=XREF
LISTLOAD DDN=LPALIB,MEMBER=IEFU85,OUTPUT=XREF
MVSVTML.JCL
//AUDIT JOB,CLASS,MSGCLASS,
// USER=xxxxxx,PASSWORD=xxxxxxxx
/*ROUTE PRINT
//S1 EXEC PGM=PDSLIST,PARM='EJECT,INDEX'
//* PARM= SPACE (SKIP A LINE) - EJECT (A PAGE) - ALPHA (LIST BY NAME)
//* INDEX (INDEX IT) - UPDTE (IEBUPDTE CONTROL)
//SYSPRINT DD SYSOUT=*,OUTLIM=0
//OUTPDS DD SYSOUT=(B,,CHAR),DCB=BLKSIZE=80
//SYSUT9 DD DSN=SYS2.ACFVTAM.VTAMLST,DISP=SHR
//SYSIN DD *
//
Following was contributed by (Rey LeClerc) at rey@mass-usa.net
Part 2 of 2
other fields which can be used to provide authentication of User-IDs not using
passwords.
They are:
PROGRAM - a certain program is issuing the job and inserting a User-ID.
SUBAUTH - the program submitting the job must be an APF authorized
program. This assumes APF authorization is adequately controlled, because if
it is not, ACF2 cannot be relied upon.
SOURCE - the physical location the job is submitted from may be an
appropriate control.
The most desirable control is to use a PROGRAM and SUBAUTH. The program may be
masked, provided the mask is specific enough not to include programs which
should not be used. PROGRAM without SUBAUTH is practically useless, because
any program can be renamed or copied to a personal library to be used for job
submission. SUBAUTH without PROGRAM is equally ineffective, since there are
many APF authorized programs which could be used for job submission (i.e.
IEBCOPY, WAAPSPLT).
SOURCE could be a good control, provided the SOURCE is a physically secured
location. SOURCE is only as good as the physical controls to that source. An
example of a situation where SOURCE may be practical would be an RJE station,
where jobs submitted from a single line or terminal is physically separate from
the rest of the system. Some examples of poor controls would be INTRDR or
STCINRDR, the system internal readers. These are the sources used for by all
batch jobs or started tasks for submitting other jobs. These can be used by
any job or STC and should never be considered a controlled SOURCE. Another
commonly misused source is READER1. This is a card reader, normally in the
computer room. Anyone with physical access to this reader can initiate jobs on
it.
Review a listing of User-IDs with RESTRICT to ensure that controls are adequate
to ensure on valid usage of the User-IDs. Note that User-IDs used for STC
although they do not have a password, do not need the RESTRICT attribute, and
if it exists, it is ignored. Pay special attention to the programs specified.
The program should insert the User-ID in the JCL based on some pre-defined
criteria. It should not allow the user to insert his own /*LOGONID card.
The listing can be generated by using an ACFRPTSL against the backup files as
follows:
IF(NOT STC AND RESTRICT AND NOT CANCEL AND NOT SUSPEND)
SF(SUBAUTH,PROGRAM,SOURCE)
3. Using the "LIST IF" command or the SL report, determine who has the
SECURITY or the ACCOUNT privilege. These powers should be restricted to 2 or 3
persons, or else limited by the person's DSNSCOPE, UIDSCOPE, or SCPLIST if the
unit has decentralized administration. Systems programmers should never have
either attribute. Verify users with SECURITY and/or ACCOUNT privileges are
responsible for daily administration of Data Security.
SECURITY privilege allows the User-ID to change certain fields of the User-ID
record, make changes to the dataset rules and change the information storage
database. SECURITY privilege does not allow adding or deleting User-IDs.
ACCOUNT privilege allows the User-ID to change certain fields of the User-ID
record and allows for adding and deleting User-IDs on the User-ID database.
ACCOUNT privilege does not allow for writing rules or changing info storage.
Generally, Data Security users are given both privileges to perform their job
function. These privileges can be given to users outside of Data Security
provided they are adequately controlled to limit the changes made to only their
scope of responsibility. A SCPLIST reference can be attached to any user with
SECURITY or ACCOUNT privilege. The SCOPE includes a limitation of LOGONIDs,
UIDs, DATASET rules, and/or INFO STORAGE records. Any combination of these can
be used to limit what a user can do with these privileges.
Make sure that all User-IDs with these privilege belong to users with a data
security responsibility. Also ensure that any users outside of Data Security
have been appropriately scoped to limit their privilege.
4. Using the "LIST IF" command or the SL report, determine which User-IDs
have the NON-CNCL attribute. No more than 3 or 4 such users should be found,
and these should be used for emergency purposes (e.g. started task ids) only.
In addition, their usage should be reviewed. Determine how NON-CNCL and
READALL is being used. These should not be used except on an emergency basis
only. Emphasis should be placed on evidence of review of activity of these
privileges rather than on numbers.
ACF2 has a couple of privileges which can override the recommendation to
prevent an access due to a violation. The privileges have in the past been
abused and distributed without consideration to what the significance of the
privileges granted are.
The NON-CNCL privilege is the most powerful of these privileges. It tells ACF2
that regardless of the violation, no access is to be prevented. A log is
generated for each situation which would have caused a violation, but no
prevention will ever be invoked.
Although this is normally only considered in the dataset environment, any
resource validation such as CICS or IMS transaction, will also be allowed and
logged.
Similarly, the READALL privilege grants the user the authority to open any file
for READ or EXEC regardless of the rules. This privilege also logs any use of
datasets which would not have been allowed by rules. READALL, unlike NON-CNCL
privilege only applies to dataset rules. The use of READALL by any user with
NON-CNCL privilege, should never be criticized. The advantage of giving a user
with the NON-CNCL privilege, the READALL privilege to, is that the resulting
logs can be split based on what was done. If the access was a READ, the report
would describe the reason as, READALL, while all others would be NON-CNCL.
This would provide for more emphasis being placed on the more significant logs
(changes).
One more privilege which should be considered is the SECURITY privilege.
Security is described by ACF2 as being able to change any rule or User-ID and
as such could give itself access to any dataset or resource without external
intervention or approval. For this reason, early releases of ACF2 gave the
SECURITY privilege a power equal to NON-CNCL. Some time later, requests were
made to control SECURITY so that it had to follow the rules like any other id.
The rational behind this was based on the idea that SECURITY officers can make
mistakes like anyone else. By having to follow the rules, any inappropriate
access made by the SECURITY officer, had to be intentional and an overt action
had to be made, but any accidental access would be prevented as normal. To do
this a new privilege was added, the RULE-VLD privilege, which forced SECURITY
to be like any other id where dataset access was involved. Unfortunately,
SECURITY is still NON-CNCL implicitly for any other resource.
It is important to review the justification for and the use of NON-CNCL,
SECURITY without RULE-VLD and READALL. These privileges must be approved by
the data center manager, the users' manager and the system owner. The reason
should be specific. The privilege should seldomly be on the primary User-ID
and reports generated by their use should be reviewed daily to ensure
compliance with the defined need for the privilege. There should be evidence
that the reports are run on a timely basis and that they are reviewed by the
user's manager for appropriateness. A periodic cursory review should also be
performed by Data Security to ensure that the intended purpose of the privilege
is not being abused.
5. Using the "LIST IF" command or the SL report, examine all User-ID
records to determine that no user has a "SYS1" prefix, as this would allow them
complete access to all system files, including ACF2 files. Similarly determine
that no user has asterisks specified. Review User-IDs with a PREFIX different
from the User-ID. Verify that no user has a PREFIX of "********", "ACF*" or
"SYS*".
The PREFIX field is one of the most powerful privileges available to ACF2.
This field describes to ACF2 the high-level index which you own. ACF2 will not
validate any access to datasets which begin with a high-level equal to the
high-level defined in your PREFIX. No logging will be generated. No
violations will occur, regardless of the rules.
This field is of concern, because it can contain a mask. If the mask is all
"*" then the User-ID is NON-CNCL with NO logging. If the mask is for some
sensitive datasets, such as ACF* or SYS*, the integrity of the system is in
question. If the mask is for anything other than the User-ID, it should be
closely examined, to identify what can be accessed without rules.
Some valid reasons for the mask to be different from the User-ID include:
o the user has 2 User-IDs and the PREFIX points the second to the
datasets generated by the first;
o the PREFIX may be blank, indicating that nothing is OWNED by this
User-ID. Rules are required for all access;
o groups of users may share a single high-level, but don't want the
overhead of rule writing and logging.
The listing can be generated by using an ACFRPTSL against the backup files as
follows:
IF(PREFIX NE LID AND PREFIX NE " ") SF(PREFIX)
6. Using the "LIST IF" command or the SL report, determine which User-IDs
have the RESTRICT attribute. Verify that these User-IDs have SUBAUTH
specified, as well as, the PGM and LIB parameters, to ensure that their usage
is via an APF-authorized program from a controlled library.
7. Using the "LIST IF" command or the SL report, examine which users have
the REFRESH attribute. These users are allowed to dynamically activate GSO
options. Determine how the REFRESH attribute is controlled. User-IDs with
this privilege may have their password exposed when using the privilege.
The REFRESH privilege is used to cause changes to the GSO records to be invoked
dynamically, without requiring an IPL. The privilege does not grant any
authority to change any parameters, simply to invoke parameters already
defined. When a modify command is issued, the system requests a User-ID and
password be entered on the console issuing the modify command.
ACF2 then verifies the User-ID has the REFRESH attribute before allowing the
modify to be performed.
The main concern that we should have with the REFRESH privilege is that it can
invoke any GSO record which has been previously defined. So if there is a
record with a MODE of quiet, any user with the REFRESH capability could invoke
that GSO record dynamically.
The secondary concern with REFRESH is that the User-ID and password are entered
in a displayable field and can be seen by anyone in the vicinity. The password
for User-IDs with REFRESH privilege are more subject to being observed than any
other password, because when entered, it cannot be entered in a non-display
field. Any User-ID whose password cannot be relied upon should never have any
powerful privileges attached to them.
For these reasons, the most practical way of controlling the REFRESH privilege
is to assign it to a single User-ID and given to the Operations manager to
control. It's his system and REFRESH controls when ACF2 operating parameters
are changed. The id should have NO other privileges, such as NON-CNCL,
SECURITY, TAPE-BLP, or READALL. The id should not have any other system
authority, such as TSO, IMS, CICS, or JOB. The UID should not match any file
access (i.e.. the UID fields should all be blank).
A listing can be generated by using an ACFRPTSL against the backup files as
follows:
IF(REFRESH AND NOSUSPEND AND NOCANCEL) SF(REFRESH,UID)
8. Using the "LIST IF" command or the SL report, examine all User-ID
records to determine which users have the MAINT attribute. These users are
allowed to execute any program defined in MAINT GSO.
9. Using the "LIST IF" command, examine all User-ID records to determine
which users have the TAPE-BLP attribute. These users are allowed to a tape
data set without rule verification. Determine if TAPE-BLP is used to gain
access to tape files. Only the Tape librarian has an ongoing need for this
privilege.
The ability to use LABEL=(,BLP) is controlled by ACF2 to ensure that only users
with this privilege can use the privilege. The TAPE-BLP privilege is assigned
to individuals. Earlier in this handbook, the BLPPGM was described. In this
area, the individual's authority to use BLP to access any tape, using any
program is reviewed.
>From a listing of all User-IDs with the TAPE-BLP privilege, determine the
appropriateness of the privilege, by referring to the authorization maintained
by data security. Each occurrence of the privilege is to be approved by the
Operations Manager of the data center, with a reason for its need.
In most facilities, the Tape Librarian has a justifiable need for the
privilege. Often the Software groups, especially, the Tech Support groups feel
they need the privilege because they are constantly receiving files from
vendors and have no way of knowing the filenames on these tapes. The files
received from the vendor should be quite limited and may be handled with a
short term request for TAPE-BLP privilege.
In most cases, TAPE-LBL, which is a limited TAPE-BLP privilege will suffice.
TAPE-LBL allows the user to use BLP, but if the label is a Standard label, will
validate the user's authority to use the file anyway.
The listing can be generated by using an ACFRPTSL against the backup files as
follows:
IF(TAPE-BLP AND NOSUSPEND AND NOCANCEL) SF(TAPE-BLP,NON-CNCL,UID)
10. Determine the appropriateness of users with the OPERATOR privilege. This
privilege on its own has little implications, but many products like SDSF, and
JES2 use the OPERATOR authority to give higher authority within their product.
Originally, OPERATOR privilege was a TSO attribute which allowed users to issue
Status commands and Cancel commands. Very little significance could be
attached to users with this privilege. Determine the appropriateness of the
user's with OPERATOR privilege. Verify that each occurrence of the privilege
has been properly authorized. Verify that all users with OPERATOR are system
software people, or have data center operations responsibility. Note that
there is no limitation as to what can be canceled by the users. Messages
showing the cancellation of jobs do not include the User-ID of who did the
cancel.
If a review of SDSF and/or JES2 is not being conducted during this audit, it is
important to evaluate the additional privilege provided by these products.
Both products usually give any user with OPERATOR full console authority, with
the ability to issue most console commands, including starting started tasks
and issuing modify commands. These are some of the main reasons for limiting
physical access to the computer room in the past. By requiring people in the
software groups be escorted in the Computer Room, the Operations manager has
control of commands issued on the console which could effect the operation of
his system.
In the near future NetView will have similar capabilities. Some of these may
not even need the user to have OPERATOR!
The listing can be generated by using an ACFRPTSL against the backup files as
follows:
IF(OPERATOR AND NOSUSPEND AND NOCANCEL) SF(OPERATOR)
11. Generally, IMS and CICS User-IDs have no need to run in batch. Review the
User-IDs defined as IMS or CICS User-IDs with the JOB attribute. These
User-IDs can be used in batch jobs if rules are written to give access to data.
The JOB attribute is the privilege comparable to the TSO, IMS or CICS
attributes which determine if the User-ID is allowed to run TSO, IMS or CICS.
JOB determines whether you are authorized to use the batch environment. JOB is
validated only if JOBCHK has been initialized in the OPT parameter in the GSO.
JOB is particularly important in an environment where there are a large number
of users requiring access in an on-line environment only. These users can be
prevented from using their User-ID in batch jobs if they do not have the JOB
attribute.
If the JOB attribute is not being used, we do not necessarily have a problem.
Determine if the organization depends on users not being able to use batch, as
a control. An environment which claims to have ACF controls to prevent access
in batch, but do not use JOB with JOBCHK, is not fully controlled.
12. Review User-IDs with the JOBFROM attribute. Verify that these User-IDs
are also defined as MUSASS. Determine how User-IDs are inserted in the jobs
submitted by these regions.
User-IDs are used to identify users of the system to ACF2. ACF2 verifies the
identity of each user by requesting a password known only to the valid user.
Sometimes, when production jobs are being submitted, a password is
impractical. In these cases, the identity is verified, by determining the
program used and the authorization of the program (SUBAUTH). On rare occasion,
SOURCE may also be used to verify that the User-ID is appropriate.
In a multi-user environment (MUSSAS), there is another unique requirement to
have a User-ID approved for use by ACF2. In a MUSASS like CICS, ACF2 only
knows the identity of the region. If a job is submitted by a user of the
region, ACF2 has to be told by the region which User-ID is to be used. It is
impractical to require each user to include a password when submitting a job.
A feature has been designed to allow a MUSSAS to pass a User-ID to jobs using
the JOBFROM statement.
FORMAT: /*JOBFROM T2HJWJV
Since anyone could insert this in their JCL, an additional privilege was added
to allow a MUSSAS to use this (JOBFROM). JOBFROM tells ACF2 that this User-ID
has already been validated within the region or job. This review, is intended
to verify the appropriateness of the JOBFROM attribute. Only User-IDs with the
MUSSAS attribute should have the JOBFROM attribute. Review how the JOBFROM
User-ID is determined. If the user is allowed to insert his own /*JOBFROM,
there is a significant exposure.
Imagine, a TEXT user being allowed to insert a JOBFROM User-ID of any User-ID
he wishes. ACF2 would assume the User-ID is okay since the CICS region has the
JOBFROM attribute. NOTE, TEXT has an appropriate job submission routine which
inserts the user's own User-ID only, in the JOBFROM record. TEXT should only
be a concern if the region is not controlled by ACF2.
If JOBFROM is on an id which is not a MUSSAS, review the source of the job
doing the job submission to determine how the /*JOBFROM record is generated,
and how the User-ID is validated.
13. Review User-IDs with the NO-SAF attribute. Verify these User-IDs are also
defined as MUSASS and STC or RESTRICT.
User-IDs with the NO-SAF attribute can access data via program products using
SAF (e.g. DFDSS, DFHSM, BDT) without validating dataset rules. Products using
explicit ACF2 interfaces like CICS or IMS will call ACF2 for dataset rule
validations, unless NON-CNCL or MAINT was also granted. Compensating controls
for MUSASS User-IDs such as STC or RESTRICT (with SUBAUTH and PGM, or SOURCE)
should be used.
Rules for System Software
Purpose: To review the ACF2 access rules for system software.
1. Use the DECOMP command to decompile the SYS1 rule set. Review the ACF2
access rules to determine that the ACF2 distribution libraries can only be
accessed by the system programmer(s) assigned to ACF2 support.
The integrity of ACF2 among other things depends on the adequacy of rules over
the ACF2 distribution files. These datasets need to be protected against
unauthorized modification and only people with a business need to know should
be able to read them. The MACRO libraries contain file definitions
(SYS1.ACFMAC). These file definitions give enough information to give users
with access to APF libraries the ability to bypass ACF security. Note that
many of the datasets have 2 versions of the information. SYS1.ACFMAC and
SYS1.ACFAMAC are identical versions of each other. Access to both should be
strictly limited and should be similar.
2. Determine that libraries containing ACF2 load modules are adequately
protected. Write and Allocate access to the production version should be
logged and restricted to emergency situations only.
This aspect of the ACF2 program need not be reviewed if MVS is also being
reviewed. The ACF2 load libraries are in 'SYS1.LPALIB' and 'SYS1.LINKLIB'. If
this review is a stand-alone review of ACF2, it is important to determine the
adequacy of controls over the programs running ACF2. Review the rules to
determine who can modify the system datasets and 'SYS1.ACFMOD' and
'SYS1.ACFAMOD'. Only the system program responsible for the MVS system and the
ACF2 software should be able to change these libraries.
Only the ACF2 systems person should have write authority to the MOD libraries
(these would also be reviewed in question 1 of this section).
ACF2 security is only as good as the software used to run it. If the software
can be indiscriminately modified, ACF2 cannot be relied upon.
3. Determine if any user other than Data Security can change the rules for
SYS1 or ACF2 by the use of %CHANGE and %RCHANGE.
The rules for SYS1 or ACF2 are reviewed in this section to ensure that current
controls are adequate to ensure the integrity of the ACF2 system. When ACF2 is
controlled Centrally, only SECURITY privilege can change rules, unless the
%CHANGE record is present in the rule. If current controls are adequate and
the %CHANGE is present, there is no assurance that they will stay adequate. If
it is not present, only SECURITY users can change the rules, and adequacy of
change controls over rules are covered later in this review.
In reviewing the rules for %CHANGE, its existence does not imply there is a
problem. The User-ID mask should be reviewed to determine the appropriateness
of users with the ability to make rule changes for system and ACF2 files.
Normally, only Data Security can change rules. No other group has a job
responsibility to do so.
4. Determine that the System Management Facility (SMF) files (SYS1.MAN*) used
for ACF2 logging are adequately protected. WRITE and ALLOCATE permission should
be limited to emergency situations only. Allocate permission should be logged
and restricted to the system programmers responsible for SYSGENs. Ensure that
the same level of protection is present for the dump datasets, both tape and
disk.
ACF2 uses the System Management Facility (SMF) files to store information used
for an audit trail. All ACF2 logging is stored on the SMF files. The
information needed to restore the current database is stored on the SMF files.
The change history is stored on SMF. All reports produced by ACF2 come from
information stored on SMF.
As a result the information here must be carefully controlled to ensure that no
one can change this information. Keep in mind that if there are system
problems relative to SMF data, someone has to be able to fix it. The backup
files or the files used to store SMF after it is dumped should be as closely
controlled as the live files. Ask the system programmers to identify the
datasets names for all versions of the SMF data. Review the rules for all of
these.
If SMF is covered in MVS review, it may not be necessary to cover it here.
Ensure that the files reviewed in MVS, include all collected SMF.
5. Ensure that ACF2 rules grant access on a need to know basis.
ACF2 rules are generally written based on the data owner's requests. Data
Security should always write access rules as requested. However, if a customer
requests access which is obviously not limited to only user's with a defined
need to know, Data Security has an obligation to inform the customer of the
consequences of the general access granted.
Data Security also writes rules for new TSO users. A default set of rules is
written unless otherwise specified. Review these default rules to determine if
access to user's libraries is limited on a "need to know" basis.
6. Determine the names of the production systems libraries, APF libraries,
IMS and other production program product libraries, and production JCL
libraries. Ensure that controls over these resources are adequate.
This is normally covered in the MVS review, but should be covered here if MVS
is not being reviewed.
The adequacy of ACF2 depends on the integrity of MVS to be intact. MVS
integrity has been assured by IBM provided mechanisms under the users control
are adequately controlled. APF authorization is one of the main bypass
mechanism under the users control. Other powerful libraries (normally APF
authorized) include IMS and production load libraries. Determine that the ACF
rules limiting access to these authorized libraries are reasonable.
The libraries used to contain JCL for production jobs should also be closely
reviewed to ensure the appropriateness of production jobs being used.
7. Check the GSO OPTS record, NOSORT fields. If NOSORT is in effect,
verify that all rule sets containing a $NOSORT control card accurately reflect
access permissions. If NOSORT=NO is in effect, there should not be any $NOSORT
entries.
ACF2 ADMINISTRATION
Purpose: To review the adequacy of ACF2 administration.
1. Review the controls over changes to the ACF2 databases. Ensure that all
changes are properly authorized. Verify that a management review of changes to
ACF2 is conducted to ensure only authorized changes are performed.
The ACF2 database can be updated only be user's with the SECURITY privilege.
Data Security requires all changes to be supported by an authorization from the
owner.
The intent of this audit step is to perform a review of changes made to the
ACF2 databases to ensure that all changes are authorized. To do this, perform
the following:
o Determine what change controls are in place to ensure only authorized
changes are included. Specifically, if changes are made to the rules (dataset
or resource), using a stored copy of source rather than a decompile just
previous to the change, determine what controls are in place to ensure:
o there is only one copy of the source;
o no other changes were made to the source by some other user
(trojan horse);
o no changes were made to the database using
ACFNRULE command or decomp and store;
o only authorized users can write to the source
file.
In essence, if a PDS containing original source is being used, there
should be a change control procedure similar to that used for production
program change controls for all changes to the ACF2 rules.
o If all changes have been properly authorized, there should be a way of
referencing the authorization when the change occurs. Take a sample of changes
(explained below) and request the Data Security administrator to provide you
with the authorizations.
o Determine if there is a management review of ACF2 change reports
conducted. There should be a daily review by management or an independent
party to ensure changes to the databases are authorized. It doesn't make sense
to review all changes daily, but a reasonable sample of changes made should be
done, at least weekly. This would be even more significant if during the
sample done above, any situation was identified which did not have supporting
authorization.
The reports that should be reviewed by an independent person includes:
ACFRPTLL - User-ID Modification Log - identifies the fields that were
changed, if DETAIL was requested.
ACFRPTRL - Rule-id Modification Log - identifies the rules that were
changed and by who. Currently, no detail is available in this report (Planned
for a future release). However, ACFRPTIX can be run to show full detail
resulting from a given modification.
ACFRPTEL - Info Storage Update Log - identifies the resource rules,
ENTRY's, GSOs, SCOPEs, and SHIFTs changed. If DETAIL is requested the fields
changed will be displayed were possible.
To sample the changes, run each of these reports using the collected SMF for a
sample period. One week, just prior to the review period should be sufficient.
Additionally, the Data Security group should be reviewing the following reports:
ACFRPTJL - Restricted User-ID Job Log - identifies usage of User-IDs
without passwords. Should be examined to determine appropriateness of usage;
ACFRPTPW - Invalid Password Authority - identifies invalid attempts
to sign-on. Should be used to identify any attempts to hack the system.
2. Determine that Data Security is reviewing and actively following up
potential problems with ACF2 logging and violation reports for:
o abuse of privileges;
o attempted hacking; and
o conversion to ABORT mode.
Data Security has a responsibility to review the reports caused by logging or
violations. Primarily, logging should be reviewed to determine if there is an
abuse of privileges granted, such as EID, NON-CNCL, READALL, or SECURITY.
Additionally, if the logs are as a result of a conversion, these logs should be
reviewed to ensure the timely completion of such plans.
The violations should also be reviewed by the Data Security group for several
reasons. Violations are the result of failed attempts to access information.
Data Security should be using this as an indication of problems in ACF2
administration, to determine their effectiveness. They should also use these
to determine if there was a breech of security. Trends in attempted access
should be observed. A series of violations on sensitive datasets indicate a
possible fishing expedition. It should be noted however, that the violations
are accesses which did not happen, while the logging are for things that did
happen.
User Exits
Purpose: To review ACF2 user exits.
1. Using the SHOW ACTIVE command, determine which exits are in use on each
system. Review the source code for each. Cross reference compile date and
load module size with SYS1.LPALIB contents. Note any discrepancies.
There are now 19 exits available for a site to alter the way in which ACF2
works. Each of these exits can be used to bypass the security mechanisms in
the system if inappropriately written. The auditor should review the source
for each module and verify that the source matches the load module.
EXIT usage can be determined by reviewing the GSO records for all systems. The
commands to do so are:
ACF
SET CONTROL(GSO) MSYS(-)
LIST EXITS
END
2. Review the source for any exits in use to verify they perform as
intended. Verify the exit usage is well documented as to the purpose and
effect on the system.
If any exits are in use and the source listing has been verified to be the
original source, review the source to ensure that it is functioning as
intended. Any exit in use should be explicitly documented as to the purpose of
the exit and what the exit does. If it isn't, the site cannot be assured of the
integrity of their security system. Remember, any exit can be used to
circumvent the controls in ACF2.
Other Products Under ACF2
Purpose: To review other products that relate to ACF2.
1. If Innovation Data Processing's Fast Dump Restore (FDR) is used, determine
if the ACF interface is being used to verify authority to access information.
FDR and FDRDSF are products which are used to dump and restore information at a
volume level and/or a dataset level. When a disk is dumped at a volume level,
FDR bypasses normal open. This gives the user the ability using FDR to dump
onto a tape he has access to any file on any volume. The Dataset Facility
allows any user to restore any file previously dumped, to any file he has write
access to. ACF2 validation only occurs on the file being written to. This
facility therefore gives the user the ability to get READ access to any file
regardless of ACF2 rules preventing it.
The ACF2 vendors recognized this weakness some time ago, and have developed an
interface which provides additional levels of control. Before allowing the
user to dump a volume, the interface determines the users authority, by calling
ACF2 to validate access to VOLUME.@volser (or @volser.VOLUME, depending on
options selected). When restoring a dataset, the interface verifies the user's
authority to read the original dataset name given in the control parameters,
before allowing the file to be
restored.
To determine if the ACF2 interface has been implemented, BROWSE the load
modules for the FDR.... programs, looking for references to ACF. If they don't
exist, the interface has not been installed. It may also be prudent to look
for rules for VOLUME or @volser. If these are not present, the interface
should be questioned (determine how access is allowed).
However, similar rules are used in other interfaces, so the existence of them
does not imply the interface is installed.
Some installations have protected the FDR programs using an exit to validate
usage of programs. Others have put the FDR programs in a fully protected
library to limit their use to only appropriate DAMART users. This may be an
acceptable alternative to using the exit provided the controls prevent copying
to another name and library.
2. If Cambridge Systems Group's ASM2 is used determine if the ACF$AUTH code is
present. Verify that only authorized ASM2 commands are present.
Cambridge Systems Group (now Computer Associates) have developed a Space
Management System which provides archive and retrieval mechanisms to make
maximum use of storage space. ASM2 performs tasks on behalf of the user,
bypassing user authentication. ASM2 was distributed by the same group as ACF2
and has been distributed with an ACF2 interface which performs additional ACF2
calls to ensure the user is authorized to perform the tasks requested.
The ASM2/ACF2 interface is distributed as a Selectable Unit and must be
installed to make it work. If ASM2 is being used, interview the MVS group, the
Utilities group and the DAMART group to determine if the ACF2 interface was
installed during the last distribution implementation.
3. If Sterling's Disk Management System (DMS/OS) is used, determine if the
vendor supplied ACF2 interface has been applied.
Sterling's Disk Management System is designed to provide programs to archive
and restore datasets on the system, making more efficient use of the disk space
available. To do this, DMS/OS runs as a sub-system or Started Task and needs
access to all data on the system. When a dataset is aged sufficiently, DMS/OS
programs remove the dataset from the disk and store it on a tape file. If the
dataset is required, DMS/OS programs retrieve the data from the tape and
restore it on disk. Some additional features allow for a dataset to be renamed
during the retrieval process. Since DMS/OS does all of these functions on the
user's behalf, the user's authority to access these dataset names is never
validated by ACF2. This allows a user to access a file which has been archived
and restore it to his high-level, even if he does not have access to the
original file.
Sterling has recognized this weakness in their product and has created an
additional Selectable Unit. The site must specifically install the SU to take
advantage of this feature. The SU performs some additional ACF2 calls to
ensure the user's authority to access both the original and final datasets
before any action is taken by DMS/OS to archive or restore files.
4. If IBM's Hierarchical Storage Manager (DFHSM), Data Set Services (DFDSS),
or Bulk Data Transfer (BDT) are installed and not protected by PGM resource
rules, verify SAFPROT entries are present.
These three IBM program products require a SAFPROT record for dataset rule
validation to occur (regardless if SAF VALIDATION = ON and no generically
masked SAFSAFE record exists).
The SAF PROTLIST entries can be determined by reviewing the GSO records for
all systems. The commands to do so are:
ACF
SET CONTROL(GSO) MSYS(-)
LIST LIKE(SAF-)
END
Entries should resemble the following:
SAFPROT.DFDSS CLASS(-) CNTLPT(ADR-) SUBSYS(ADR-)
SAFPROT.DFHSM CLASS(-) CNTLPT(ACR-) SUBSYS(ACR-)
SAFPROT.BDT1 CLASS(-) CNTLPT(BDT-) SUBSYS(SVC019)
SAFPROT.BDT2 CLASS(-) CNTLPT(BDT-) SUBSYS(SVC099)
SAFPROT.BDT3 CLASS(-) CNTLPT(BDT-) SUBSYS(SVC109)
SAFPROT.BDT4 CLASS(-) CNTLPT(BDT-) SUBSYS(BDT-)