RACF is a trademark of IBM. This newsletter is not affiliated with IBM in any way.
Learn What Other Shops Found Out With the Password Cracker Program
Many of us have used the free password cracker program (which guesses RACF and ACF2 passwords, and tells us which ones are correct guesses). [See page 8 for how to get your free copy; Please note that E-mail is a much better way to ask for it!]. Many of us apparently have found that a large number of passwords in our shops are guessable. (The record I've heard so far is 50 percent of the passwords in one shop, and, no, I won't tell you where. The "50 percent" is interesting; where it happened is confidential.)
Kurt Meiser of ITSS, the author of the program, is offering to compile user experiences and to share them with us, while maintaining complete confidentiality. You can tell him what you've learned, what passwords worked and didn't work in your shop, and what percent of passwords you were able to guess in your shop.
Kurt will keep it all confidential, but will combine it with others to make a presentation to RACF user groups. Let him know at kmeiser@ibm.net, or if you're not on the net, mail to: ITTS, 11 Phillips Rd, Poughkeepsie, NY 12603 USA. Thanks for sharing.
RACF Release Cycle Revealed
We can expect a new release each Spring and Fall. Some RUGs are interested in teleconferencing with IBM to get details of new releases from developers rather than from marketing people. If your RUG is interested, let your IBM rep know, or give Stu a call. Also ask your local IBM rep if he or she will host your next meeting at their teleconferencing facilities.
NEW YORK RUG Meeting Date for January (REVISED)
On Wednesdays, from 1 to 5 PM: Jan. 28, 1998; and April 22, 1998. Mark your
calendars now. On January 28: Dan Tum Suden of IBM will describe IBM's new
tool for single signon: GSO. He will also describe the new mainframe firewall
which you get for free with RACF when you get the OS/390 Security Server).
PLUS: If you have questions about RACF and CICS, a panel of knowledgeable
speicalists will be there to answer them in our dedicate RACF/CICS QandA! We
will have a Q&A session for other topics separately.
BALTIMORE/WASHINGTON RUG
Meeting Date for January
On Thurdays, from 9AM to Noon:
No meeting in January, 1998; but then April 23, 1998.
Mark your calendars now.
-------------------------------------------
Corrected Contact for TAMPA RUG
Jim Cuddy is making it happen. For more info, to join, or to volunteer to help,
call Jim at (800) 237-8931 Ext. 78192.
Carolinas RUG Continues
Bill Sharber of First Citizens Bank is the new head. Contact him for more
info at (919) 779-8148.
Jacksonville RUG Comes Alive
Tommy Shelton of Barnett Banks is taking the lead. Call him at (904) 987-7635
to take part.
RACF/DB2 Exit Details
IBM's offers a new exit from DB2 to let RACF control DB2 security
(as opposed to DB2's internal security, which is based on the GRANT and REVOKE
commands and the Seven Security Tables in DB2's catalog). The name of the
exit is DSNX@XAC. It gets control from DB2 at three different times: DB2
system start-up, DB2 system shut-down, and whenever DB2's internal security is
normally called.
The exit can be tailored, based on its return codes to DB2. One
return code value tells DB2 to allow the access; another says to fail it; a
third tells DB2 to use its internal security as if the exit hadn't been called
at all. This lets you phase in use of the exit gradually. You can do this by
setting it up to allow or fail based on RACF if there is a matching RACF rule.
Set it up so that if there is no matching RACF rule, it gives a return code to
tell DB2 to use the old, internal security.
The names of the RACF resource classes come in two flavors: the
standard names and the tailored names (much like using TCICSTRN in some CICS
regions, but some other class name like T$PRDTRN in other regions). The names
of the rules are different, depending upon whether you use the standard class
names or the tailored class names. Whichever you use (and you can use both),
you will need to know the names of the DB2 subsystems.
To Learn the Names of the DB2 SubSystems, look in SYS1.PARMLIB for members
with names starting with IEFSSN. Each DB2 subsystem will be defined in one of
these members with a line containing ,DSN3INI, Just to the left of
",DSN3INI," will be a name of up to four characters. This is the subsystem
name. For example, it might be DB2T for the test DB2 subsystem, and DB2P for
the production DB2. You would see these names in lines starting like this:
These are the same subsystem names you use in the DSNR resource class.
The Standard Class Names all begin with MDSN, followed by two characters
describing what they protect: MDSNBP for bufferpools, MDSNCL for collections,
MDSNDB for databases, MDSNPK for packages, MDSNPN for plans, MDSNSG for
storage groups, MDSNSM for subsystems, MDSNTB for tables, and MDSNTS for
tablespaces.
Each of these has a grouped version, similar to the way TCICSTRN
has GCICSTRN.
When you use the standard class names, you put the subsystem name
as the first part of each rule's name. For example, in the class MDSNTB, you
might have two rules names DB2T.**, and DB2P.**.
The Tailored Class Names all begin with the letter M, followed by the
subsystem name, followed by the two characters described above for standard
class names, followed by a special character (such as # or $). For example,
the class names for tables might be: MDB2TTB$ in for the test subsystem and
MDB2PTB$ in the production subsystem.
Each of these has a grouped versions, similar to the way TCICSTRN
has GCICSTRN. With the tailored names, your sysprog must define the names in
two places (the SAF router table and the RACF class descriptor table) before
you can use them.
When you use the tailored class names, you do not put include the
subsystem name in the name of the rule. This is because with tailored class
names, the subsystem is already included in the name of the class.
When Your DBA Learns That You Can Protect Several Similarly Named Tables With
a Single Rule (ending in an *), he or she will be sooo jealous. They might
even change the way they name things.
Password History Change Improvement
Before RACF release 4, when you changed someone else's password, the old password
was not stored in the user record, to prevent it from being re-used. As of RACF release 4, IBM
has improved this by putting the old password into the password history of the user record
whether you change the password for someone else, or whether you change your own password.
HG Sponsors New Web Site to Share InfoSecInfo
The Henderson Group's new web site (at
http://www.stuhenderson.com) provides
articles on computer security, back issues of the RACF Users News, hot links to other sites,
information on RACF user groups, and other info on infosec. If you have information you'd like
to make available to others (with credit to you), contact Stu at (301) 229-7187 or email him at
stu@www.stuhenderson.com.
RACF/CICS Use of SURROGAT Rules
CICS release 4 uses the SURROGAT class for some special purposes. You will want to
know how to define these rules before they are needed. In general, CICS 4 insists that everything
which goes on in a region must have a RACF userid associated with it. (Note for example, the
use of preset terminal security to associate a userid with a terminal definition. Note also the use
of the default userid specified in the DFHSIT [or SIT] macro.)
A second operand in the DFHSIT macro determines whether CICS makes SURROGAT
class checks. If the CICS system programmer specified a SIT with XUSER=YES, then CICS does
RACF SURROGAT checking.
CICS makes these checks to determine whether the CICS region's userid should be
permitted to use the:
How to Control Use of the APPCLU Resource Class with CICS
This class is used with APPC to prove that the other end of the
communication session is with who you think it is. This is easier to
understand when you think of making a phone call. The phone number you dial is
comparable to the LU or logical unit that APPC uses to make a connection.
Your VTAM system programmer assigns the LUs, the same way (almost) that your
phone company assigns your home a telephone number.
To make sure that APPC is connecting to the right LU, it can use
the APPCLU resource class in RACF. The records in this class contain
encryption keys. APPC at one location takes a random number, encrypts it with
the key from APPCLU, and sends it to the other APPC location. The second
location gets the same key from his RACF database, decrypts the random number,
and re-encrypts it with a second key (which is also obtained from the APPCLU
records in the RACF database). The second location now sends the re-encrypted
random number back to the first location, which decrypts it (you guessed it,
using the second key which he gets from the APPCLU records in his RACF
database). If the result is the same as the random number he started out
with, he says to himself "That must be location x (or whatever the other LU
is) because only location x knows both of those encryption keys!".
Very few shops use this class.
If you choose not to use it too, this should be the result of a
sensible risk assessment, not because the APPC people don't know your name.
To turn off use of this class in a CICS region, specify XAPPC=NO
in the DFHSIT macro for the region.
Use of this class outside of CICS is primarily with APPC/MVS,
which we may cover in a future issue.
Fifteen Minute Project to Improve Your RACF
Try these SETR rules, which are all safe (with exceptions noted) and which can get your
shop ready for various RACF improvements and/or keep auditors off your back:
If you aren't familiar with any of these operands, or why they might help you, why not
take a minute to look them up?
Interesting Products Column
We have not evaluated these, but think every RACF shop should know about them.
Permanently Interesting Products Column
We have not evaluated these, but think every RACF shop should know about them.
HG RACF and Security Training 1998 Schedule:
The Henderson Group offers its RACF and computer security/audit seminars
around the country and on-site too. See the details below or call (301) 229-
7187 for a free seminar catalog.
RACF List Server on the Internet
To join, send E-mail to the administrator for the server. (Don't send it to the server itself or your
request will be routed to every subscriber.) For example, if your name is John Smith and you want to
subscribe, then send this E-mail:
subscribe racf-l john smith
to the address: LISTSERV@uga.cc.uga.edu or LISTSERV@UGA.BITNET.
The reply will include directions on how to get info such as a list of all
subscribers, an index to previous comments, and a command summary.
Other Internet places:
Georgia RUG home page on the Internet
IBM RACF home page:
IBM S/390 home page, including RACF:
IBM FTP site, including RACF stuff:
IBMLink at: http://www.ibmlink.com
Palace Guard:
Proginet:
Consul:
SysData:
the Henderson Group:
DB2T,DSN3INI,...
DB2P,DSN3INI,...
http://www.consulrisk.com
1) HG04 Effective RACF Administration (formerly called How to Implement and
Administer RACF Effectively) ($1695)
Feb. 23-27, 1998 in Clearwater, FL
May 4-8, 1998 in Atlanta
Sept. 21-25, 1998 in NYC
Nov. 16-20, 1998 in Washington, DC
2) HG05 (formerly HG44) Advanced RACF Administration ($850)
March 2-3, 1998 in Clearwater, FL
April 20-21, 1998 in NYC
Dec. 10-11, 1998 in Washington, DC
3) HG17 How to Be an Effective Mainframe Data Security Officer)
(covers CICS, VTAM, DB2, JES, and other security along with MVS
security, SAF, and OS/390)
(3 days in 1998 for $1150)
Mar. 30-Apl 1, 1998 in Denver, CO
May 27-29, 1998 in NYC
Dec. 7-9, 1998 in Washington, DC
4) HG40 Mastering Windows NT Security ($850)
April 6-7, 1998 in Atlanta
Oct. 19-20, 1998 in Washington, DC
http://www.mindspring.com/~ajc10/garug.html
http://www.s390.ibm.com/products/racf/racfhp.html
http://www.s390.ibm.com
lscftp.kgn.ibm.com
http://www.palaceguard.com/pgshome
http://www.proginet.com
http://www.consulrisk.com
http://www.sysdata.com
http://www.stuhenderson.com/index.html