Interpreting Output from the RACF DSMON Utility


sponsored by the Henderson Group
Computer Security Consulting and Training


ABSTRACT
"Interpreting Output from the RACF DSMON Utility"
DSMON is the Data Security Monitor, a program which prints 11 reports about use of RACF, IBM's strategic software for mainframe computer security. This session will show you how to interpret these reports. You may have an actual DSMON printout to illustrate. You will learn recommended values for several RACF options, as well as the reasons behind these recommendations. This report was updated July, 2007.
This is the handout for a stand-up presentation by Stu Henderson. It is offered on an "as-is", "at-your-own-risk" basis. The opinions expressed are Stu's and may not be suitable at your installation.
======================================================== ======================================================== ========================================================

AGENDA


I INTRODUCTION
II EXPLANATIONS AND RECOMMENDATIONS
III SUMMARY AND CALL TO ACTION
======================================================== ======================================================== ========================================================

I INTRODUCTION


TODAY, WE WILL EXAMINE A SAMPLE DSMON REPORT IN 5 PARTS:
A) THE SHORT REPORTS (4 REPORTS)
B) USER/GROUP REPORTS (4)
C) CLASS DESCRIPTOR TABLE REPORT #9
D) GLOBAL ACCESS TABLE REPORT #10
E) SELECTED DATASETS REPORT #11
======================================================== ======================================================== ========================================================

II EXPLANATIONS AND RECOMMENDATIONS


A) SHORT REPORTS (4)



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

1) SYSTEM REPORT #1



CRITICAL STEPS TO TAKE:


1) TURN THE PAGE!
======================================================== ======================================================== ========================================================

2) PROGRAM PROPERTIES TABLE REPORT #2



CRITICAL STEPS TO TAKE:


1) ID ANY PROGRAMS WITH "YES" UNDER BYPASS PASSWORD PROTECTION WHICH WERE NOT SUPPLIED BY IBM. THE LIST OF IBM-SUPPLIED ENTRIES MAY BE FOUND IN THE IBM MANUAL "MVS INITIALIZATION AND TUNING REFERENCE" UNDER THE HEADING "SCHEDxx".
2) DETERMINE WHY THEY ARE THERE AND WHO IS RESPONSIBLE FOR THEM
3) COMPARE TO SCHEDxx MEMBERS IN SYS1.SAMPLIB. (CICS [THAT IS DFHSIP] SHOULD NOT HAVE "YES". (SEE ARTICLE ON PROGRAM PROPERTIES TABLE IN "MAINFRAME AUDIT NEWS" ISSUE NO. 1
======================================================== ======================================================== ========================================================

3) AUTHORIZED CALLER TABLE REPORT #3



CRITICAL STEPS TO TAKE:


1) MAKE SURE IT'S EMPTY; TURN THE PAGE!
======================================================== ======================================================== ========================================================

4) RACF EXITS REPORT #4


LISTS RACF EXITS, INCLUDING PRE- AND POST- EXITS FOR THE FIVE RACF FUNCTIONS (RACINIT, RACDEF, RACHECK, FRACHECK, AND RACLIST). ALSO EXITS FOR PASSWORD CHANGE, RACF COMMANDS, DATASET NAMING CONVENTIONS, AND PASSWORD ENCRYPTION.

CRITICAL STEPS TO TAKE:


1) MAKE SURE IT'S EMPTY. IF SO, TURN THE PAGE!
2) IF THERE ARE EXITS, OBTAIN SOURCE LISTINGS. EVALUATE THEIR FUNCTION AND WHETHER THEY INTRODUCE ANY EXPOSURES.
======================================================== ======================================================== ========================================================

B) USER/GROUP REPORTS (4)


1) SELECTED USER ATTRIBUTE REPORT #5
2) SELECTED USER ATTRIBUTE SUMMARY REPORT #6
3) STARTED PROCEDURES TABLE REPORT #7
4) GROUP TREE REPORT #8 ======================================================== ======================================================== ========================================================

B1) SELECTED USER ATTRIBUTE REPORT #5


LISTS USERIDS WHICH HAVE SPECIAL, OPERATIONS, OR AUDITOR ATTRIBUTES, AND USERIDS WHICH ARE REVOKED.
IF THE ATTRIBUTE IS A GROUP ATTRIBUTE, THEN YOU WILL SEE THE WORD "GROUP". IF IT IS A USER ATTRIBUTE, THEN YOU WILL SEE THE WORD "SYSTEM".
ON THE RIGHT SIDE OF THE PAGE, MAY LIST USERID ASSOCATIONS FOR RRSF. THIS WILL REQUIRE A SEPARATE EVALUATION.

CRITICAL STEPS TO TAKE:


1) MAKE SURE THAT IBMUSER IS REVOKED.
2) FOR GROUP ATTRIBUTES, ISSUE A LISTUSER COMMAND TO SEE IN WHAT GROUPS THE USER HAS THE GROUP ATTRIBUTES (CLEVERLY CALLED "CONNECT ATTRIBUTES" TO CONFUSE YOU). THEN SEE THE GROUP TREE REPORT TO DETERMINE THE SCOPE OF THE GROUP ATTRIBUTE. COMPARE TO STANDARDS AND STRATEGY FOR GROUP TREE STRUCTURE AND DELEGATION OF AUTHORITY. GROUP ATTRIBUTES APPLY TO THE GROUP INVOLVED, ALL THE GROUPS OWNED BY THAT GROUP, ALL THE GROUPS THAT THEY OWN, AND SO ON DOWN THE GROUP TREE. (OWNERSHIP IS THE IMPORTANT LINK, NOT SUPGROUP.)
3) FOR SPECIAL AND OPERATIONS ATTRIBUTES, DETERMINE WHAT AUTHORIZATION IS NEEDED, AND SEE IF THE AUTHORIZATION IS THERE. DETERMINE WHETHER THE USERS TRULY NEED THE ATTRIBUTES. (USE SAUDIT AND OPERAUDIT SETTINGS WITH SETR AND THE RACFRW.) HOW IS THE DECISION MADE TO GIVE SOMEONE SPECIAL OR OPERATIONS? IS THERE AN OWNER FOR THESE PRIVILEGES, IN THE SAME WAY THAT THE PAYROLL HEAD IS THE OWNER OF THE PAYROLL APPLICATION?
4) NOTE WHICH USERS HAVE SPECIAL AND OPERATIONS FOR LATER USE.
======================================================== ======================================================== ========================================================

B2) SELECTED USER ATTRIBUTE SUMMARY #6


LISTS NUMBER OF USERS DEFINED TO RACF, NUMBER OF USERS WITH SPECIAL, OPERATIONS, AUDITOR, AND REVOKED (BOTH SYSTEM AND SPECIAL VERSIONS)

CRITICAL STEPS TO TAKE:


1) (EXCLUDING IBMUSER, WHICH SHOULD BE REVOKED) IF MORE THAN 2 USERS OUTSIDE OF RACF ADMINISTRATION WITH SYSTEM SPECIAL, OR MORE THAN 2 USERS ANYWHERE WITH OPERATIONS, ASK "WHY?" AGAIN. YOU SHOULD HAVE AN "OWNER", THAT IS THE PERSON WHO IS AUTHORIZED TO DECIDE THAT SOMEONE SHOULD OR SHOULD NOT HAVE THESE PRIVILEGES. CONSIDER USE OF A "FIRECALL" USERID WITH SPECIAL AND OPERATIONS WITH THE PASSWORD KEPT IN A SAFE IN THE COMPUTER ROOM. THIS WOULD LET A SYSTEM PROGRAMMER HAVE TOTAL RACF PRIVILEGES IF TRULY NEEDED IN AN EMERGENCY.
2) CALCULATE PERCENTAGE OF ALL USERIDS WHICH ARE REVOKED. IF GREATER THAN SAY 15 PERCENT, THEN ASK WHAT IT MEANS.
======================================================== ======================================================== ========================================================

B3) STARTED PROCEDURES TABLE #7


LISTS STARTED TASKS (OR PROCEDURES OR STC'S), AND THE USERID AND GROUP ASSIGNED TO EACH
A "YES" UNDER THE PRIVILEGED OR TRUSTED COLUMN MEANS THAT EVERY RACHECK FOR THAT STARTED TASK IS IMMEDIATELY ALLOWED.
AN ASTERISK ("*") AS THE LAST ENTRY IN THE LEFT-HAND COLUMN MATCHES EVERY PROCEDURE NAME NOT LISTED EARLIER. YOU WANT THIS, IN ORDER TO MAKE SURE THAT EVERY STC HAS A RACF USERID ASSOCIATED WITH IT

CRITICAL STEPS TO TAKE:


1) MAKE SURE THAT THE LAST ENTRY HAS AN ASTERISK. IF IT HAS AN EQUALS SIGN ("="), THEN MAKE SURE THAT IT HAS A GROUP SPECIFIED.
2) ASK "WHY?" FOR EVERY "YES" UNDER PRIVILEGED OR TRUSTED. OTHER THAN IBM-SUPPLIED ENTRIES, THERE IS USUALLY LITTLE JUSTIFICATION.
3) MAKE SURE THAT ALL USERIDS FOR STARTED TASKS ARE PROTECTED (THAT IS, MARKED NOPASSWORD AND NOOIDCARD).
4) MAKE SURE THAT THERE ARE SEPARATE USERIDS FOR: JOB SCHEDULER, DB2 SUBSYSTEMS, CICS REGIONS, TAPE MANAGEMENT SOFTWARE, ETC.
5) CHECK THE PRIVILEGES (OPERATIONS AND SPECIAL) FOR THE JOB SCHEDULING SOFTWARE, SINCE ITS USERID WILL BE PROPAGATED TO PRODUCTION JOBS. (THIS MAY LEAD YOU TO INVESTIGATE HOW PRODUCTION JOBS GET THEIR USERIDS ASSIGNED TO THEM. IT IS NOT ACCEPTABLE FOR ALL PRODUCTION JOBS TO HAVE THE SAME RACF USERID.)
======================================================== ======================================================== ========================================================

B4) GROUP TREE REPORT #8


LISTS ALL THE GROUPS, ORGANIZED BY WHICH IS A SUPGROUP TO WHICH OTHER GROUP. THIS IS USED FOR DELEGATION OF AUTHORITY IN RACF.
THE GROUP SYS1 IS FIRST, AND IS LEVEL 1. EVERY GROUP WHICH HAS SYS1 AS A SUPGROUP IS A LEVEL 2 GROUP. EVERY GROUP WHICH HAS A LEVEL 2 GROUP AS ITS SUPGROUP IS A LEVEL 3 GROUP. (AND SO ON)
TO FIND OUT WHICH GROUP IS THE SUPGROUP OF ANOTHER GROUP, PUT YOUR PENCIL ON THE FIRST LETTER OF THE NAME OF THE OTHER GROUP. MOVE THE PENCIL ONE CHARACTER TO THE LEFT; IT WILL NOW BE ON A VERTICAL LINE. FOLLOW THE VERTICAL LINE UP UNTIL IT RUNS INTO THE FIRST LETTER OF THE NAME OF THE SUPGROUP.
TO FIND OUT THE OWNER OF ANY GROUP, SEE IF THERE IS A NAME IN PARENTHESES TO THE RIGHT OF THE GROUP'S NAME. IF SO, THEN THAT IS THE USERID WHICH IS THE OWNER OF THE GROUP. IF NOT SO, THEN THE OWNER IS THE SAME AS THE SUPGROUP.
PLOT THE SCOPE OF GROUP ATTRIBUTES, SUCH AS GROUP SPECIAL, BY NOTING THAT THEY PROPAGATE DOWNWARDS AS LONG AS A GROUP OWNS A GROUP.

CRITICAL STEPS TO TAKE:


1) IF THERE IS A WRITTEN STRATEGY FOR DELEGATION OF AUTHORITY AND THE STRUCTURE OF THE GROUP TREE, THEN SEE IF THE ACTUAL GROUP TREE MATCHES THE STRATEGY. OTHERWISE, TURN THE PAGE!
======================================================== ======================================================== ========================================================

C) CLASS DESCRIPTOR TABLE #9


LISTS EACH RESOURCE CLASS, BOTH IBM-SUPPLIED AND YOUR- SYSTEM-PROGRAMMER-SUPPLIED, ALONG WITH INDICATION OF STATUS, AUDIT, STATISTICS, DEFAULT UACC, AND OPERATIONS- ALLOWED.
REVIEW THE MEANINGS AND RECOMMENDATIONS FOR EACH CLASS. MARK YOUR PRINTOUT WITH WHAT YOU LEARN.
AUDITING SHOULD BE YES FOR ALMOST EVERY CLASS, WITH THE EXCEPTION OF THE CLASSES USED FOR USS. THESE INCLUDE: DIRACC, DIRSRCH, FJOBJ, FSSEC, PROCACT, AND PROCESS.
(TURNING ON AUDIT FOR FSOBJ OR PROCESS CAN RESULT IN A LARGE NUMBER OF SMF RECORDS. THE USE OF AUDIT FOR THESE CLASSES SHOULD BE ADDRESSED SEPARATELY.)
TURNING ON AUDIT FOR THE OTHER CLASSES IS A GOOD IDEA, BUT PERHAPS NOT A MAJOR AUDIT FINDING.
YOU CAN IGNORE STATISTICS (SEE SETR LIST PRESENTATION).
HAVE AN "OWNER" FOR EACH CLASS, THAT IS SOMEONE WITH AUTHORITY TO DECIDE WHAT THE RULES SHOULD BE
THE DEFAULT UACC SPECIFIES THE SOURCE OF THE UACC IF SOMEONE CREATES A RULE FOR THIS RESOURCE CLASS AND FORGETS TO SPECIFY THE UACC. THIS IS NOT CRITICAL.
A "YES" UNDER OPERATIONS-ALLOWED, MEANS THAT A USER WITH THE OPERATIONS ATTRIBUTE HAS OPEN ACCESS TO RESOURCE IN THAT CLASS (JUST AS OPERATIONS ALLOWS A USER TO ACCESS A DATASET).

CRITICAL STEPS TO TAKE:


1) MAKE SURE THAT EVERY CLASS (OTHER THAN THE ONES FOR USS DESCRIBED ABOVE) HAS AUDIT TURNED ON. THIS IS A GOOD IDEA, BUT NOT A CRITICAL SHORTCOMING IF NOT DONE.
2) MAKE SURE THAT THE CLASSES YOU WANT TO USE ARE ACTIVE. THESE PROBABLY INCLUDE: DASDVOL, TAPEVOL (TO CONTROL BYPASS LABEL PROCESSING), APPL, FACILITY, TSOPROC, TSOAUTH, OPERCMDS, JESSPOOL, SURROGAT, RACFVARS, NODES, VTAMAPPL, AND SERVAUTH.
THEY ALSO LIKELY INCLUDE THE PROGRAM AND GLOBAL CLASSES, HOWEVER THESE ARE NOT CONTROLLED BY THE SAME "ACTIVE/INACTIVE" SWITCH AS THE OTHER CLASSES. THE PROGRAM CLASS IS MADE ACTIVE BY ISSUING A SETR WHEN(PROGRAM) COMMAND. (SEE SETR LIST, 1ST LINE.). THE GLOBAL CLASS IS MADE ACTIVE BY ISSUING SETR GLOBAL(classname). (SEE THE GLOBAL ACCESS TABLE BELOW.)
3) YOU PROBABLY WANT TO HAVE AN OWNER IDENTIFIED FOR EACH CLASS, THAT IS A KNOWLEDGABLE PERSON RESPONSIBLE FOR DECIDING WHETHER TO USE THE CLASS, AND WHAT THE RULES SHOULD BE. FOR EXAMPLE, THE RACF ADMINISTRATOR MAY NOT KNOW ENOUGH ABOUT VTAM TO DECIDE WHETHER AND HOW TO USE THE VTAMAPPL RESOURCE CLASS. IT IS USEFUL THEN TO HAVE SOMEONE (PERHAPS THE VTAM SYSPROG) RESPONSIBLE FOR MAKING THE DECISION.
4) TO KEEP THE AUDITORS HAPPY, IT US OFTEN WORTHWHILE TO MAKE A LISTOF THE RESOURCE CLASSES, ALONG WITH AN INDICATION OF WHO IS THE OWNER OF EACH CLASS, AND WHAT THAT PERSON'S RECOMMENDATION IS ON WHETHER TO USE THE CLASS. FIND A WAY TO FORMALIZE THIS WITHOUT A LOT OF PAPERWORK, AND TELL THE AUDITORS THAT THIS IS YOUR COMPANY'S STANDARD FOR HOW THE RESOURCE CLASSES SHOULD BE USED. (THE AUDITORS ARE THEN INVITED TO COMPARE YOUR ACTUAL SETTINGS TO THE STANDARD. IF THEY HAVE A PROBLEM WITH THE STANDARD, IT IS THEIR JOB TO SHOW SPECIFIC BUSINESS RISK RESULTING FROM THE STANDARD.) THIS HELPS TO POSITION THE RACF ADMINISTRATOR AS SOMEONE WHO CARRIES OUT THE DECISIONS OF OTHER PEOPLE, THE PEOPLE WHO HAVE THE KNOWLEDGE AND AUTHORITY TO MAKE THE DECISIONS.
======================================================== ======================================================== ========================================================

D) GLOBAL ACCESS TABLE #10


THIS IS A PERFORMANCE FEATURE WHICH SAYS FOR SPECIFIED RESOURCE CLASSES THAT PARTIAL RULES ARE TO BE LOCKED IN MEMORY. FOR EXAMPLE, IF YOU HAVE FREQUENTLY USED DATASET WHICH IS NOT SENSITIVE, THEN YOU CAN SPECIFY WITH A GLOBAL RULE THAT ANYONE IS ALLOWED TO READ IT. THEN EVERY RACHECK AGAINST THAT DATASET FOR READ WILL BE ALLOWED, WITHOUT I/O TO THE RACF DATASET, AND WITHOUT LOGGING.
THIS TAKES EFFECT ONLY UNDER WHEN:
-- GLOBAL IS ACTIVE FOR THE RESOURCE CLASS IN QUESTION (SEE SETR LIST OR SEE THE GLOBAL ACCESS TABLE IN THE DSMON.)
A COMMON, AND SENSIBLE, ENTRY IS &RACUID.**/ALTER WHICH SPECIFIES THAT ANY USER HAS ALTER ACCESS TO ANY DATASET WHOSE HIGH LEVEL QUALIFIER IS THE SAME AS THE USER. &RACGPID IS USED IN SIMILAR FASHION TO DENOTE USER'S GROUP.
NOTE THAT AN ENTRY OF SYS1.**/READ IS ALMOST CERTAINLY A MISTAKE, EVEN THOUGH ONCE UPON A TIME IT WAS RECOMMENDED IN SOME IBM MANUAL. READ ACCESS TO SYS1.UADS, TO THE RACF DATABASE AND ITS BACKUP, TO SYS1.VTAMLST, AND TO OTHER SYSTEM DATASETS WOULD REPRESENT A SECURITY EXPOSURE.
NOTE THAT ALTER ACCESS TO A CATALOG ALLOWS YOU TO DELETE A VSAM DATASET CATALOGUED IN IT.

CRITICAL STEPS TO TAKE:


1) MAKE SURE THAT RULES ARE APPROPRIATE, AND THAT THEY ARE BASED ON ANALYSIS SO THAT MEMORY IS NOT WASTED ON INFREQUENTLY USED NAMES. MAKE SURE THAT THE CONDITIONS LISTED ABOVE ARE MET.
======================================================== ======================================================== ========================================================

E) SELECTED DATASETS REPORT #11


LISTS SENSITIVE DATASETS, INCLUDING: THE DSNAME, THE VOLSER WHERE IT LIVES, WHY IT WAS INCLUDED, WHETHER THE RACF BIT IS ON ("RACF INDICATED"), WHETHER IT IS RACF PROTECTED, AND THE DEFAULT UACC.
DON'T RELY JUST ON THE UACC. IT CAN BE AFFECTED BY WARNING, BY GLOBAL ENTRIES, AND BY THE PERMIT LIST.
N.M. MEANS THE DISK PACK IS NOT MOUNTED. N.C. MEANS THAT THE DATASET IS NOT CATALOGUED. N.F. MEANS THAT THE DATASET IS NOT FOUND.

CRITICAL STEPS TO TAKE:


1) MAKE SURE THAT NO APF LIBRARIES HAVE A UACC OF UPDATE OR HIGHER. (AUDITORS LOVE THIS.)
2) MAKE SURE THAT THE RACF DATASET AND ITS BACKUP ARE ON DIFFERENT DISK PACKS (AND DIFFERENT PATHS IF YOU CAN).
3) MAKE SURE THAT THE PROTECTION SEEMS APPROPRIATE (UACC OF NONE FOR SYS1.UADS AND FOR THE RACF DATASETS, ETC.)
4) MAKE SURE THAT NO GLOBAL ENTRIES (SEE PREVIOUS REPORT) UNDERCUT THE DATASET RULES LISTED IN THIS REPORT IN A WAY THAT CAUSES A SECURITY EXPOSURE.
======================================================== ======================================================== ========================================================

III SUMMARY AND CALL TO ACTION


YOU SHOULD NOW BE ABLE TO INTERPRET DSMON BETTER THAN MOST AUDITORS. CHECK IT PERIODICALLY. COMPARE IT TO LAST MONTH AND TO THE STANDARD. IF YOU DON'T HAVE A STANDARD, THEN GO GET ONE!
FOR EACH RESOURCE CLASS, MAKE SURE YOU HAVE AN "OWNER", THAT IS, SOMEONE WITH THE AUTHORITY TO DECIDE WHAT THE RULES SHOULD BE AND WHETHER THE CLASS SHOULD BE ACTIVE. LET THE OWNER MAKE THE DECISIONS; LET THE RACF ADMINISTRATOR CARRY THEM OUT. DO THE SAME FOR ASSIGNMENT OF USERIDS, AND FOR THE SPECIAL AND OPERATIONS PRIVILEGES.
BETWEEN WHAT YOU KNOW ABOUT SETR LIST, AND ABOUT DSMON, YOU SHOULD BE ABLE TO MAKE A SIGNIFICANT CONTRIBUTION TO IMPROVING USE OF RACF IN YOUR SHOP. YOU CAN MAKE SECURITY BETTER, AND FIX THINGS BEFORE THE AUDITORS FIND THEM. DO IT WITH GUSTO!
A NOTE TO AUDITORS: MANY OF THE RECOMMENDATIONS IN THIS REPORT ARE CONSIDERED BY THE AUTHOR TO BE "SELF-EVIDENT". THAT DOES CONSTITUTE A STANDARD TO BE USED IN AN AUDIT, ANY MORE THAN ANY OTHER "AUDIT CHECKLIST" DOES. ANY AUDIT FINDING WITH WHICH THE AUDITEE DOES NOT AGREE REQUIRES YOU TO DEMONSTRATE THE SPECIFIC BUSINESS OR OPERATIONAL RISK, OR TO WITHDRAW THE FINDING. AUDITEES ARE QUITE JUSTIFIED IN DISAGREEING WITH AN AUDIT RECOMMENDATION UNLESS YOU HAVE DEMONSTRATED A SPECIFIC BUSINESS RISK OR A FAILURE TO FOLLOW SOME STANDARD WHICH THE AUDITED ORGANIZATION AGREES APPLIES TO THEM.
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, 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