Information Security and IS Audit Articles
from the Henderson Group
This page is:
ARTICLES: RACF SETR LIST

Quick Links:

HOME PAGE

CONTACT US

INFOSEC TRAINING

IT AUDIT TRAINING

NEWSLETTERS AND USER GROUPS

ARTICLES

PRIVACY STATEMENT

ABOUT US

OTHER INFO SOURCES

Interpreting Output from the RACF SETR LIST Command

sponsored by the Henderson Group
Computer Security Consulting and Training

ABSTRACT

"Interpreting Output from the RACF SETR LIST Command"

SETR is the command to set options for RACF, IBM's strategic software for mainframe computer security. The SETR LIST command is the version which lists the current setting of all these options. This session will show you how to interpret all these settings. (You may have an actual printout to use along with the presentation.) You will learn recommended values for these settings, as well as the reasons behind these recommendations.

This is the handout for a stand-up presentation by Stu Henderson. It's content is offered on an "as-is", at-your-own- risk, test-it-yourself-first, basis. The opinions expressed are his, and may not be suitable for your installation. This article has been updated July, 2007.

======================================================== ======================================================== ========================================================

AGENDA

I INTRODUCTION

II EXPLANATIONS AND RECOMMENDATIONS

III SUMMARY AND CALL TO ACTION

======================================================== ======================================================== ========================================================

I INTRODUCTION

TODAY, WE WILL EXAMINE A SETR LISTING IN 5 PARTS:

A) THE ATTRIBUTES

B) RESOURCE CLASS SWITCHES

C) DATASET AND USERID OPTIONS

D) PASSWORD OPTIONS

E) MISCELLANEOUS OPTIONS

======================================================== ======================================================== ========================================================

II EXPLANATIONS AND RECOMMENDATIONS

A) THE ATTRIBUTES (THE TOP LINE OF THE PRINTOUT)

  • INITSTATS--- SAYS TO TIME-STAMP THE USER RECORD AT TERMINAL SIGN-ON AND AT START OF A BATCH JOB AND AT START OF A STARTED TASK

  • WHEN (PROGRAM)--- SAYS TO ALLOW PROGRAM-PATHING (FOR EXAMPLE, "PERMIT THIS USER TO UPDATE THIS DATASET WHEN GOING THROUGH THIS SPECIFIED PROGRAM"). USED ALSO TO ACTIVATE THE PROGRAM RESOURCE CLASS.

  • TERMINAL UACC--- DEFAULT TERMINAL ACCESS (READ OR NONE) IF NO MATCHING TERMINAL RESOURCE RULE. (SHOWS ONLY IF TERMINAL CLASS IS ACTIVE)

  • SAUDIT--- SAYS TO LOG EVERY TIME A USER DOES SOMETHING HE OR SHE IS ONLY ABLE TO DO BECAUSE OF THE SPECIAL USER OR GROUP ATTRIBUTE

  • CMDVIOL--- SAYS TO LOG EVERY COMMAND VIOLATION

  • OPERAUDIT--- SAYS TO LOG EVERY TIME A USER DOES SOMETHING HE OR SHE IS ONLY ABLE TO DO BECAUSE OF THE OPERATIONS USER OR GROUP ATTRIBUTE

======================================================== ======================================================== ========================================================

RECOMMENDATIONS FOR THE ATTRIBUTE SWITCHES:

  • LEAVE TERMINAL SET AT READ

  • FOR THE OTHERS, TURN THEM ALL ON AND LEAVE THEM ON

======================================================== ======================================================== ========================================================

B) RESOURCE CLASS SWITCHES (SEVERAL PAGES LONG WITH THE NAME OF THE SWITCH ON THE EXTREME LEFT SIDE OF THE PRINTOUT)

THESE SWITCHES DESCRIBE SETTINGS FOR EACH RESOURCE CLASS.

  • STATISTICS--- SPECIFIES CLASSES FOR WHICH RACF IS TO KEEP REFERENCE COUNTS IN DISCRETE PROFILES (NUMBER OF CALLS FOR "READ", NUMBER OF CALLS FOR "UPDATE", ETC.)

  • AUDIT--- SPECIFIES CLASSES FOR WHICH RACF IS TO LOG EVERY TIME A RULE IS CREATED, CHANGED (INCLUDING PERMITS) , OR DELETED

  • ACTIVE--- SPECIFIES CLASSES FOR WHICH RACF CHECKING IS TO BE IN EFFECT

  • GENERIC PROFILE--- SPECIFIES CLASSES FOR % AND * ARE TO TREATED AS WILDCARD CHARACTERS

  • GENERIC COMMAND--- SPECIFIES CLASSES WHICH FOR WHICH RACF COMMANDS TREAT % AND * AS WILDCARD CHARACTERS

  • GENLIST--- SPECIFIES CLASSES FOR WHICH RACF IS TO KEEP ALL THE GENERIC PROFILES LOCKED IN MEMORY (A PERFORMANCE FEATURE) (CONTRAST WITH RACLIST BELOW)

  • GLOBAL--- SPECIFIES CLASSES FOR WHICH RACF IS TO USE GLOBAL CHECKING (SEE THE DSMON REPORT FOR MORE DETAILS)

  • RACLIST and GLOBAL =YES RACLIST ONLY--- SPECIFIES CLASSES FOR WHICH RACF IS TO KEEP ALL PROFILES LOCKED IN MEMORY (ANOTHER PERFORMANCE FEATURE) (CONTRAST WITH GENLIST ABOVE) (GLOBAL=YES RACLIST ONLY SPECIFIES CLASSES RACLISTED USING ESA MEMORY ENHANCEMENTS)

  • LOGOPTIONS ALWAYS--- SPECIFIES CLASSES FOR WHICH EVERY REFERENCE IS TO BE LOGGED

  • LOGOPTIONS NEVER--- SPECIFIES CLASSES FOR WHICH NO REFERENCE IS TO BE LOGGED

  • LOGOPTIONS SUCCESSES--- SPECIFIES CLASSES FOR WHICH EVERY SUCCESSFUL REFERENCE IS TO BE LOGGED

  • LOGOPTIONS FAILURES--- SPECIFIES CLASSES FOR WHICH EVERY FAILED REFERENCE IS TO BE LOGGED

  • LOGOPTIONS DEFAULT--- SPECIFIES CLASSES FOR WHICH LOGGING IS BASED ON THE OPTIONS IN THE RACF RULE (GLOBALAUDIT OR AUDIT)

======================================================== ======================================================== ========================================================

RECOMMENDATIONS FOR RESOURCE CLASS SWITCHES

  • HAVE AN OWNER FOR EACH CLASS: THE PERSON RESPONSIBLE FOR DECIDING WHAT THE RULES SHOULD BE AND WHETHER THE CLASS SHOULD BE ACTIVE

  • SINCE STATISTICS APPLIES ONLY TO DISCRETE PROFILES, DON'T WORRY ABOUT IT

  • TURN ON AUDIT FOR EVERY RESOURCE CLASS EXCEPT THE RESOURCE CLASSES FOR USS, (SEE RELATED HANDOUT FOR DSMON INTERPRETATION) SINCE YOU NEED TO KNOW WHO MADE EACH AND EVERY CHANGE TO A RULE. (NOTE: THIS SWITCH DOES NOT CAUSE LOGGING FOR RESOURCE CHECKS, ONLY FOR CHANGES TO RULES).

  • MAKE ACTIVE ONLY THOSE CLASSES YOU ARE READY TO ADMINISTER (SEE FURTHER RECOMMENDATIONS IN DSMON PRESENTATION)

    ======================================================== ======================================================== ========================================================

  • TURN ON GENERIC PROFILE FOR EVERY CLASS POSSIBLE (NOT POSSIBLE FOR GROUP CLASSES)

  • DON'T WORRY ABOUT GENERIC COMMAND, SINCE IT IS USED ONLY TO REPAIR MIXED UP GENERIC PROFILES

  • USE GENLIST FOR THE VMMDISK RESOURCE CLASS IF YOU USE RACF WITH VM, OTHERWISE USUALLY IGNORE IT

    ======================================================== ======================================================== ========================================================

  • USE GLOBAL FOR DATASETS, SELECTING THE DATASET RULES CAREFULLY BASED UPON ANALYSIS OF FREQUENCY OF USE AND SENSITIVITY. AN ENTRY TO PERMIT ANY ACCESS TO A DATASET WHOSE HIGH LEVEL QUALIFIER IS YOUR USERID WOULD MAKE SENSE. USE GLOBAL FOR OTHER CLASSES ONLY IF THE FREQUENCY JUSTIFIES IT

  • USE RACLIST FOR RESOURCE CLASSES WITH FEW RULES AND FREQUENT ACCESS, PLUS FOR CLASSES WHICH REQUIRE IT. THE APPL CLASS IS A GOOD CANDIDATE. GLOBAL = YES RACLIST ONLY CLASSES WILL TAKE CARE OF THEMSELVES WHEN YOU RACLIST THEM.

  • SET LOGOPTIONS TO DEFAULT FOR ALL CLASSES UNLESS YOU HAVE A SPECIFIC REASON TO SET IT OTHERWISE

======================================================== ======================================================== ========================================================

C) DATASET AND USERID OPTIONS

  • AUTOMATIC DATASET PROTECTION--- (OBSOLETE). USED TO BE USED TO SPECIFY THAT FOR CERTAIN USERS, EVERY DISK DATASET WHICH THEY CREATE GETS A RACF DISCRETE PROFILE WITH THE RACF BIT TURNED ON

  • ENHANCED GENERIC NAMING--- DETERMINES WHETHER THE "ENHANCED" USE OF ASTERISKS IS USED FOR DSNAMES.

  • REAL DATASET NAMES--- USED WITH DATASET NAMING CONVENTIONS TABLE TO SPECIFY THAT UN-MODIFIED VERSIONS OF DSNAMES ARE TO BE LOGGED

  • JES-BATCHALL-RACF --- USED TO INDICATE THAT EVERY BATCH JOB MUST HAVE A RACF USERID ASSOCIATED WITH IT (EXCEPTING XBM JOBS, SEE NEXT ITEM)

  • JES-XBMALL-RACF--- USED TO INDICATED THAT EVERY BATCH JOB RUN UNDER THE JES EXECUTION BATCH MONITOR MUST HAVE A RACF USERID ASSOCIATED WITH IT

  • JES-EARLYVERIFY--- OBSOLETE, JES NOW ALWAYS ASSUMES THAT THIS SWITCH IS ON. USED TO INDICATE THAT JOBS SHOULD HAVE THEIR PASSWORD CHECKED WHEN THEY ARE READ IN, NOT LATER WHEN THEY ARE EXECUTED

  • PROTECT-ALL--- REQUIRES EVERY DATASET TO HAVE A RACF RULE COVERING IT. IF TAPEDSN IS SET, APPLIES TO TAPE DATASETS, AS WELL. (EXCEPTION: USERS WITH THE SPECIAL ATTRIBUTE CAN READ DATASETS NOT COVERED BY A DATASET RULE WHEN PROTECTALL IS ACTIVE)

  • TAPE DATA SET PROTECTION (TAPEDSN)--- TELLS RACF TO PROCESS TAPE DATASETS THE SAME WAY THAT DISK DATASETS ARE PROCESSED (THAT IS, BY CHECKING THE DSNAME AT OPEN TIME AGAINST THE APPROPRIATE RACF DATASET PROFILE)

  • SECURITY RETENTION PERIOD--- USED WITH TAPE DATASETS TO SPECIFY THE DEFAULT NUMBER OF DAYS A TAPE DATASET IS KEPT BEFORE THE REEL OR CARTRIDGE IS SENT TO THE "SCRATCH" POOL.

  • ERASE-ON-SCRATCH--- SPECIFIES WHETHER SCRATCHING A DISK DATASET CAUSES ZEROES TO BE WRITTEN OVER THE DATA BEFORE THE DISK SPACE IS FREED UP. FOUR OPTIONS:
    1. NOT ACTIVE
    2. ACTIVE FOR ALL DATASETS
    3. ACTIVE FOR DATASETS WITH A SPECIFIED SECURITY LEVEL OR HIGHER
    4. FOR DATASETS WHOSE RACF PROFILES HAVE THE "ERASE" FLAG TURNED ON.

  • SINGLE LEVEL NAME PREFIX--- SPECIFIES PREFIX WHICH RACF PRETENDS IS THE HIGH LEVEL QUALIFIER OF DSNAMES WHICH OTHERWISE HAVE JUST ONE QUALIFER. FOR EXAMPLE, DSNAME=PASSWORD IS TREATED AS IF IT WERE DSNAME=prefix.PASSWORD

  • LIST OF GROUPS--- SPECIFIES THAT EACH USER IS TO BE TREATED AS BEING ACTIVE IN ALL GROUPS TO WHICH THE USER IS CONNECTED

  • INACTIVE USERIDS--- SPECIFIES THE NUMBER OF DAYS OF INACTIVITY AFTER WHICH A USERID WILL BE AUTOMATICALLY REVOKED

  • MODELLING (USER, GROUP, GDG)--- OBSOLETE. USED TO SPECIFY THAT MODEL DATASET PROFILES WILL BE USED TO FILL IN THE PERMIT LISTS OF USER, GROUP, OR GDG DATASET PROFILES

======================================================== ======================================================== ========================================================

RECOMMENDATIONS FOR DATASET AND USERID OPTIONS

  • LEAVE AUTOMATIC DATASET PROTECTION INACTIVE

  • SET ENHANCED GENERIC NAMING ON OR OFF FOR ALL OF YOUR INSTALLATION (EITHER WAY IS FINE, BUT YOU WANT TO BE ALL ONE WAY OR ALL THE OTHER.)

  • USE REAL DATASET NAMES IF YOU CHOOSE, BUT IT ONLY MATTERS IF YOU USE THE DATASET NAMING CONVENTIONS EXIT

  • ACTIVATE BATCHALLRACF AND XBMALLRACF TOGETHER. PLEASE NOTE THAT WHILE BATCHALLRACF IS IMPORTANT, XBMALLRACF HAS NOT EFFECT IN MOST INSTALLATIONS (UNLESS YOU ARE USING THE JES EXECUTION BATCH MONITOR, ASK YOUR JES SYSTEM PROGRAMMER). WHILE IT IS A GOOD IDEA TO ACTIVATE XBMALLRACF IN ALMOST EVERY INSTALLATION, IT IS NOT CRITICAL IF YOU ARE NOT USING XBM. YOU SHOULD CONCENTRATE ON BATCHALLRACF, AND TURN ON XBMALLRACF IF POSSIBLE.

    ======================================================== ======================================================== ========================================================

  • DON'T WORRY ABOUT EARLYVERIFY

  • TURN ON PROTECTALL IN FAIL MODE

  • CONSIDER TURNING ON TAPE DATA SET PROTECTION, EVEN IF YOU HAVE TAPE MANAGEMENT SOFTWARE. (TAPE PROTECTION IS A LARGER ISSUE THAN JUST RACF BECAUSE OF PROBLEMS SUCH AS THE 17 CHARACTER DSNAME PROBLEM AND BYPASS LABEL PROCESSING). TAPE PROTECTION SHOULD BE ADDRESSED IN CONCERT WITH THE ADMINISTRATOR OF THE TAPE MANAGEMENT SOFTWARE. (PLEASE SEE RELATED ARTICLE ON OUR WEBSITE ABOUT COMPLETE TAPE PROTECTION.) AUDITORS SHOULD ADDRESS THIS RACF FEATURE ONLY AS PART OF AN AUDIT THAT ADDRESSES TAPE MANAGMENT SOFTWARE IN CONCERT WITH RACF.

    DON'T FORGET TO CONSIDER USING THE HARDWARE ENCRYPTION IN THE NEWER TAPE DRIVES FOR ALL TAPES LEAVING THE DATA CENTER.

  • DON'T WORRY ABOUT RETENTION PERIOD IF YOU USE TAPE MANAGEMENT SOFTWARE

  • ACTIVATE ERASE-ON-SCRATCH FOR SELECTED DATASETS, THAT IS FOR DATASETS WHICH HAVE "ERASE" SPECIFIED ON THE DATASET RULE. (NOTE HOW IBM DESCRIBES THIS: "BY SECURITY LEVEL IS INACTIVE"!) NOTE THAT YEARS AGO THIS OPTION CAUSED PERFORMANCE PROBLEMS IN SOME INSTALLATIONS WHEN IT WAS MADE ACTIVE FOR ALL DATASETS. SINCE THEN, IMPROVEMENTS IN DISK HARDWARE [INCLUDING NEW CCWS, ELECTRONIC CACHING, RAID, AND OTHERS] MAKE THE PERFORMANCE ISSUE ALMOST MEANINGLESS. WITH SOME HARDWARE [SUCH AS RAID] THIS OPTION MAY NOT BE NECESSARY BECAUSE IT IS IMPOSSIBLE FOR SOMEONE TO RECOVER RESIDUAL DATA LEFT ON DISK STORAGE AFTER THE DATASET IS ERASED. HOWEVER, SINCE THE RACF ADMINISTRATOR NEVER KNOWS FOR SURE WHICH HARDWARE IS IN USE, THE ERASE-ON- SCRATCH OPTION SHOULD BE USED. IT CAN BE ROLLED OUT GRADUALLY, A DATASET AT A TIME, TO ENSURE THAT PERFORMANCE IS NOT AFFECTED.

  • SET SINGLE LEVEL PREFIX TO SUIT YOUR TASTE, OR STANDARDS

  • ACTIVATE LIST-OF-GROUPS

  • REVOKE INACTIVE USERIDS AFTER SOME STANDARD NUMBER OF DAYS, BUT INSTEAD OF USING THIS OPTION OF THE SETR COMMAND, USE THE SEARCH COMMAND WITH CLIST OPTION TO REVOKE THEM PROPERLY [SEARCH CLASS(USER) NOMASK AGE(365) CLIST('ALU ' ' REVOKE')]

  • LEAVE MODELLING TURNED OFF

======================================================== ======================================================== ========================================================

D) PASSWORD OPTIONS

(PLEASE NOTE THAT IBM HAS RECENTLY ADDED SUPPORT FOR MIXED CASE PASSWORDS AND PASS PHRASES TO RACF. NOT ALL ONLINE PROGRAMS (SUCH AS TSO AND CICS) ARE ABLE TO HANDLE THESE YET. LONG TERM, YOU WILL WANT TO USE THESE NEW FEATURES, BUT ONLY AFTER GOOD TRAINING FOR USERS, AND BEING SURE THAT ALL ONLINE PROGRAMS YOU USE SUPPORT THEM AS WELL.)

  • CHANGE INTERVAL--- NUMBER OF DAYS AFTER WHICH A USER MUST CHANGE HIS OR HER PASSWORD

  • MIN CHANGE MINIMUM NUMBER OF DAYS BEFORE A USER CAN CHANGE HIS OR HER OWN PASSWORD, USED TO PREVENT USERS FROM RE-CYCLING PASSWORDS SO THEY CAN RE-USE THEIR ORIGINAL ONE.

  • NUMBER OF GENERATIONS MAINTAINED--- (AKA "PASSWORD HISTORY") NUMBER OF RECENTLY USED PASSWORDS (UP TO 32) MAINTAINED IN EACH USER PROFILE (TO PREVENT PASSWORD RE-USE)

  • NUMBER OF CONSECUTIVE UNSUCCESSFUL--- NUMBER OF BAD PASSWORDS IN A ROW WHICH WILL CAUSE RACF TO REVOKE A USERID

  • EXPIRATION WARNING LEVEL--- NUMBER OF DAYS BEFORE A PASSWORD EXPIRES THAT A USER IS WARNED

  • SYNTAX RULES--- LENGTH AND CONTENT RULES

    (NOTE THAT WITH RACF, ALPHANUMERIC REQUIRES AT LEAST ONE LETTER AND AT LEAST ONE NUMBER, WITHOUT SPECIFYING WHERE THEY OCCUR. THIS MAKES IT MOST HARD FOR CRACKERS TO GUESS)

    RECENTLY ADDED POSSIBLE VALUES INCLUDE: MIXEDCONSONANT, MIXEDVOWEL, AND MIXEDNUM. (MIXED MEANS BOTH UPPER AND LOWER CASE. MIXEDNUM REQUIRES AT LEAST ONE UPPER CASE LETTER, AT LEAST ONE LOWER CASE LETTER, AND AT LEAST ONE NUMBER. THE THREE SPECIAL CHARACTERS (#, $, AND @) ARE CONSIDERED TO BE UPPER CASE CONSONANTS, OF COURSE.)

======================================================== ======================================================== ========================================================

RECOMMENDATIONS FOR PASSWORD OPTIONS

  • SET PASSWORD CHANGE INTERVAL TO SOMETHING IN THE AREA OF 30 DAYS (COMMON PRACTICE)

  • KEEP 32 PASSWORD GENERATIONS, BUT ALSO MONITOR RE-USE AND FORBID RE- USE IN SECURITY STANDARDS

  • SET MINCHANGE TO A VALUE OF 2 OR 3 DAYS.

  • DO NOT ALLOW MIXED CASE PASSWORDS UNTIL USERS ARE PROPERLY TRAINED AND ONLINE SOFTWARE SUPPORTS IT.

  • REVOKE USERIDS AFTER 3 UNSUCCESSFUL PASSWORDS

    (IF YOU CAN'T REMEMBER YOUR PASSWORD IN 3 TRIES, YOU WON'T GET IT EVER. SINCE A SUCCESSFUL LOGON ZEROES THE COUNTER OF INVALID PASSWORDS IN THE USER RECORD, IF YOU SET THIS LIMIT TO 3, THEN A HACKER CAN MAKE TWO GUESSES, WAIT FOR A SUCCESSFUL LOGON, MAKE TWO MORE GUESSES, AND SO ON UNTIL SHE LEARNS WHAT THE PASSWORD IS. IF YOU SET THIS LIMIT HIGHER THAN 3, THEN IT IS EVEN EASIER FOR THE HACKER TO GUESS PASSWORDS.)

  • SET PASSWORD EXPIRATION LEVEL TO SUIT TASTE AND STANDARDS

  • SET SYNTAX RULES TO INCLUDE AT LEAST ONE NUMBER AND AT LEAST ONE LETTER (ALPHNUMERIC) WITH A LENGTH OF AT LEAST 5. (IN FUTURE, PLAN ON CHANGING THIS TO MIXEDNUM, ONLY AFTER USERS AND ONLINE SOFTWARE ARE READY.)

  • TRAIN USERS IN HOW TO MAKE PASSWORDS "EASY TO REMEMBER, BUT DIFFICULT TO GUESS". IF YOU DON'T TRAIN USERS, THE NUMBER OF PASSWORD RESET REQUESTS WILL GET CONINTUALLY WORSE OVER TIME.

  • MONITOR NUMBER OF BAD PASSWORDS PER WEEK AND PLOT THEM OVER TIME TO SEE THE TREND. ESTIMATE THE COST TO RESET ONE PASSWORD (SOME SAY $70) AND MULTIPLY BY THE NUMBER OF PASSWORDS RESETS EACH YEAR. THEN RE-CONSIDER WHETHER THAT TRAINING PROGRAM FOR USERS IS TOO EXPENSIVE.

======================================================== ======================================================== ========================================================

E) MISCELLANEOUS OPTIONS

  • RVARY PASSWORDS--- PASSWORDS OPERATOR IS TO ENTER TO CONFIRM USE OF RVARY COMMAND

  • SECURITY LEVEL AUDIT --- SPECIFIES THAT RACF IS TO LOG ALL CHECKS OF ITEMS WITH A SPECIFIED SECURITY LEVEL

  • SECLABELAUDIT --- USED WITH B1 (A RELATIVELY RESTRICTIVE LEVEL OF SECURITY ACCORDING TO THE US GOVERNMENT'S "ORANGE BOOK"). CAUSES LOGGING FOR ENTITIES WITH SECURITY LABELS BASED ON THE AUDIT OPTIONS IN THE SECLABEL RULES

  • SECLABELCONTROL--- USED WITH B1. RESTRICTS WHO CAN SPECIFY SECURITY LABELS IN RACF COMMANDS.

  • GENERICOWNER--- RESTRICTS SCOPE OF USER ATTRIBUTE CLAUTH(resource class name) TO PREVENT UNDERCUTTING ("UNDERCUTTING" IS THE CREATION OF A MORE SPECIFIC RULE. THIS HAS THE EFFECT OF BYPASSING THE ORIGINAL RULE FOR ANY RESOURCE WHICH MATCHES THE MORE SPECIFIC RULE.) [REMEMBER THAT RACF ALWAYS USES THE ONE MOST SPECIFIC MATCHING RULE AND NO OTHER WHEN MAKING HIS DECISIONS.]

    IN GENERAL, THE CLAUTH USER ATTIBUTE GIVES A USER THE ABILITY TO CREATE NEW RESOURCE RULES IN THE SPECIFIED CLASS. WHEN GENERICOWNER IS ACTIVE, THEN A USER WITH CLAUTH(resource class name) WILL NOT BE ABLE TO MAKE A RULE IN THAT CLASS WHICH IS MORE SPECIFIC THAN AN EXISTING RULE UNLESS HE IS THE OWNER OF THE EXISTING RULE OR HAS SPECIAL OVER IT. )

  • COMPATIBILITY MODE--- USED WITH B1. ALLOWS CERTAIN USERIDS THAT DON'T HAVE SECURITY LABELS TO USE THE SYSTEM, EVEN THOUGH SECURITY LABELS ARE BEING CHECKED

  • MULTI-LEVEL OPTIONS (MLS)--- USED WITH B1 TO SPECIFY DEGREE OF RIGOR FOR LABEL CHECKING

  • CATALOGUED DATASETS ONLY --- REQUIRES EVERY DATASET TO BE CATALOGUED, (WITH SOME EXCEPTIONS)

  • NJEUSERID--- DEFAULT USERID FOR JESSPOOL PROFILE NAMES FOR NJE JOBS

  • UNDEFINEDUSER--- DEFAULT USERDID FOR JESSPOOL PROFILE NAMES FOR LOCAL JOBS

  • SESSIONKEY INTERVAL--- DEFAULT AND MAXIMUM NUMBER OF DAYS SESSION KEY FOR APPC IS VALID

  • PRIMARY AND SECONDARY LANGUAGES--- DEFAULT LANGUAGES (FRENCH AND GERMAN, NOT COBOL AND FORTRAN) FOR MVS TO PRINT ERROR MESSAGES. A WONDERFUL OPPORTUNITY FOR PRACTICAL JOKES.

  • ADDCREATOR--- ADDCREATOR APPLIES WHEN SOMEONE CREATES A NEW DATASET OR RESOURCE RULE. IT AUTOMATICALLY PERMITS THE USERID CREATING THE RULE WITH ALTER ACCESS.

======================================================== ======================================================== ========================================================

RECOMMENDATIONS FOR MISCELLANEOUS OPTIONS

  • PROVIDE RVARY PASSWORDS, DOCUMENT THEM, TRAIN AND TEST OPERATORS

  • LEAVE SECURITY LEVEL, SECLABEL AUDIT, AND SECLABEL CONTROL INACTIVE

  • CONSIDER TURNING ON GENERICOWNER AS PART OF AN OVERALL STRATEGY FOR DELEGATION OF AUTHORITY

  • LEAVE COMPATIBILITY MODE AND MULTI-LEVEL OPTIONS NOT IN EFFECT, UNLESS YOU WANT B1

  • CONSIDER TURNING ON CATALOGUED DATA SETS ONLY, BUT RECOGNIZE THAT THIS MAY HAVE NOTHING TO DO WITH SECURITY

  • SETR NOADDCREATOR

  • LEAVE THE REST TO THEIR DEFAULT VALUES: NJEUSERID (????????), UNDEFINEDUSER (++++++++), SESSIONKEY INTERVAL (30 DAYS), AND LANGUAGES (ENU FOR "ENGLISH AS SPOKEN IN THE UNITED STATES") [OF COURSE IF YOUR USERS MOSTLY USE SOME OTHER LANGUAGE, SPECIFY IT.]

======================================================== ======================================================== ========================================================

III SUMMARY AND CALL TO ACTION

  • YOU SHOULD HAVE A STANDARD IN WRITING FOR EVERY FIELD IN SETR LIST

  • YOU SHOULD HAVE PERIODIC AUDITS OR REVIEWS TO ENSURE THAT THE STANDARD IS OBSERVED

  • THIS WILL HELP YOU TO KNOW THAT YOUR RACF OPTIONS ARE SET THE WAY YOU WANT THEM TO BE. THIS WILL BE THE FOUNDATION FOR AN EFFECTIVE RACF IMPLEMENTATION, AND FOR EFFECTIVE COMPUTER SECURITY.


Return to HG Home Page (www.stuhenderson.com)
======================================================== ======================================================== ========================================================

About the Author

Stuart Henderson is an experienced consultant and trainer who specializes in effective IT audits and computer security. He has helped hundreds of organizations make better use of security software such as RACF, ACF2, and TopSecret. He has also helped these organizations address the technical and organizational issues surrounding cross-platform security. As President of the Henderson Group, he directs a variety of activities in support of the computer security and IT audit communities. These include: seminars, consulting services, articles, and speeches. He is an experienced system programmer who has earned the Certified Internal Auditor, Certified Management Accountant, and Certified Data Processor designations. His seminars on computer security and audit of: MVS, DB2, RACF, VTAM, Windows 2000, and other subjects are taught nationwide. He teaches Certified Information Systems Auditor review courses for the National Capital Area Chapter of the ISACA.

He speaks to groups such as the Computer Security Institute, the DPMA, the ISSA, and the ISACA. Some of his topics have been: "What System Programmers Know that DSOs and EDP Auditors Should (or How I Would Break into Your System and What You Should be Doing to Stop Me)", What Non-Data Processing Executives Should Know and Do About Computer Security", "Combining VAX/VMS Security with IBM Mainframe Security", and "Tools for Maintaining Single Point of Control for Security". He is founder of the New York RACF Users Group and Editor of its newsletter. His website is http://www.stuhenderson.com. He can be reached at (301) 229-7187 or stu@stuhenderson.com.


Return to Home Page