Winner of the APPLDATA Golf Shirt Announced
Priscilla Bates of Cessna Aircraft is the winner of the gorgeous Henderson Group golf shirt. She was the first to call and note the use of the APPLDATA operand on resource rules for IMS transactions. (If you specify APPLDATA('REVERIFY'), then the transaction is considered sensitive. If you sign on to IMS, and then walk away from your terminal, no one can execute that transaction without first entering your RACF password. The password is the way of proving that it is still you at the terminal and not some stranger.) Wouldn't it be great if CICS gave us the same flexibility and control? How about for RACF commands too? Hayim, does this constitute a formal request?
Texas RUG Shares Info
Contact Melinda Sealey at (972) 556- 4115 (or email@example.com) for more info. They meet the 3rd Friday of January, April, July, and October.
NEW YORK RUG Meeting Dates
On Wednesdays, from 1 to 5 PM: July 22, 1998, then October 21, 1998 (revised), and then January 13, 1999. Mark your calendars now. See inside for details.
On Thurdays, from 9AM to Noon: July 23, 1998, then October 22, 1998 (revised) and then January 14, 1999. Mark your calendars now. See inside for details.
We Get Questions About the Status of Some RUGs
We would like to hear (and publicize) what's happening with the Michigan/Ohio RUG, the Seattle RUG, the Southern California RUG, and any others. If you have any news, please let us know. Thanks. (If your area doesn't have a local RUG, why not start one?)
How to Get E-Mail Announcements of RUG Meetings
Send Stu an E-mail (to firstname.lastname@example.org) with the message RUG ALERT. Stu will add you to a broadcast list. He will then try to E-mail directions to NYRUG and BWRUG meetings to everyone on the list as soon as they are available. We may also announce meetings on the RACF-L list server on the Internet (see page 8).
More on Hackers:
Here, in no particular order, is a partial list of attack points and methods hackers might address first to penetrate a RACF/MVS shop (like yours?):
1) Use dial-in ports (using a demon dialler, aka war dialler) to connect to your system from outside. Once they have access to your system, they will likely try to logon to applids that don't use RACF to check out userid/password. (An applid is a program you can sign onto from a terminal, such as TSO, CICS, and IMS.) Commonly used applids with well- known, vendor-supplied passwords are likely lines of attack.
2) Once signed onto TSO as a regular user, get the privileges of the operating system by attacking unprotected backdoors, such as user SVCs, and APF authorization.
3) Copy unprotected sensitive data, especially: residual data (tape and disk), Bypass Label Processing, and tape datasets exposed by the "17- character dsname" problem.
4) Guess passwords, both RACF passwords and passwords in SYS1.UADS for userids which are not defined to RACF.
5) Get use of the OPERATIONS attribute or access to production datasets by submitting a job into production which accesses data it shouldn't.
6) Use the RVARY command to shut down the system.
7) Submit a batch job from TSO which will be a new CICS region, and use it to send CICS transactions to a production AOR region.
More on the TSOPROC Resource Class
Last issue we noted that it is difficult to control use of TSO solely with RACF, since if a user is defined in SYS1.UADS and not in RACF, then he can log onto TSO. We noted that IBM documentation tells us NOT to use generics in the TSOPROC class, so a backstopping rule (named **) couldn't be used. Well, we were wrong again! As Hayim Sokolsky points out, you can use generics in the TSOPROC class and you can use a backstop. Hayim also gives us a suggestion on why the IBM documentation says what it does: When you first logon to TSO through RACF, RACF doesn't know what tsoproc you use as a default. So TSO finds the RACF rule in the TSOPROC class to which the user is permitted, and uses that as the default tsoproc for that user. Of course, if that rule is a generic containing an asterisk or percent sign, then TSO might have a bit of trouble using it as a TSOPROC. (Of course, any errors in this article belong to the RUG News, and not to Hayim.) If you think that this documentation (or logic) should be changed, please notify your SHARE RACF Request Coordinator. Thanks, Hayim.
How to Start Addressing Tape Security
We all know that tape datasets have their own security issues, including the 17-character dsname problem, the residual problem, Bypass Label Processing, and the "two files on a cartridge" problem. To address these, you need to use your tape management software (TMS, UCC-1, aka CA-1; or TLMS; or Control-T most likely. [We understand that IBM has a tape management software package out. We will give a free Henderson Group golf shirt to any satisfied user of the IBM product who fills us in on how it works and why they like it.] Almost no one bothers to define rules in the RACF TAPEVOL class.) In the process, you have to become more of a DSO, and less of a RACF specialist.
To address these tape security issues, you need to understand the calls to RACF your tape management software can issue. You will want to activate options which distinguish between "foreign tapes" (that is, those whose volsers are NOT defined to the tape management software) and local tapes (those whose volsers are defined to the tms). The cleverer tape management systems let you require RACF protection over all local tapes, with separate rules for controls over foreign tapes. This lets you permit system programmers for example to read a foreign tape with a non-standard dsname, without letting him read the local, master payroll tape.
Because tape management systems carry the full 44-character dsname for tape files, you can have the tms call RACF to check out the dsname properly, thus solving the 17-character dsname problem. Note: you still want to turn on the RACF option TAPEDSN. Read the documentation for your tms, and you will see that they recommend TAPESDSN in addition to the tms calling RACF for the dsname.
Yet Another Freebie From RACF
When IBM re-packaged RACF by putting it into a product called "OS/390 Security Server", they added other software to the product for free. First, we got the DCE Security Server, and then the mainframe Firewall. Now they've thrown in another piece of software called the LDAP server. (Ginzu knives, next?) LDAP is something worth learning about. More next issue.
Interesting Products Column
We have not evaluated these, but think every RACF shop should know about them.
Updates to Our Recent Notes on RACF Release 4 Features
1) We should have mentioned that the WHEN(SYSID(sydid)) operand of the PERMIT command only works with PROGRAM class profiles.
2) Of course, the correct spelling of the FACILITY class rules for digital certificates is: IRR.DIGTCERT.LIST, IRR.DIGTCERT.ADD, IRR.DIGTCERT.ALTER, and IRR.DIGTCERT.DELETE.
Fifteen Minute Project to Improve Your RACF
Use the DSMON Class Descriptor Table as a Project Planner and to help your boss understand how much work there is to be done with RACF in your shop:
1) Take the CDT printout and draw a line through all the resource classes you KNOW you don't care about in your shop: perhaps the VM classes, the IMS classes, the B1 security classes like SECLABEL, and so on.
2) For the remaining classes, draw a bracket around the matched pairs (like TCICSTRN and GCICSTRN). For matched pairs which don't use the individual class (for example, we all use PROGRAM, but we all safely ignore PMBR), draw a line through the individual class name.
3) Set up your own code with x's, o's and other characters (or highlight in different colored magic markers) to indicate which classes you have addressed completely, which classes you need to learn more about, which classes need to be addressed and are essential to good security, and which are optional (meaning, you might get around to doing something with them if you ever get some spare time and staff, but they aren't essential to effective security). Mark the status of each resource class, so you know what's been dealt with, what you can ignore, and what you need to understand better before you decide what to do with it.
4) Pin the CDT to your wall and watch your progress each month, as the list of resource classes still needing attention becomes shorter and shorter. (Until the next release, that is)
5) Turn on auditing for all resource classes (SETR AUDIT(*)) and generics for all classes which will accept it (SETR GENERIC(*)).
Questions and Answers
Qþ Alright, then. What resource classes are "essential to effective security"?
Aþ Many knowledgeable people consider these classes essential in most MVS shops:
MVS Classes: RACFVARS, DASDVOL, TAPEVOL (no rules, just right), APPL, GLOBAL, DSNR (if you have DB2), FACILITY, PROGRAM, TSOPROC, TSOAUTH, PROPCNTL, APPCLU, VTAMAPPL
CICS Classes: TCICSTRN, ACICSPCT, CCICSCMD, SURROGAT
JES Classes: OPERCMDS, JESSPOOL, JESINPUT, SURROGAT, NODES, STARTED
and others, depending upon the installation.
Qþ So give us a better answer than last issue on what programs should be protected in the PROGRAM class.
Aþ These programs should be protected in most MVS/RACF shops, at least the copies in APF- authorized libraries. (See if you know what each program does and whether you can guess what mischief would be possible if you hadn't protected them. See if you can tell from IBM documentation which ones have additional protection such as Write-To- Operators-with-Reply to protect them. See if you can tell from your computer room documentation which WTORs your operators have written instructions for. See if you can tell from IBM documentation which ones have calls to RACF built into them to provide better protection than the PROGRAM class does.)
What other programs do you think belong on this list? Call Stu at (301) 229-7187. The most interesting entry by September 1 wins a free, comfortable, and attractive Henderson Group golf shirt.
NYRUG (New York RACF Users Group) and BWRUG (Baltimore/Washington RUG) NEWS
NYRUG: At Our Next Meeting Beta Systems is hosting our meeting. They are offering a free lunch and product demo before the meeting, if you want to learn more about their software . The product presentation is completely separate from, and precedes our regular meeting. Please call Mike Scharf at (732) 238-9698 if you will be attending the lunch. (To learn more about Beta Systems, see "Interesting Products" earlier in this issue.)
At the regular meeting, Lori Dwyer of LANcomp will present "Staying on Top of Security When Computer Power is Being Distributed to the World". Afterwards, Stu Henderson will describe "What Mainframers Need to Know About TCP/IP". We will have a Q&A session for other topics afterwards.
Time: Wednesday, July 22, 1998. The lunch and product presentation will begin at 11:30AM. The regular meeting starts at 1 PM until it's too late to go back to the office.
Place: Millennium Hotel on Church Street, across the street from the World Trade Center (WTC 5)
BWRUG (Baltimore/Washington RUG): Beta Systems is hosting our meeting. They are also offering a free lunch and product demo after the meeting, if you want to learn more about their software. The product presentation is completely separate from, and will follow, our regular meeting. Please call Don Wardwell at (610) 261-2262 if you will be attending the lunch. (To learn more about Beta Systems, see "Interesting Products" earlier in this issue.)
At the regular meeting, Stu Henderson will describe "What Mainframers Need to Know About TCP/IP". We will have a Q&A session for other topics afterwards.
Time: Thursday, July 23, 1998 at 9:00. The regular meeting will be from 9 to noon. The lunch and product demo will be from noon until about 1PM.
Place: Bethesda Marriott Residence Inn at 7335 Wisconsin Avenue in Bethesda, MD, phone (301) 718-0200. This is right at the Bethesda stop on the Red Line of the Metro. (The Red Line goes quickly to Union Station for MARC and Amtrak riders.)
By car: Take the beltway (I495) to Exit 34 ("Wisconsin Avenue"). [This is Northwest of DC, near where I270 joins I495.] Take Wisconsin Ave South (aka Route 355 South) about 2.5 miles. Watch for the Hyatt/Bethesda Metro on the right. Immediately past the Hyatt, take the next left onto Montgomery Avenue. Go one block and take the first right onto Waverly Avenue. Waverly Avenue wraps around to the front of the hotel, where valet parking is available.
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. 1) HG04 Effective RACF Administration (formerly called How to Implement and Administer RACF Effectively) ($1695) Sept. 21-25, 1998 in NYC Nov. 16-20, 1998 in Washington, DC Feb. 22-26, 1999 in Clearwater, FL 2) HG05 (formerly HG44) Advanced RACF Administration ($850) Dec. 10-11, 1998 in Washington, DC 3) HG17 How to Be an Effective OS/390 (MVS) 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) May 27-29, 1998 in NYC Dec. 7-9, 1998 in Washington, DC 4) HG40 Mastering Windows NT Security ($850) Oct. 19-20, 1998 in Washington, DC
RACF User Services (Key Phone Numbers / Addresses)
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 http://www.mindspring.com/~ajc10/garug.html
IBM RACF home page: http://www.s390.ibm.com/products/racf/racfhp.html
IBM S/390 home page, including RACF: http://www.s390.ibm.com
IBM FTP site, including RACF stuff: lscftp.kgn.ibm.com
IBMLink at: http://www.ibmlink.com
Beta Systems: http://www.betasystems.com
the Henderson Group: http://www.stuhenderson.com/index.html
Return to Home Page
Copyright ©: 1998, Stuart C. Henderson
Revised - June 28, 1998