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