C ONTRIBUTED 11/29/00 BY RICHARD KIMBLE RICHARD.KIMBLE@NISSAN-USA.

COM

RACF SECURITY REVIEW

ENTER DATE HERE

DETAIL AUDIT PLAN

Prepared By: Date:

name
Title

Approved By: Date:

Name
Title
 ENTER COMPANY NAME HERE

Internal Audit Department

RACF Security Audit
Detail Audit Plan

Objectives:
The purpose of this review is to determine how the Resource Access Control Facility (RACF) is utilized and administered.
More specifically, the review will:
• determine how effectively RACF has been implemented
• ensure adequate procedures exist, and are practiced, for notification of employee terminations, authorization changes,
issuance of user-ids and passwords
• ensure all production libraries, their members, and datasets are protected by RACF
• ensure Password Encryption is in effect and meets the Data Encryption Standard (DES).
• ensure special attributes are justified and used sparingly
• determine whether group structure is flexible and accommodates decentralization

Scope:
This review focuses only on RACF as it applies to THE COMPANY’S computing requirements.

DONE
AUDIT STEPS TO BE COMPLETED BY W/P REF

A. Administrative Section

1. Prepare a Strategic Audit Plan for the area(s) or function(s) to be reviewed.

2. Prepare a Detail Audit Budget for the area(s) or function(s) to be reviewed.

3. Prepare an engagement letter for the area(s) or function(s) to be reviewed. Address the
letter to the appropriate level of management. Request copies or access to information
necessary to begin work on the review. This information includes but is not limited to:
Ø Policies and procedures and system user manual.
Ø Reports concerning the activity, i.e. special projects, studies, other audit reports.
Ø Organizational charts from CEO down to area(s) being reviewed
Ø Job descriptions
Ø Flow charts
4. Prepare audit issues. Discuss audit issues and recommendations with appropriate
management personnel.
5. Determine the reporting structure from the area(s) to be reviewed up to the CEO.

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

1 / 21
 RACF Security Audit

DONE
AUDIT STEPS TO BE COMPLETED BY W/P REF

B. General Overview Section

Objective(s): Gain a general understanding of the RACF environment at this installation.
Identify hardware configurations, system libraries, RACF protected datasets, etc.
1. Determine who is responsible for installing, monitoring, and maintaining RACF.

2. Obtain a copy of the installation's security policy, procedures, and dataset and user-id
naming conventions.
3. Obtain a user-id with the "AUDITOR" attribute. Include all members of the audit team.

4. Interview the security administrator to identify the resources protected by RACF and those
that are not. Document the overall protection scheme as described by the security
administrator. Verify the scheme throughout the review.
a. Identify and document the extent of resources protected by RACF (e.g. volumes, files,
programs, transactions, commands, etc.). Use the DSMON – Class Descriptor Table
report and check with System Support’s list of applications on the mainframe.
b. Document resources either not protected or not fully protected by RACF. Include what
protection is available for those resources and who is responsible for administering the
security.
NOTE: Before executing any Internal Audit RACF jobs, meet with Security Administration to
ensure the jobs will not adversely affect computer operations. Sample JCL listings are
in the Appendices. IBM's "RACF Auditors Guide" should be used for reference, too.
5. Generate RACF DSMON and SETROPTS reports. These reports provide a ‘blueprint’ of
RACF security at the installation and must be kept secure. Bear in mind both of these
reports are dynamic and are only a snapshot of the system at a point in time.
a. DSMON -- Use either the TSO batch JCL supplied in Appendix C Exhibit 1 or have
the Security Administrator run one for you. A user with the ‘AUDITOR’ attribute can
execute the report. This report should be run by Auditing to ensure independence,
integrity and completeness. If anyone outside the Auditing Department runs the report,
you must be present when the report is submitted for execution and released to the
printer.
b. SETROPTS -- Use the TSO batch JCL supplied in Appendix C Exhibit 2. You can
review the report on-line anytime by entering the command "SETROPTS LIST" at the
TSO/ISPF TSO command prompt.

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

2 / 21
 RACF Security Audit

DONE
AUDIT STEPS TO BE COMPLETED BY W/P REF

C. Review Policies and Procedures

Objective(s): To ensure adequate policies and procedures exist for the administration of the
security administration function and RACF
1. Ensure the RACF security can only be removed by appropriately authorized personnel (e.g.
security administration) and its removal is reported to MIS Management. Review and
evaluate control of the command (RVARY) used to deactivate RACF or switch RACF
database files. No special authority is required to issue the RVARY command. However, a
password must be entered at the master console to approve use of the command.
a. Ensure the default RVARY password has been changed (use the SETROPTS report).
b. Ensure the RVARY password is changed regularly and only authorized personnel know
or have access to the password.
c. Ensure computer operators have procedures outlining use of the RVARY command.
2. Review the procedures/criteria for assigning the "SPECIAL", "OPERATIONS", or
"AUDITOR" attributes to users/groups.
3. Review the Employee Confidentiality and Non-Disclosure policies for adequacy. These
policies address disclosure of company data to outside sources.
a. the policies and agreements specify that THE COMPANY computer resources are
intended for THE COMPANY business only.
b. Determine whether employees are required to review and sign documents stating they
understand and will comply with the policies.
4. Review the procedures for issuing new user-ids and passwords for adequacy. These
procedures should not be limited to permanent, full-time employees. Contractors,
consultants, and temporary and part-time employees must be included.
5. Determine if procedures exist to ensure users have logged on since being issued their user-id.
User-ids that are not immediately logged on to are susceptible to unauthorized use because
default passwords are the user's default group. Refer to audit step E-4 for aging of
user-ids that have not been used (logged on).
6. Ensure procedures exist to age the user-ids by last access date and revoke as necessary.
Evaluate the procedures for adequacy. Policy should require the revocation of user-ids that
have not been used for a period greater than the SETROPTS Inactive User-id Revoke
Settings. Refer to audit step E-5 for aging of user-ids.
7. Review procedures for resetting the password on revoked user-ids.

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

3 / 21
 RACF Security Audit

DONE
AUDIT STEPS TO BE COMPLETED BY W/P REF

8. Ensure procedures exist, and are practiced, to notify security administration of user
authorization changes. These procedures address authorization changes resulting from a user
changing department, being promoted/demoted, etc. The procedures should not be limited
to permanent, full-time employees. Contractors, consultants, and temporary and part-time
employees must be included.
9. Ensure procedures exist, and are practiced, to notify security administration of terminations.
The procedures should not be limited to permanent, full-time employees. Contractors,
consultants, and temporary and part-time employees must be included. As a minimum, the
following should be addressed.
a. Revocation of user-ids the day of termination.
b. Automatic revocation of user-ids when termination date is known in advance. For
example, a pre-determined end date is generally known well in advance for contractors,
consultants and temporary workers. Look for use of REVOKE DATE being set for any
user-ids.
c. Removal of the user-id from the system as soon thereafter as practical. Test by
identifying recently terminated users and verifying the associated user-ids have been
removed from the system. As a minimum, the user-ids should be revoked.
10. Determine if adequate procedures are in place to delete user-ids from all groups and from
specific dataset profiles when a user-id is deleted from the system. Ensure all user-ids
connected to groups/datasets or owning groups/datasets are defined to RACF.
D. Review of the Program Properties Table (PPT)
Objective(s): Review the Program Properties Table (PPT) section of the DSMON to ensure all
programs do, in fact, exist, are justified, and Technical Services and RACF Administration
are aware of the entries.
1. Review the PPT to ensure all programs are valid entries. Identify odd entries and justify their
existence with RACF Administration and System Support. Resources in the PPT that don't
exist can be used by other programs as a means of "piggy-backing" to greater authority.
Refer to Appendix D for a listing of known PPT entries and their description. Update the
Appendix with any THE COMPANY installation specific entries for future audits.
2. Ensure CICS is in the PPT. If CICS is not in the PPT it will be paged out of memory thus
slowing system response time.
3. Justify the need for programs to have "BYPASS PASSWORD PROTECTION = YES"
with Systems Support and Security Administration. Refer to Appendix D for a list of
programs where "YES" is allowed. The programs DFHSIP (CICS) and IEBGENER (copy
utility) should not be set to "YES". Bypass Password Protection = YES means the program
will bypass RACF authorization checking to any datasets and bypass SMF logging.

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

4 / 21
 RACF Security Audit

DONE
AUDIT STEPS TO BE COMPLETED BY W/P REF

E. Review of User-ids and Passwords

Objective(s): Ensure user-id and password processing options prevent passwords from being
easily compromised and that user-ids are given minimum required access to
datasets/resources. This include the administration of user-ids.
1. Review the “Password Processing Options” and “Inactive User-ids” entries on the
SETROPTS report to determine the reasonableness of:
a. the password change interval.
b. generations of previous passwords being maintained.
c. unsuccessful password attempts before a user-id is revoked.
d. password expiration warning period.
e. password syntax rules.
f. the number of days before an inactive user-id is automatically revoked.
2. Verify the default user-id "IBMUSER" has been "REVOKED" and has no special attributes
(SPECIAL, OPERATIONS, AUDITOR). If not revoked, test that the password has been
changed from the default of "IBMUSER".
3. Review for user-ids with the password interval set to "N/A" which means no password
change is required. The password change interval at the user-id level overrides the default
interval controlled by SETROPTS.
4. Identify user-ids that have never been used (no logon date). Determine the reason the
user-ids have never been used. User-ids that are not immediately logged on to are
susceptible to unauthorized use because the default password is the user-id’s default group.
Refer to audit step C-5 for review of policies and procedures related to this.
5. Age the RACF user-ids and produce a listing of user-ids with 30, 60, 90, and over 120
days of inactivity. Determine if these user-ids status is "REVOKED" and action taken to
determine the need for maintaining the user-id. Aging user-ids can be accomplished online
using either Vanguard RACF Administrator (VRA) reports or the RACF command
"SEARCH NOMASK CLASS(user) AGE(30)". This command will list all user-ids that
have not been used for 30 days. Refer to audit step C-6 for related review of policies and
procedures.

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

5 / 21
 RACF Security Audit

DONE
AUDIT STEPS TO BE COMPLETED BY W/P REF

6. Identify all user-ids with the "SPECIAL", "OPERATIONS", or "AUDITOR" attributes.

Justify the need for these attributes with Security Administration. These attributes should be
used sparingly. The DSMON "Selected User Attributes Report" provides this information.
"OPERATIONS" allows the user-id update and create access to all files.
a. Ensure systems programmers and computer operators do not have the "SPECIAL"
attribute. Systems Programmers should have an emergency user-id with the
"SPECIAL" attribute.
b. Ensure user-ids do not have both "SPECIAL" and "OPERATIONS" attributes.
c. Determine whether the user can perform duties without these attributes.
d. Ensure UAUDIT is turned on for all user-ids with the "SPECIAL", "OPERATIONS", or
"AUDITOR" attributes.
7. Review for user-ids that do not adhere to the installation's naming conventions. Pay
particular attention to unusual user-ids such as "SUPRUSER", "IGOTYOU", or "ZAPPER".
F. Review of Dataset Profiles
Objective(s): To ensure access to critical data files and programs is restricted to appropriate
personnel.
1. Ensure access to critical application data files is restricted based on job responsibilities.
Start with the high-level qualifiers and work to more detail.
2. Ensure access to all production and load libraries are secured. Identify and justify user-ids
with access, and the access level, to production libraries.
3. Review the DSMON Global Access Table report for appropriate levels for each entry.
Ensure the Global Access Table does not override intended security for a particular dataset.
Refer to the RACF order of access checking diagram in the RACF Audit Basic Information
file.
4. Ensure access to the SYS1.LPALIB and SYS1.LINKLIB libraries is restricted to only
authorized users.
Ø SYS1.LPALIB - contains RACF modules and exits that are loaded into the link pack
area during IPL using a procedure called CLPA (create link pack area).
Ø SYS1.LINKLIB - contains RACF modules.
5. Determine if the "TAPEVOL" class is active by reviewing the SETROPTS report. If the
TAPEVOL class is not active, tape datasets are not RACF protected.

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

6 / 21
 RACF Security Audit

DONE
AUDIT STEPS TO BE COMPLETED BY W/P REF

G. Review of the Group Structure and Group Profiles

Objective(s): To ensure the RACF implementation utilizes a group structure to ease
administrative overhead and maintain security system integrity.
1. Review the group structure to determine its flexibility and ability to accommodate growth and
ease administration. Groups are useful in delegating security officer responsibility to the
owners of the data.
2. Review the group profiles to ensure each group is owned by superior groups. Utilizing group
ownership of sub-groups facilitates scope of group authority for security officers.
3. Ensure users do not inadvertently have access to resources by reviewing the scope of group
authority of their connect groups. User-ids with the Group Special, Group Operations, or
Group Auditor attributes for a group has that authority for all subgroups of that group.
4. Identify user-ids with CONNECT or JOIN group authority. Gain an understanding of their
job description then determine if the authority is appropriate in relation to the group.
H. Manageme nt Control
Objective(s): To ensure security reports are generated and reviewed by security administration.
Further ensure action is taken by security administration to correct the situation.
1. Review the reports used by Security Administration for adequacy.
a. Determine the frequency of the reports produced, who reviews them, and whether
corrective action is taken.
b. Ensure reports are utilized to document access violations and improve the everyday
administration of the system.
2. Ensure there is adequate documentation of additions, changes (departmental/application),
and deletions of RACF user-ids.
3. Ensure RACF functions are being recorded in SMF data (record type 80). Determine how
long the data is retained and whether the retention period is adequate.
4. Ensure undefined users accessing TSO are identified with a user-id of 8 plus (+) signs
(++++++++) by reviewing the SETROPTS report entry "USER-ID FOR JES
UNDEFINEUSER IS:".
5. Ensure there are no entries in the Authorized Caller Table. This information can be found in
the DSMON "Authorized Caller Table" report. The Authorized Caller Table is not
adequately controlled by RACF and should not be used.

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

7 / 21
 RACF Security Audit

DONE
AUDIT STEPS TO BE COMPLETED BY W/P REF

I. RACF Exits
Objective(s): To document and ensure all RACF exits are properly controlled to ensure the
integrity of the RACF environment.
NOTE: Chapter 8 of IBM's "System Programming Library: RACF" can be used as a
reference for an understanding of the exits function.
1. Review the DSMON "RACF EXITS REPORT" for any exits. Consult System Support and
Security Administration on the purpose and justification for the exit. Also, determine and
evaluate who is allowed to maintain exit routine code (both source and load form). Refer to
Appendix E for list of known RACF exits and their purpose. Generally, the report should
state that "NO RACF EXITS ARE ACTIVE".
2. Ensure the Data Encryption Standard (DES) is used to encrypt passwords. To guarantee
DES encryption is being used there should be no password exit. Check the RACF EXITS
REPORT to determine if a password exit is used. Although the RACF exit ICHDEX01 is
the DES encryption it does not guarantee that DES encryption is in effect. If an exit is used
ensure the return code is set to ‘8’
J. RACF Database Security
Objective(s): To ensure the datasets used by RACF to store security information are secure
from unauthorized access and controls are in place to prevent unexpected failure. Also,
ensure backup and recovery procedures for the RACF databases are sufficient to facilitate a
prompt resumption of access control.
1. Identify and justify user-ids with access, and the access level, to the RACF databases.
Determine if access level is appropriate. The dataset names for the RACF databases can be
found in the “Selected Data Sets Report” section of DSMON report.
2. Review the DSMON report (Selected Data Sets Report) to determine if the RACF
databases (primary and backup) are maintained on separate DASD units. The databases
should be on separate DASD units to provide backup capabilities in case of DASD failure.
3. Review the datasets information for the RACF databases to ensure the primary database is
smaller than the backup database. Since both databases are concurrently updated this
prevents the backup database from crashing along with the main database when the allotted
space is exceeded.
4. Determine the frequency of backing up RACF system and its databases. Also, review the
procedures for rotating backup RACF files to the off-site facility. Evaluate whether the
timeliness and security of the rotation is adequate.

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

8 / 21
 RACF Security Audit

DONE
AUDIT STEPS TO BE COMPLETED BY W/P REF

K. CICS Interface
Objective(s): To ensure RACF and CICS parameters are set to ensure RACF security is
active for CICS
1. Determine if the CICS regions are set up in the APPL resource class. If not, evaluate if
using APPL will provide additional security.
L. Review of the Started Task Table (STC)
Objective(s): To ensure programs listed in the STC are adequately controlled.
1. Review entries in the RACF Started Procedures Table Report of the DSMON to identify
programs with the Privileged or Trusted attribute. Programs with these attributes should be
justified. Both attributes cause all RACF exits, checking, and statistics to be bypassed for
RACHECK and RACDEF supervisor calls (SVC). The Privileged attribute also bypasses
SMF logging whereas Trusted will log based on the SETROPTS LOGOPTIONS setting.
2. Review the RACF Started Procedures Table Report to determine if there is a Procedure
Name entry of '*'. If so, verify that there is an Associated User or Associated Group
defined for the entry.
M. Review of TSO and SYS1.UADS Security
Objective(s): To ensure user access to system facilities via TSO is secured by RACF and
based on job responsibilities.
1. Ensure the SYS1.UADS file is protected by RACF and evaluate the appropriateness of
user-ids with UPDATE access to SYS1.UADS.
2. Identify user-ids with access to TSO via SYS1.UADS. Ensure the RACF user-ids are the
same as the user-ids in the SYS1.UADS file.
a. Determine the exposure if a user-id is defined in SYS1.UADS but not to RACF.
NOTE: User-ids defined in the TSO SYS1.UADS file, but not to RACF are allowed access to
TSO. However, access to RACF-protected files and resources is only granted at the
universal access (UACC) level for the file/resource.
3. If TSO resources are in the RACF database ensure the TSO general resource class is
active. Verify this by ensuring that the "ACTIVE CLASSES" section of the SETROPTS
report includes TSOPROC, ACCTNUM, PERFGRP, TSOAUTH.
4. Identify user-ids in the SYS1.UADS file or RACF (TSOAUTH option) with the
"ACCOUNT" attribute and verify for appropriateness. The ACCOUNT command and
subcommands are used to create and to update the entries in the user attribute data set
(SYS1.UADS), and simultaneously, the broadcast data set (SYS1.BRODCAST).
End Of Audit Steps

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

9 / 21
 Appendix A RACF Security Audit

Appendix A
How To Read Dataset Profiles

1. For data files under review, obtain "Data Set Profiles" for each by using the RACF command:

LISTDSD DA('data-set-name') ALL

Note - If generic profiles are used to protect the significant profiles, use:

LD PREFIX('highlevel-qualifier') ALL

If data set profiles do not exist for any data set under review, the data set is not protected by RACF. For data files
not RACF protected, determine an alternate method of protection is used and develop procedures for testing.

2. Using the data set profiles, determine whether the universal access (UACC) is appropriate. This should normally be
"NONE" for production data files.
• Obtain explanations where critical files have UACC of UPDATE, ALTER and CONTROL.
• Evaluate if UACC of "read" is appropriate (e.g., password data set should not have UACC of READ).

Note - If fast path RACHECK (FRACHECK) is used for access checking, do not perform steps 3 and 4 as
FRACHECKing bypasses logging to the SMF data set.

3. Using the data set profiles review the WARNING parameter. Warning specifies that even if access authority is
insufficient, RACF is to issue a warning message and allow access to the resource. RACF records the access in the
SMF log if logging is specified. If the WARNING indicator is on (i.e., YES) through discussion with Security
Administration or Systems Support determine if:
• the warning is appropriate
• there is follow-up to warnings

4. Ensure that the owner of the data set profile is appropriate (should be a group and not an individual). The data set
owner has complete control over the maintenance of the data set profile. Other maintenance controls will be tested
in the segregation of duties section.

5. If a user-id has UPDATE access to a PDS (e.g., program library), it can delete and add members (datasets) to the
PDS.

6. Using the data set profiles, review the AUDITING parameter for appropriateness.

Note - Auditing specifies which access authority will be logged in the SMF log. The options are:
• ALL - logs both successful and unsuccessful accesses
• SUCCESS - logs successful accesses
• FAILURES - logs unsuccessful attempts

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

10 / 21
 Appendix A RACF Security Audit

• NONE - no logging (this would not be appropriate)

• The access levels are:
• READ
• UPDATE
• CONTROL
• ALTER

• The default value is FAILURES (READ). This would normally be appropriate. At a minimum AUDITING should
be set to FAILURES (UPDATE).

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

11 / 21
 Appendix B RACF Security Audit

Appendix B
RACF Global System Resource Options (SETROPTS)

RACF Global System Resource Options (SETRPOTS)

Information Requirements

• Obtain a list of RACF system-wide environment parameters. Using the SETROPTS LIST command, obtain a
listing of the resource options (SETROPTS). Refer to the RACF Security Administrators Guide chapter 6 for
details.

1. Review and evaluate the RACF System Resource Options (SETROPTS).

Special attention should be given to the following parameters:

SETROPTS report shows:

1. ATTRIBUTES =

a. Bypass RACINIT statistics (INITSTATS/NOINITSTATS)

INITSTATS - records logon activity statistics in the user profile. NOINITSTATS indicates no recording of the
above. Without INITSTATS being in effect the REVOKE, INACTIVE, HISTORY and INTERVAL options
cannot be activated.

b. Bypass logging of activity of user-ids with the SPECIAL attribute (SAUDIT/NOSAUDIT)

SAUDIT - indicates that all commands issued by user-ids with the SPECIAL attribute are to be logged. If
NOSAUDIT is specified, no logging of the above actions will be recorded.

c. Bypass logging of RACF command violations (CMDVIOL/NOCMDVIOL)

CMDVIOL - logs violations of the use of RACF commands by unauthorized user-ids. NOCMDVIOL
indicates no logging of the above activity and would not be appropriate.

d. Logging activities of user-ids with the OPERATIONS attribute OPERAUDIT/NOOPERAUDIT)

OPERAUDIT - this option logs all accesses to RACF protected resources granted because the user-id has the
OPERATIONS attribute and all uses of the ADDSD and REDEFINE commands issued by a user-id with the
OPERATIONS attribute.

2. STATISTICS = 'list'. This is the list of resource class names for which RACF is to record statistics. Review
management's selections for appropriateness.

3. Logging RACF command and RACDEF activity. AUDIT CLASSES = 'list' user-ids with the AUDITOR attribute
can request RACF to log all detected accesses to the profiles on the RACF data set by RACF commands or the
RACDEF macro routine for specified classes. All appropriate resources should be listed.

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

12 / 21
 Appendix B RACF Security Audit

4. Activating RACF protection for general resource classes. ACTIVE CLASSES = 'list'. To provide RACF access
authorization checking for general resources in the RACF Class Descriptor Table (CDT), the resource class must be
activated with the CLASSACT operand. This list should include all protected resources.

5. Security classification checking allows an installation to impose an additional level of access control checking using
security level and/or security categories.

6. Generic profile checking allows the activation of generic profile checking for specified classes of resources.

7. Global access checking allows the activation of global access checking for either specified classes or all classes of
resources.

8. Bypass automatic data set protection (ADSP/NOADSP)

NOADSP - if MVS ALWAYS CALL in effect or if PROTECTALL option is set.

9. Use of real data set names in messages and SMF records (should be active). This will allow for easier follow-up
for trouble shooting.

10. JES batch job identification - JES-BATCHALLRACF should be active. JES-XBMALLRACF should be active.
This ensures that batch jobs are assigned a user-id and gain access based on that user-id, not universal access
authority. Depends on local installation approach to RJE type jobs.

11. JES early verification - depends on local installation approach to RJE type jobs.

12. RACF PROTECTALL option for data sets should be set to 'in effect'. This ensures that all data files must have a
rule for user-ids to gain access, except for user-ids with the SPECIAL attribute. If the facility is still implementing
RACF this might be acceptable as 'not in effect'.

13. Tape data set protection. Must be set to 'active'. This ensures RACF maintains tape data set protection.

14. Security retention period for tape data sets. Should be set to 9999 days. This ensures that RACF protection
remains in effect until the tape retention expires.

15. Erasure of scratched DASD data sets. This option could cause heavy overhead if used extensively, but might be
appropriate for certain files. Discuss with the security administrator.

16. RACF protection for data sets with single-level names. Depends on installation standards of allowing single level
names.

17. List-of-groups access checking. Will affect review of access rules - discuss with security administrator.

18. Automatic revoke of inactive user-ids. Should be set to revoke user-ids after at least 90 days of inactivity.

19. Password processing options:

a. INTERVAL - should be 60 days or less.

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

13 / 21
 Appendix B RACF Security Audit

b. HISTORY - should be at least 2.

c. UNSUCCESSFUL ATTEMPTS - should be 3 or less.
d. SYNTAX RULES - should be 'length' (min 5), character content should not be restrictive.

20. RVARY passwords for SET and SWITCH should not be default (YES). The computer operator must enter the
password at the master console for command to execute.

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

14 / 21
 Appendix C - Exhibit 1 RACF Security Audit

Appendix C
TSO Batch JCL
Exhibit 1 - JCL to produce a RACF DSMON report.

***************************** TOP OF DATA ******************************

//jobcard goes here
//********************************************************************
//* :
//* JOBNAME : RFJC0002
//* :
//* DESCRIPTION : THIS JOB PRODUCES A RACF DSMON REPORT. ALL
//* : AVAILABLE REPORTS ARE GENERATED.
//* :
//* : REFER TO THE RACF AUDITORS GUIDE FOR ASSISTANCE.
//* :
//* WRITTEN : JANUARY 29, 1992
//* WRITTEN BY : RIC KIMBLE
//* SYSTEM : RACF
//* PROGRAM : ICHDSM00 – IBM RACF DSMON (DATA SECURITY MONITOR) RPT
//* :
//* INPUT FILES : NONE
//* :
//* OUTPUT FILES: NONE
//* :
//* REPORTS : RACF DSMON REPORT
//* :
//********************************************************************
//*
//STEP01 EXEC PGM=ICHDSM00
//SYSPRINT DD SYSOUT=X
//SYSUT1 DD DSN=SYS1.PARMLIB,DISP=SHR
//SYSUT2 DD SYSOUT=X
//SYSIN DD *
LINECOUNT 55
FUNCTION ALL
//*
//********************************************************************
//* END OF JOB *
//********************************************************************
/*
**************************** BOTTOM OF DATA ****************************

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

15 / 21
 Appendix C - Exhibit 2 RACF Security Audit

Appendix C
TSO Batch JCL
Exhibit 2 - JCL to produce a RACF SETROPTS report.

***************************** TOP OF DATA ******************************

//jobcard goes here
//*
//*********************************************************************
//* :
//* JOBNAME : RFJC0001
//* :
//* DESCRIPTION : TSO BATCH JOB TO GENERATE A RACF SETROPTS LISTING.
//* : OUTPUT IS WRITTEN TO FILE SPECIFIED IN JOBSTREAM
//* :
//* WRITTEN : 1/27/98
//* WRITTEN BY : RIC KIMBLE
//* :
//* SYSTEM : RACF
//* PROGRAM : IKJEFT01 - IBM SETROPTS REPORT
//* :
//* INPUT FILES : NONE
//* OUTPUT FILES: NONE
//* :
//* REPORTS : RACF SETROPTS REPORT
//*******************************************************************
//*
//STEP01 EXEC PGM=IKJEFT01,DYNAMNBR=30
//SYSTSPRT DD SYSOUT=X
//* SYSTSIN DD DISP=SHR,
//* DSN=userid.SETROPTS
//*
//SYSTSIN DD *
SETROPTS LIST
//*
//*******************************************************************
//* END OF JOB
//*******************************************************************
/*

**************************** BOTTOM OF DATA ****************************

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

16 / 21
 Appendix D RACF Security Audit

Appendix D
Standard Program Properties Table (PPT) Entries

Have RACF Administrator and/or System Support review this list and the list in the RACF Workshop manual for
validity. Update list to reflect appropriate settings for future reviews.

Bypass Password System

Program Description Program Name Protection Key
VLF COFMINIT NO NO
DLF COFMISDO NO NO
XCF - Cross System Coupling IXCINJST NO NO
MMS - MVS Message Service CNLSSDT NO NO
IOS IOSVROUT NO NO
APPC ATBINITM NO NO
ASCH ATBSCHIN NO NO
SDFM Utility ATBSDFMU NO YES
APPC Message Log Writer ASBSCHWL NO YES
NET CENTER PNV1000 NO YES
JES2 HASJES2A NO YES
CICS DFHSIP NO NO
Cryptographic Unit Support ICUMKG10 NO YES
JES3 IATINTK
JES3 FSS IATINTKF

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

17 / 21
 Appendix E RACF Security Audit

Appendix E
RACF Standard Exits

Exit Exit
Name Description
ICHDEX01 Password encryption
ICHRIX01 RACINIT preprocessing
ICHRIX02 RACINIT postprocessing
ICHRCX01 RACHECK preprocessing
ICHRCX02 RACHECK postprocessing
ICHRDX01 RACDEF preprocessing
ICHRDX02 RACDEF postprocessing
ICHCCX00 Command preprocessing
ICHCNX00 Command preprocessing
ICHRFX01 FRACHECK preprocessing
ICHRFX02 FRACHECK postprocessing
ICHPWX01 New password
ICHRLX01 RACLIST pre/post processing
ICHRLX02 RACLIST selection
ICHRSMFE Report writer

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

18 / 21
 Appendix F RACF Security Audit

Appendix F
RACF Commands

Display the Contents of a User-Id Profile

1. Use the following RACF command to generate a listing of a user-id profile. This command can be used at the
TSO/ISPF TSO command prompt or in batch JCL.

LISTUSER 'user-id'

Note - If you wish to produce a listing of all RACF user-id profiles use:

LISTUSER Q

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

19 / 21
 RACF Security Audit Program

End of Program

Filename: c:\data\web pages\auditnet \docs\racfauditprog.doc November 30, 2000

20 / 21