Beruflich Dokumente
Kultur Dokumente
COM
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
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.
DONE
AUDIT STEPS TO BE COMPLETED BY W/P REF
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.
DONE
AUDIT STEPS TO BE COMPLETED BY W/P REF
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.
DONE
AUDIT STEPS TO BE COMPLETED BY W/P REF
DONE
AUDIT STEPS TO BE COMPLETED BY W/P REF
DONE
AUDIT STEPS TO BE COMPLETED BY W/P REF
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.
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
Appendix A
How To Read Dataset Profiles
1. For data files under review, obtain "Data Set Profiles" for each by using the RACF command:
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
• The default value is FAILURES (READ). This would normally be appropriate. At a minimum AUDITING should
be set to FAILURES (UPDATE).
Appendix B
RACF Global System Resource Options (SETROPTS)
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. ATTRIBUTES =
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.
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.
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.
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.
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.
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.
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.
Appendix C
TSO Batch JCL
Exhibit 1 - JCL to produce a RACF DSMON report.
Appendix C
TSO Batch JCL
Exhibit 2 - JCL to produce a RACF SETROPTS report.
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.
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
Appendix F
RACF Commands
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
End of Program