Backuping 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
2011年4月21日 星期四
Backuping and restoring a single table using mysqldump
2011年4月17日 星期日
Add a counter column in a query
Sometimes I’ve needed to add a counter column in a query and I don’t want to add the column with php, so I’ve found this query to put the counter directly in the record set returned out from the query.
1. set @N = 0;
2. SELECT @N := @N +1 AS number, name, surname FROM people;
To use it in PHP scripts you have to use 2 query statements:
1. mysql_query("set @N = 0;");
2. $rs = mysql_query("SELECT @N := @N +1 AS number, name, surname FROM people");
3. while ($r=mysql_fetch_array($rs)) {
4. echo $r['number']." - ".$r['name']." ".$r['surname'];
5. }
1. set @N = 0;
2. SELECT @N := @N +1 AS number, name, surname FROM people;
To use it in PHP scripts you have to use 2 query statements:
1. mysql_query("set @N = 0;");
2. $rs = mysql_query("SELECT @N := @N +1 AS number, name, surname FROM people");
3. while ($r=mysql_fetch_array($rs)) {
4. echo $r['number']." - ".$r['name']." ".$r['surname'];
5. }
2011年4月12日 星期二
Omegamon/MVS Review
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.
MVS Operating System Review
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
MVS audit program
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 *
//
ACF2 auditor checklists part 2
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-)
ACF2 auditor checklists part 1
Following was contributed by (Rey LeClerc) at rey@mass-usa.net
Part 1 of 2
ACF2/MVS (Access Control Facility) Security System
Purpose: Determine whether the ACF2 software has been appropriately installed
in the MVS environment. Determine if access to system software, files and
commands is controlled and appropriately restricted. Determine if chosen exits
permit circumvention of intended controls.
Overview
ACF2 was developed by Schrager Klemens and Krueger, Inc. (SKK) for large IBM
computers. Computer Associates currently markets the product. (Cambridge
Systems Group, Inc. originally marketed ACF2. UCCEL Corporation bought them
out and were, in turn, bought out by Computer Associates in 1987.)
ACF2 supports the MVS, VS1, VM, and VSE operating systems and the TSO, JES,
CICS, IMS, and IDMS subsystems. The current ACF2 version is release 5.0 for
MVS environments.
ACF2 acts as an interface between users, programs and data, and "defined
resources" to provide a mechanism by which data access and manipulation take
place in a controlled environment. Defined resources are those components
under ACF2 control, such as programs, Customer Information Control System
(CICS) transactions, and Information Management System (IMS) transactions.
ACF2 protects all data by default. This means that access to the system by
anyone besides the "owner" is only possible when authorized by the data owner
or by a security officer.
Each system user is identified to ACF2 by a unique "User-ID." The User-ID
provides individual accountability for all system activities. ACF2 also
creates a User-ID record, which contains information about the user--such as
name, privileges, type of user and statistics about the user's activities on
the system. In this way, ACF2 can play an important role in implementing
controls over access to programs and data files.
ACF2 also provides audit trails and reports on who accessed what data and on
the maintenance of the security system. These can be supplemented by other
types of information retrieval software.
ACF2 places intercepts in the MVS and VS1 operating systems and in the
subsystems. Requests for access to resources is evaluated using ACF2 access
and resource rules. Access is either allowed or denied and a SMF record is
created if logging is specified. Control is then passed back to the operating
system and subsystem originating the request for access.
There are three ACF2 data bases (VSAM key sequenced data sets): User-IDs,
Access Rules, and Information Storage. The User-ID data base controls system
access validation. Users are defined to ACF2 via a unique User-ID record that
specifies the user's privileges, TSO attributes, and access history.
User-ID record fields are defined in the ACF2 Field Definition Record
(ACFFDR). Fields can point to records in the Information Storage data base.
The Access Rule data base contains one record (rule set) per high-level index
(qualifier) for each data set. The rule set defines the conditions for access
to data within that high-level index. The levels of access allowed are READ,
WRITE, ALLOCATE, and EXECUTE. Each type of access may be allowed (A), allowed
but logged (L), or prevented (P). The default is prevent.
The Information Storage data base identifies input sources (terminals),
identifies privileged user scopes, contains rules to control access to
resources (i.e.., IMS, CICS, and IDMS), and contains Global System Option (GSO)
records. GSO records specify all system-wide options except those defined in
the ACFFDR.
Source of ACF2 information:
Coopers & Lybrand Software Newsletter, Volume 4, No. 1, Spring 1984,
"Exploring ACF2", pp. 15-17.
ACF2 Auditors Guide
ACF2 Administrators Guide
MIS Training Institute The 7th Annual Conference on Control, Audit and Security
of IBM Systems, "Reviewing the Implementation and Administration of ACF2,"
Session 38, presented by James Richardson, Senior Internal Review Analysis,
Ford Aerospace & Communications Corporation.
Components of ACF2
Purpose: To ensure that components of ACF2 are adequately installed.
1. Review the catalog entry for the primary ACF2 databases. Use TSO "LISTC
ENT(dsn) ALL" to determine that each component is:
o uniquely named;
o adequate size;
o periodically reorganized; and
o NOT VSAM password protected.
The dataset names for the databases can be found by issuing a SHOW DDSN or SHOW
ACF command under TSO on any of the shared systems. To view the condition of
the VSAM files it may be advisable to put the results of the LISTC into a
dataset. To do this do the following:
o create a dataset using TSO ISPF 3.2
o RECFM=VBA
o LRECL=255
o BLKSIZE=6250
o DSN=acf.listc (any dataset you choose)
o In function 6 of ISPF, allocate the file as follows:
o ALLOC FI(DD1) DA(acf.listc) MOD
o Perform the catalog list for each of the Primary Databases
o LISTC ENT('ACF2.RULES') ALL OF(DD1)
o LISTC ENT('ACF2.LOGONIDS') ALL OF(DD1)
o LISTC ENT('ACF2.INFOSTG') ALL OF(DD1)
By Uniquely named, we mean:
o The DATA and INDEX components should be explicitly defined with a
explicit name;
o The high-level of the databases should be different from any other VSAM
files; and
o The definition of the VSAM files should have specified the attribute
UNIQUE.
The need for a unique name comes from the ability to control access to the VSAM
files. If the DATA and INDEX components are not explicitly defined, access to
the databases can be attained by the VSAM default names beginning with Z9999992
or Z9999996. If the high-level of the dataset name is the same as some other
VSAM files, the access controls become very difficult to administer.
If the VSAM file was not defined with the UNIQUE attribute, the VSAM cluster
may be shared by other VSAM datasets and the possibility exists that data
sharing could also exist.
The adequacy of the size of the database is very subjective and should be
evaluated using the following formula:
From the LISTC for each file, get:
o HI-ALLOC-RBA assign it to A
o HI-USED-RBA assign it to B
o CISIZE assign it to C
Formula is (A - B) / C
___________ = # of unused tracks
11
if the database is on 3350 disk replace 11 with 4 in the formula.
If the database is not large enough, the database will have to be reorganized
more frequently. An indication of size problems will be a high number of CA/CI
splits. This is also an indication that the database is not reorganized
frequently enough.
The CI split number can be significantly higher without concern than the CA
splits. CI splits over 1000 or CA splits over 100 should raise some concern.
However, the numbers alone should only be an indication of a problem. If a
database is reorganized regularly and these numbers are still high, the problem
is either a very high volume of activity, or the database may need to be
differently defined.
Regular reorganization if important to ensure the availability of ACF2. VSAM
errors have been shown to increase significantly if CA and CI splits are high.
Without reorganization, the possibility exists that a user may not be able to
be added. This problem occurred frequently when NETIDS were all being added as
ids. The VSAM keyed dataset was evenly distributed among all User-IDs. When a
large number of ids are added in the same range, there are a number of CA
splits which occur. After a number of splits, no more splits can occur,
resulting in some specific ids not being able to be added.
VSAM passwords are a valuable feature to enhance the security controls of a
VSAM space. VSAM passwords are frequently used to control access to files that
are not always in an ACF2 controlled environment. There is a tendency to try
password protecting the ACF2 VSAM files to ensure they are protected when ACF2
is not active. However, if a password is used, the recoverability of a
database, may be severely impacted if the password is not known by the
operations staff. If the password is known by the operations staff, the
desired effect of controlling access is lost as the potential accessors are the
operations staff.
2. Repeat the above review for the Alternate databases.
The Alternate databases should be identical to the Primary, with the following
exceptions:
o The Alternate files could be allocated with less free space than the
primary, since the Alternate should never be used productively for long periods
of time in which many inserts are processed;
o The Alternate file names should be different from the Primary. The
high-level index should be different and on a different catalog. This would
allow the alternate files to be used in the event that a catalog error
occurred.
o The Alternate files should reside on a different volume than the
Primary. This volume should ideally also be attached to a different
controller. This would ensure the availability of ACF2 in the event of either
a Volume error or a controller error.
o If the files either Primary or Alternate are being backed up using FDR,
it is advisable for the catalog to be on the same Volume as the VSAM space.
The catalog entry for a VSAM
space much be in sync with the file itself, otherwise, the VSAM file may
not be usable.
Alternative clusters may include SYS1. ACF2. ALTLIDS, SYS1.ACF.ALTRULES, and
SYS1.ACF2.ALTRULES. (Note that they may be under a different high level index).
3. Examine the SYS1 (or appropriate high level index) rule set to determine
if the three non-VSAM backup data sets (SYS1.ACF.BKLIDS, SYS1.ACF.BKRULES, and
SYS1.ACF.BKINFO) are accessible only to ACF2 and the ACFRECVR recovery job
(which would be controlled by operations). Verify that the BACKUP and
alternate BACKUP files exist. Determine if an automatic backup is performed at
about the same time as SMF is dumped.
The BACKUP file names used by ACF2 for backup procedures can be found by
issuing a SHOW DDSN sub-command of ACF under TSO. These files should exist or
the backup procedures may not be effective.
ACF2 provides for the ability to automatically backup the ACF2 databases at any
time of the day. The GSO BACKUP records describe to ACF2 when to perform the
backup and on which machines. BACKUP parameters can be determined by reviewing
the GSO records for all systems. The commands to do so are:
ACF
SET CONTROL(GSO) MSYS(-)
LIST BACKUP
END
The recovery procedures for an ACF database requires a reload of the backup
file to the VSAM file, and a restore of activity since the last backup using
the SMF data collected since the backup. If the SMF data is not dumped at
about the same time as the ACF database, the backup procedure will become very
cumbersome as some of the recovery information may be on the live SMF files
while the rest is on a disk or tape file. This could cause a significant delay
in system availability.
4. Determine if the Alternate Clusters are recreated and maintained current
using the results of the nightly backup. Verify the automatic procedures exist
on a procedure library and are only initiated on one machine per set of
databases.
The procedure defined in the GSO BACKUP record should exist. Review the
system Procedure libraries for this procedure. If it doesn't exist, determine
how the site keeps its Alternate files current? If the Alternate files are not
kept current, how do they plan to get the system back if a fatal error occurs
on the ACF Databases?
If an old copy of the primary file has been kept on the Alternate, the site may
have a problem using it. Say for example that the Alternate is 2 months old,
ask, "what was your password 2 months ago". This normally drives the point
home. If it doesn't, suggest that even if they know what their password is,
would the hundreds of user's trying to get on know theirs?
Review the procedure used to keep the Alternate Clusters current. If the
procedure simply restores the backup files into the Alternate Cluster, without
first deleting and recreating the datasets, review the contents of the
Alternate files (there will be old ids which have been deleted from the
Primary). When a VSAM restore is performed, using a backup file, records found
on the backup will be replaced. Records on the Alternate files not found on
the backups will remain on the Alternates. Therefore, any deletes performed on
the primary files will not be deleted from the Alternates.
Verify that the backup is performed on only one system. If the backup is
performed on multiple systems at about the same time a contention problem may
cause problems with system availability.
5. Use the DECOMP command or the cross reference report to check the rules
for the ACF2 system files. Verify that the rules allow only full scoped
security officers to access the primary ACF2 files, and that write access is
not allowed. Review the ACF2 rules for the databases. Ensure that only the
ACF2 system support people have access to the above stated files.
The system programmers responsible for ACF2 should have WRITE and ALLOCATE
access to the Primary and Alternate VSAM files. But, all access should be
logged and justified when such logging occurs. They are the ones who will have
to recreate the databases when more space is required or when a recovery is
required.
The procedure used to recreate the Alternate clusters, needs similar access to
the Alternate files.
Data Security does not need access to these files under any circumstances.
When updating the databases, ACF2 accesses the files on their behalf, so they
don't need access. ACF2 does not need access either, as ACF2 opens the file
before it is fully active and therefore no validation is performed.
Access to the databases should be tightly controlled, as the system
availability may be compromised. If a user has allocated the databases, ACF2
cannot access them, as ACF2 needs to have exclusive access.
6. Examine the SYS1 rule set to determine that the SYS1 rule set to
determine that the ACF2 distribution libraries may only be accessed by the
system programmer assigned to ACF2 support. Files included are SYS1.ACFMAC,
SYS1.ACFMOD, and SYS1.ACFOBJ.
7. Review the ACF2 rules for the backup files. Ensure that only the
recovery procedure (from a controlled library) can update the files. Allocate
access should be limited to only the ACF2 system support people.
Access to the backup files can be much more loosely controlled than access to
the databases, as the system availability is not in question.
WRITE or ALLOCATE access should be strictly controlled to ensure that the
integrity of the backup files cannot be compromised. The backup and recovery
procedures need this kind of access and the system programmer(s) responsible
for ACF2 also needs it. When individuals have WRITE access all such access
should be logged and strictly reviewed.
READ access may be allowed to any user with the need to scan the user User-IDs
and some information about users of the system.
8. Review the ACF2 FDR compile listing. Verify that the listing being
reviewed matches the current SHOW ACF. Differences indicate the FDR listing is
not the one currently in use.
This feature is intended primarily to ensure that the listing used in the next
series of questions is in fact the actual source used in the generation of the
current ACF2 system. If the site has kept the original compile listing of FDR
(most desirable), the only check that is needed here is to compare the SHOW
STATE or SHOW ACF sub-commands to the compile date/time and compile size to the
listing. If this is identical, no further check is required.
Otherwise, use the SHOW ACF & SHOW FIELDS sub-commands to list all the features
and parameters currently active. Several of these include:
o UID string content;
o Fields defined (SHOW FIELDS);
o SVCs used;
o Dataset names used for databases & backups;
o contents of header line in User-ID list;
o SMF record types;
If there are any discrepancies in any of these areas, the listing you are
looking at is not the one being used.
9. Using the "SHOW STATE" command, verify that started tasks are controlled
by ACF2 (i.e. STC=ON).
10. Using the "SHOW STATE" command, verify that access to tape datasets is
controlled by ACF2 (i.e. TAPEDSN and TAPEBLP in the OPTS GSO record).
11. Using "SHOW STATE", determine that all disk dataset names are protected
by ACF2 (i.e. specified as ******).
12. Using "SHOW STATE", check the appropriate GSO option to determine if
passwords are adequately controlled by ACF2. For example MINPSWD(5) to enforce
that all User-ID passwords have a minimum of 5 characters.
13. Determine which fields are being used to make up the UID string. Verify
that these fields may only be changed by SECURITY personnel.
Use the ACF2 sub-command SHOW STATE or SHOW ACF to list the fields which make
up the UID string. The results will include a line entitled "UID STRING=".
Each field name described here should be reviewed specifically in the listing
of the FDR compile reviewed earlier. The fields are being reviewed to identify
who can change each of these fields ( look for ALTER= ). Only users with
SECURITY or ACCOUNT should be able to change any of these fields.
Additionally, the RESTRICT attribute should be on each of the definitions.
If any of the fields can be changed without the SECURITY and/or ACCOUNT
privilege, the integrity of the system is questionable. The UID string is the
backbone of access authorization in an ACF2 system. Anyone who can change the
content of any part of the UID string can change the access given to a user.
The RESTRICT attribute in this situation requires the SECURITY or ACCOUNT
User-ID making the change to be FULL SCOPE, meaning that this id cannot be
limited in any way.
14. Examine the @CFDE entries in the FDR comparing to the vendor supplied
defaults. Determine that local modifications do not materially weaken security
or control. Note any exceptions.
A difference may not necessarily be a concern. Evaluate the impact of the
difference by referring to the ACF2 Administrator's Guide for a definition of
the field and it's purpose.
The areas of most concern in the CFDE definitions are:
o field name defines how it is referenced in the User-ID record;
o ALTER= defines who can change the contents;
o FLAGS= defines any restrictions.
A definition of the various FLAG restrictions can be found in the ACF2 System
Programmers manual. The most commonly used FLAG is the RESTRICT flag which
requires the Changer to be FULL SCOPE.
15. Determine if ACF2 PTFS, TUMS and other maintenance is performed using
SMP. Verify that distributed fixes for integrity exposures are applied in a
timely manner.
The vendor periodically issues program fixes which are identified as fixes for
integrity exposures. Normally, there is little or no more explanation about
the fix.
16. Determine how distribution and maintenance files (tapes) are controlled.
Is the information designated as critical and adequate physical security
applied?
Each site will get the ACF2 software distributed to them in a different
manner. Some get it direct from the Vendor, others get it transmitted to them.
The purpose of this review is to determine how the site has established control
over the distributed software to ensure that the integrity of the original
files remain intact and to ensure recoverability if the down-loaded files are
damaged. The software should be considered a proprietary product and
appropriately controlled to ensure no copies of the software are left around
where it could be copied. Access controls for the files should be adequate to
ensure only the system programmer(s) responsible for the product can access it.
ACF2 Settings
Purpose: To review settings of ACF2 to ensure that ACF2 has been adequately
installed.
1. Review the GSO records to determine if any disk volumes are omitted from
ACF2 control (RESVOL).
ACF2 allows for a partial control to be invoked by specifying a parameter which
allows you to control only certain volumes of disk. The parameter is the RESVOL
parameter, specifying a mask or series of masks which are to be controlled at a
dataset name level.
RESVOL parameters can be determined by reviewing the GSO records for all
systems. The commands to do so are:
ACF
SET CONTROL(GSO) MSYS(-)
LIST RESVOLS
END
It could be necessary to exclude some disk volumes from dataset name validation
if, the dataset names on that volume are not standard MVS dataset names. ACF2
verifies that MVS dataset naming conventions are adhered to. Some products
exist which do not conform to MVS dataset names. For example, some products
use 10 position level names. ACF2 does not allow this. For the product to run
on an ACF2 controlled environment, the volumes that these dataset reside on
must not be protected at a dataset level.
However, no dataset on those volumes are controlled. Review the content of any
volumes that are excluded from the RESVOL list. The datasets on the volumes
are free for all users of the system. Any production datasets on these volumes
are uncontrolled and should be criticized.
2. Review the GSO records to verify that Started Tasks are controlled by
ACF2 (STC=ON).
When ACF2 is installed, only disk datasets in a batch or TSO environment are
controlled unless ACF2 is explicitly told otherwise. Operator Started Task
Commands (STCs) are not controlled until the option is turned on in the GSO.
The STC parameter can be determined by reviewing the GSO records for all
systems. The commands to do so are:
ACF
SET CONTROL(GSO) MSYS(-)
LIST OPTS
END
The OPTS parameter will either have STC or NOSTC. If NOSTC, any started task
can be run. No access validation will be performed for any STC. In most
environments, an operator will initiate any STC upon request without any
questions asked. Anyone with write access to any of the PROC libraries can
insert or change any started task.
In any ACF2 controlled environment, dataset integrity depends on the STC option
being used.
3. Review the GSO records to determine if tape access is controlled at a
dataset level (TAPE-DSN=YES).
When ACF2 is installed, only disk datasets in a batch or TSO environment are
controlled unless ACF2 is explicitly told otherwise. Tape datasets by default
are not initially controlled until the option is turned on in the GSO.
The TAPEDSN parameter can be determined by reviewing the GSO records for all
systems. The commands to do so are:
ACF
SET CONTROL(GSO) MSYS(-)
LIST OPTS
END
The OPTS parameter will either have TAPEDSN or NOTAPEDSN. If NOTAPEDSN is
invoked on any system, then tapes will not be ACF2 protected. Any user will be
able to read or write any tape file.
4. Review the GSO records to determine if ACF2 is in ABORT mode on all
systems. (Optionally, RULE,ABORT,ABORT may be acceptable).
ACF2 allows for progressive control of the resources. To do this a MODE has
been established. This MODE should not be confused should not be confused with
the MODE operand in the User-ID record. The User-ID MODE defines the option
which causes ACF to return a "?" or "ACF, LID, RESOURCE, etc." when awaiting
input. The system MODE determines what ACF2 does when a violation is
encountered.
The possible system MODEs are:
QUIET No dataset access will be denied or reported;
LOG All dataset access will be allowed and violations will be
logged;
WARN All dataset access will be allowed, violations will be logged
and a message sent to the user informing him of future failure;
RULE,x,y Selective mode. "x" could be either QUIET, LOG, WARN or ABORT.
It determines what action is to be taken if no rule exists with the KEY
specified. "y" could be either QUIET, LOG, WARN or ABORT. It determines what
action is to be taken if no $MODE card is found in the rule.
ABORT All dataset access which is not allowed by a rule is prevented
and a log of the attempt is generated.
The desirable MODE is ABORT, however, a MODE of RULE,ABORT,ABORT may be
acceptable is no critical keys have the $MODE card allowing access.
The MODE parameter can be determined by reviewing the GSO records for all
systems. The commands to do so are:
ACF
SET CONTROL(GSO) MSYS(-)
LIST OPTS
END
5. Review the GSO records to determine if Quick Logon is not permitted for
TSO (QLOGON=NO).
TSO can optionally allow a user to sign-on using a quick logon. This means
that the user can specify his/her User-ID and password on the same line. The
problem with this is that the password is in clear text and can be observed by
anyone watching. Since ACF2 depends on individual accountability, password
integrity must be above reproach.
The TSO parameters can be determined by reviewing the GSO records for all
systems. The commands to do so are:
ACF
SET CONTROL(GSO) MSYS(-)
LIST TSO
END
The options are QLOGON or NOQLOGON. QLOGON is the default. NOQLOGON is the
desirable option. The TIME parameter specifies the default CPU time allowed
per session. A TIME of 1440 is a key time which causes the SMF time-out
parameter to be ignored. If 1440 is the default, users without a TSOTIME
parameter will never be logged off because of inactivity. Review the
compensating controls before criticizing the unit for this feature. Limited
access to the physical terminal may be a compensating control.
6. Determine if any programs have been identified as able to use BLP. If
so determine if they could be used to circumvent normal controls. (BLPPGM=)
ACF2 controls the use of LABEL=(,BLP) or Bypass Label Processing. When BLP is
specified in a DD statement of JCL, MVS is instructed to not compare the
FILENAME on a tape file to the DSN in the JCL. When BLP is used, no validation
of actual dataset name occurs, and therefore no ACF2 rules are examined.
Anyone using BLP can access any tape file on the system in any way he wants
without control or audit trail.
ACF2 provides the option to verify an individual's authority to use BLP, but it
also provides the ability to allow any user to use BLP depending on the program
being used. This is not necessarily a bad feature provided the programs
function does not allow the user to get access to information not normally
allowed. An example of a program which should be given this authority, may be
one which dumps the header records from all files on a tape. An example of a
program which should not be given this authority, is a program that copies a
tape to another file with a different name.
The BLPPGM parameter can be determined by reviewing the GSO records for all
systems. The commands to do so are:
ACF
SET CONTROL(GSO) MSYS(-)
LIST BLPPGM
END
The purpose of any program identified here should be closely examined. General
utilities like IEBGENER or WAAPDSUT should never be defined here. Ask the
utilities group to define the functions programs defined here can perform.
7. Review the libraries defined in any of the GSO records as LINKLIST.
Verify that these libraries are controlled at least as well as "SYS1.LINKLIB".
Program pathing is a feature introduced by ACF2 during early releases of the
product. It was unique to ACF2, and provided an added level of control which
no other security product had incorporated. During early releases of ACF2,
program pathing had some technical problems which were difficult to overcome.
These problems related to identifying the library a program was executed from
when STEPLIB or JOBLIB was used by the user. ACF2 would lose track of which
library in the concatenation the specific program was executing from.
To overcome these problems, ACF2 program pathing rules were generally written
to use 'SYS1.LINKLIB' as the library source for programs. This implied to ACF2
any library defined in the system LINKLIST. Later releases of ACF2 allowed the
Security Officer to add additional libraries to ACF2's list of libraries to be
considered as members of the LINKLIST, even though MVS did not. This
introduced an exposure, when libraries defined here were not as well controlled
as the system libraries.
Each library added to this list degraded the intended control of program
pathing by introducing additional libraries that the programs could come from.
The LINKLST parameter can be determined by reviewing the GSO records for all
systems. The commands to do so are:
ACF
SET CONTROL(GSO) MSYS(-)
LIST LINKLST
END
Examine this list. Determine the controls over modification of each library.
Ensure that each is at least as well protected as the SYS1.LINKLIB dataset.
Ideally, only SYS1.LINKLIB will be defined here. It is likely that all members
of the system linklist are defined also. Any more should be strongly
discouraged.
8. Determine that the PASSWORD control options in place are consistent with
suggested parameters below. Investigate discrepancies.
o minimum length is 5 (MINPSWD=5);
o standard encryption is used (ENCRYPT=XDES);
o 3 retries per session (MAXTRY=3);
o suspended after 6 violations (PASSLMT=6);
o forced after password reset by SECURITY (PSWDFRC);
o batch attempts are counted (PSWDJES).
PASSWORD control is one of the best features available in ACF2. For the first
time, users can be required to be responsible in their choice of passwords and
in maintaining them. The features described above include:
MINPSWD - The minimum length a user can use when providing a new password
to ACF2.
ENCRYPT - Which encryption technique to be used when encoding the
password on the User-ID database. In releases prior to version 2.2.1, the
vendors of ACF2 were using their own encryption routine for storing the
password. In later versions, the Data Encryption Standard was incorporated.
But the old version was still supported. ACF2 has continued to support the
old version.
MAXTRY - The maximum number of times a password can be entered
incorrectly before having to start the sign-on process over.
PASSLMT - The number of invalid password attempts allowed in a single day.
If this number is exceeded, the User-ID will be suspended until reactivate by a
SECURITY user.
PSWDFRC - This parameter forces a user to change the password if it has
been changed or observed by a SECURITY User-ID.
PSWDJES - Optionally, an ACF2 system can be allowed to not count password
violations if they are encountered in the batch environment.
The PASSWORD parameters can be determined by reviewing the GSO records for all
systems. The commands to do so are:
ACF
SET CONTROL(GSO) MSYS(-)
LIST PSWD
END
Verify these standards are being observed to ensure users are being responsible
in the administration of passwords.
9. Determine MAINTENANCE programs are appropriate for the user's job
responsibilities. Verify that only controllable programs are used. General
utilities such as IEHPROGM, IDCAMS, and IEBCOPY should never be included.
One mechanism which can be used to allow system software or data center users
to perform their job without giving them NON-CNCL privilege or requiring access
rules to be written for every dataset in the shop is MAINTENANCE.
The MAINT parameters of the GSO describe programs, libraries and User-IDs which
are allowed to access any data without rules, because the programs have been
identified as maintenance programs which perform a specific controlled
function. The functions are normally for archival and retrieval of data or
reorganization of space.
It is very appropriate for system software to have MAINT records defined for
them. In this review, we are looking at the programs defined as MAINT programs
to verify that they are for a specific purpose and cannot be used to manipulate
information for other purposes. For this reason, programs like IEHPROGM,
IDCAMS, and IEBCOPY or any other general utility program should not be used as
MAINT programs. This is not to say they cannot be used, but should not be used
as MAINT.
Additionally, it is important that other accounts are not given the MAINT
privilege to avoid writing rules. MAINT gives total access to all data for
read or write. An account like Florida Title XIX was given WAAPMCOP as a MAINT
privilege. This is a general copy utility which gave them the ability to copy
any file to any other file without logs. This should not have been allowed.
Another situation to look for, is the existence of MAINT programs in libraries
which are not well protected. If the user with the privilege has write or
allocate access to the library identified in the MAINT record, then the desired
control is lost.
10. Determine JOBCK is defined to ensure that each user must have the JOB
parameter to be able to use their User-ID in the batch environment. This may
not be significant if all users should be able to run in batch.
The JOBCHK is a parameter comparable to the TSO LOGONCHK which determines if
the checking is to be done to determine if a User-ID can be used in batch jobs.
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 JOBCHK parameter 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.
The JOBCHK parameter can be determined by reviewing the OPTS GSO records for
all systems. The commands to do so are:
ACF
SET CONTROL(GSO) MSYS(-)
LIST OPTS
END
The record will either contain JOBCHK or NOJOBCHK.
11. Determine SAF VALIDATION is ON to ensure program products using SAF will
validate dataset rules.
The SAF VALIDATION establishes if User-IDs calling a program product using SAF
will verify ACF2 dataset rules for access. The SAF VALIDATION parameter can be
determined by reviewing the ACTIVE GSO records for all systems. The commands
to do so are:
ACF
SET CONTROL(GSO) MSYS(-)
SHOW ACTIVE
END
The record will either contain SAF VALIDATION = YES or NO.
Account Privileges
Purpose: To review the account privileges for ACF2 and system software.
1. Using either the LIST command or the Super List (ACFRPTSL) report
generator, display a sample of User-ID records. Verify that the password
expiration parameter (MAXDAYS) of the password group is used and is no greater
that 90 days. Review the User-IDs required to use a password. Verify that
each must change the password at least every 90 days (normally 30).
Recognizing that the Account Manager likely has many other important things to
remember, and that it is possible for the manager to forget, procedures should
exist which would identify those situations which indicate that a User-ID is
not being used. User-IDs which have not been used in more than 3 months are
not likely needed.
2. Review User-IDs not requiring a password. Verify that each is controlled
by the SUBAUTH and PROGRAM parameters. Determine the effectiveness of PROGRAM
masks used. Alternatively a controlled SOURCE may be acceptable (NEVER
STCINRDR or INTRDR).
ACF2 depends on individual accountability to authorize any access to the
resources it protects. To do this it must have some way of ensuring that a
user is who he claims to be. For people using on-line applications, it is
practical to request a password known only to them. For batch applications,
some other means of verifying the authority is required. ACF2 has currently 3
訂閱：
文章 (Atom)