RACF AUDIT PROGRAM Contributed by Pamela Jerskey, Boston College Obtain the following reports from Security Administrator: 1. SETROPTS 2. DSMON (all functions . 3. RACF Users 4. RACF Group 5. RACF datasets 6. Sample daily violation report 7. SYS1.UADS listing CONTROL CONCERN REFERENCE I. REVIEW OF DATA SECURITY MONITOR REPORT (DSMON): 1. Review DSMON System Report and ascertain that RACF is active. 2. Review DSMON Program Properties Table Report for appropriateness. 3. Review DSMON Authorized Caller Table Report for appropriateness. 4. Review DSMON RACF Exits Report for appropriateness. What is the function of the exits? What are the requirements for exists and is this still valid? 5. Review DSMON Selected User Attribute Report for appropriateness of SPECIAL, OPERATIONS, and AUDITOR user attribute assignment. Are they sufficiently restricted and is current use appropriate? Are the activities of users with the SPECIAL or OPERATIONS attributes adequately logged and reviewed? Who is doing the review? How are possible exceptions handled? 6. Review DSMON RACF Started Procedures Table Report for appropriateness. 7. Review the DSMON RACF Class Descriptor Table Report to determine the resource classes that have been defined to RACF and whether they are active. 8. Review DSMON RACF Global Access Table Report for appropriateness. 9. Review DSMON Selected Data Sets Report to determine that data sets are RACF-protected and what universal access authority level has been assigned to each data set. II. RACF OPTIONS IN EFFECT 1. Using the SETROPTS report, analyze current RACF options in effect and review for reasonableness. 2. Is access to RACF data sets(s) protected by RACF? 3. Who is authorized to access the RACF data set(s)? 4. What universal access authority level has been assigned to the RACF data set(s)? 5. Where is RACF started? III. REVIEW PROFILES FOR ALL RACF DATA SETS. 1. Review all key RACF data set profiles for appropriateness. 2. Obtain listing of data sets from system and determine that all data sets are protected under RACF. IV. REVIEW RACF-DEFINED USERS AND PROFILES 1. Review RACF-defined users and profiles for appropriateness. Determine: 1a. that last access was within one year. 1b. that all revoked datasets are removed from RACF database. 1c. that individuals who have Special, Auditor and Operations attributes are appropriate. 1d. that there are no users with password interval = N/A (do not expire). 2. Review group list for appropriateness. V. GENERAL AND ADMINISTRATIVE 1. Are there Security Policy and Guidelines? 2. Is information "ownership" well defined? 3. How is the Data Security function structured? Where does it report within the organization? 4. What is the procedure for requesting and obtaining a new userid? 5. How are users authenticated when a password reset is requested? 6. How is the reset password determined and how is the reset performed? How is the reset password communicated to the user? 7. What is the procedure for notification of user termination or transfer? 8. What are the "clean-up" procedures for terminated, unused, and deleted userids? What is the disposition of userid datasets when the userid is deleted? Are there any potential exposures? 9. How many inactive userids are there? What are the procedures for handling inactive userids and are they appropriate? 10. How many REVOKEd userids are there? How long have they been REVOKEd? Is the current status of REVOKEd userids appropriate? 11. Do any userids have never-expiring passwords? If so, what are the compensating controls and are they appropriate? 12. Are there any userids in the RACF database with a Last-Access-Date of "UNKNOWN"? What is the status of these userids? How long since they were added to RACF? Are there any potential exposures? 13. What is the state of IBMUSER? What are its current attributes? 14. Identify users with exceptional user-attributes and group-related authorities. For example, CLAUTH(USER), CONNECT, JOIN, or GROUP-SPECIAL. Is the use of these attributes and authorities appropriate and with Policy guidelines? 15. If RACF is used to maintain TSO UADS information, are there any userids retained in TSO UADS? If so, how many are there, who are the userids assigned to, and why are they still in UADS? 16. What is the dataset naming convention and does it lend itself well to RACF control? 17. What is the minimum protection requirements for "all" data? What is the default protection for data and how is it established? 18. What is the procedure for adding and removing new dataset high-level qualifiers? 19. Are there any RACF DISCRETE profiles? What are DISCRETE profiles being used? 20. Identify all datasets with the WARNING indicator. Is the use of WARNING appropriate? 21. What kind of RACF reporting is being done? At what frequency are reports run? 22. Are there formal procedures for modifying the primary or Global RACF options? Who has the capability to change the Global RACF options? Who is authorized to make Global RACF changes? 23. Who is authorized to run the RACF DSMON program? 24. Do any program names have the privilege to bypass RACF authorization checking? If so, why do they need to bypass RACF checking? How are these programs used? What kind of controls exist to prevent these programs from subverting system security? 25. Are the RACF SMF types 20, 30, 80, and 81 records being collected for all systems? What is the retention and storage of this data? 26. What are the RACF database backup procedures? How are the databases backed up? Are the backup procedures adequate? 27. Can anyone gain access to the RACF databases through some bypass capability? 28. Have the vendor-supplied defaults for the RACF RVARY SWITCH and STATUS passwords been changed? 29. Who is authorized to know what the current RVARY passwords are and is this appropriate?