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-)