The First Step In Breaking Into a Computer Over the Internet
is to learn the IP address (like a phone number) of its computer. This will be four numbers separated by dots. The tool to find out an IP address is called whois. This tool lets you (or anyone else) ask the Internet, "what is the IP address for this name: www.somename.com?"

If you have a program to issue whois over the Internet for you, you can use it. If not, go to Google, and enter whois as a keyword. You'll find lots of sites that will do the whois for you. (Note that many of these sites will do a whois only for the names that they have registered. You may have to look a while for names ending in .gov and some others. But the info is out there for the asking.)

Step 2 is to send a message to each port number at that IP address to see which ports are active. (A port is a number which corresponds to an application, such as email.) The ports that reply to the message are active, and will include in the reply information about what version of what software they are.

Step 3 is to Google to find which of those software packages has security flaws.

NEW YORK RUG Meeting Dates
Tuesday, April 29, 2003 from 12:30 to 4PM. PLEASE NOTE CHANGE IN TIMES AND THAT YOU MUST HAVE A PHOTO ID TO ENTER THE BUILDING. Speakers' initials include: RH, RH (the other one), and WF (the only one). Mark your calendars now. See inside for details. The meeting after that will be in October, probably on a Tuesday from 1 to 5PM. Please note the NYRUG will meet twice a year from now on.

BALTIMORE/WASHINGTON RUG Meeting Dates
The BWRUG will not meet this season. Our next meeting will be in October, likely on a Monday from 1 to 5PM. Mark your calendars now. See inside for details. Please note the BWRUG will meet twice a year from now on. -------------------------------------------

If You Aren't Familiar With These Web Sites That Offer Free Stuff for RACFers, You Should Check Them Out
(Please see back page for addresses.)

• The RACF List Server (RACF-L)
• Thierry Falissard's homepage
• Nigel Pentland's homepage
• IBM's RACF Goodies Site
• The GARUG site (soon to be back in operation)

To Get a Free Subscription to the RACF User News
Phone Stu at (301) 229-7187 with your request, leaving your name, postal address (sorry, only US postal addresses; others will need to read issues online), and phone. For back issues and articles on topics like the SERVAUTH resource class, check his website: http://www.stuhenderson.com.

How to Tighten Up Your RACF Implementation
Suppose you've already got the basic stuff in place. You've already turned on PROTECTALL, BATCHALLRACF, XBMALLRACF, TAPEDSN. You've even put just a few datasets under EOS (Erase-On-Scratch). You don't even worry about dealing with auditors because you are so far past them. Now you really want to ice the cake. What do you do next to make your RACF implemention even better. Here are some ideas:

• IBM points out that if you use the RACF panels in ISPF to reset someone's password, then the command, including the new password is stored in the ISPLOG dataset. You should either not use ISPF for changing passwords (same for your help desk!!) or make sure that that dataset is completely secured. You can find the definition for this dataset in your logon proc or by asking your system programmer. Please make sure that this dataset is not made readable by some global rule, and that it has Erase-On- Scratch active. A similar concern applies as well to password resetting commands issued as operator commands, since they are listed to the system log.

  
  

• Remember RESTRICTED users? Users with this attribute can only access datasets and resources to which they or their groups are explicitly permitted. This means that they can't access something by means of the UACC in a dataset or resource rule. However, they can access certain UNIX (USS) files unless you stop them. UNIX files whose security bits (the three sets of RWX bits) permit access to the rest of the world can be accessed by RESTRICTED userids, unless you stop them. The way to stop them is by defining a UNIXPRIV resource class rule named RESTRICTED.FILESYS.ACCESS with UACC(NONE). If this rule exists, then RESTRICTED userids who aren't permitted to this rule can't access USS files by means of the "rest of world" permission bits.

  
  

• Make all auto-logged userids be PROTECTED. This includes every userid which is automatically logged on without a password. This includes userids for: started tasks, CICS default users, CICS terminals which are automatically logged on ("terminal preset security"), consoles, and users defined in the SURROGAT class. This will protect against two risks: someone knowing or guessing the password and abusing it AND someone revoking all the important userids by logging onto them with enough invalid passwords.

  
  

• Make sure that your GLOBAL rules don't undercut your other rules improperly. Smart auditors look at the DSMON report to see if your sensitive datasets are properly protected. The really smart auditors then look at the DSMON Global Access Table Report to see if any of the GLOBAL rules permit access to a sensitive dataset. For example, if you have a GLOBAL DATASET rule that allows READ access to all SYS1.* datasets, then you likely have a weakness, even if other GLOBAL rules specify access of NONE for SYS1.UADS, SYS1.RACF, etc. A GLOBAL rule of SYS1.*/READ is only safe if you know ALL the SYS1 datasets which should have a UACC of NONE, both now and in the future. While you're looking at DSMON, check to make sure that the RACF dataset and its backup are on different disk packs.

  
  

• Make sure the JESSPOOL class is used to control browsing of printouts on the print queue.

  
  

• Make sure the OPERCMDS class is used to control who can execute operator commands.

How RACF Admins Should Be Thinking About TCP/IP

TCP/IP (alright, Transmission Control Protocol / Internet Protocol, aren't you glad you asked?) is the communications protocol of choice when connecting two dissimilar computers, especially over the Internet. It introduces two new, simple concepts: IP addresses and ports. An IP address is like a phone number; it identifies a computer so that messages can be routed to it. It often corresponds to one of those names that ends in .com, .gov, etc.

A port is a number that identifies a program which supports some application. For example, port 25 is often assigned to the email program. To send email to a user at some computer, you send the message to the IP address of the computer, specifying port 25. When the message arrives at that computer, the computer looks at the port number, and hands the message to the email program. The email program processes the message by routing it to the correct recipient.

This is all important to RACF admins, because RACF can control access to your computer by IP address and/or by port number. For example, if you wanted to permit only a certain IP address to download files from your computer (using FTP [File Transport Protocol] on ports 20 and 21), you could use RACF to control those ports.

Control of IP addresses and ports is handled differently for out- bound and for in-bound messages. You need to control both, since TCP/IP represents a path into the system you are charged with securing.

Before describing the RACF controls, we should note that other people, and other tools, will have a hand in securing TCP/IP in your organization. Find out who they are. Buy them lunch. Learn what IP addresses are used, and what ports, on your mainframe. Learn what firewalls are in use, and how they filter messages based on IP address, port number, and whether in-bound or out-bound. Learn who administers the control files and what RACF specifications they put in them.

To use RACF to control out-bound TCP/IP, use the SERVAUTH resource class. By "out-bound", we mean from your computer to the Internet. If some programmer writes a program which executes on your computer and tries to bind to a given IP address and port, you can control this with RACF.

To control in-bound TCP/IP, your first line of defense should be a firewall, which can filter messages on the basis of IP address, port number, and other criteria. The TCP/IP control file, and the control files used by its daemons, can provide additional protection. In particular, these control files can require that a user be identified (for example by means of a RACF userid and password) before the user is allowed access.

For FTP, you can use the TERMINAL resource class to control access by IP address, and you can use the APPL class to control access to FTP.

You can also use the APPL class to control access to USS (use a rule named OMVSAPPL in the APPL class).

[Did we mention that TCP/IP on the mainframe is the most secure TCP/IP commonly available (when the available security tools are properly implemented)?]

How to Tell What Release of RACF You Are On

Recent releases of RACF have contained what many consider a bug on the first page of the DSMON report, which tells you what release of RACF you are on. The report does not give a useful release number. But, thanks to Russ Hardgrove of IBM and the RACF-L, we now have the following chart which summarizes: release number, what DSMON says, and what the FMID is. (FMID is the number IBM uses to identify a piece of software and its release number.)

RACF Release	What DSMON Says	FMID
OS/390 2.6	RACF VERSION 2 RELEASE 6.0	HRF2260
OS/390 2.7	RACF VERSION 2 RELEASE 6.0	HRF2260
OS/390 2.8	RACF VERSION 2 RELEASE 6.0.8	HRF2608
OS/390 2.9	RACF VERSION 2 RELEASE 6.0.8	HRF2608
OS/390 2.10	RACF VERSION 7 RELEASE 70.3	HRF7703
z/OS 1.1	RACF VERSION 7 RELEASE 70.3	HRF7703
z/OS 1.2	RACF (FMID HRF7705)	HRF7705
z/OS 1.3	RACF (FMID HRF7706)	HRF7706
z/OS 1.4	RACF (FMID HRF7707)	HRF7707

You should now be able to predict these values for futures RACF releases, based on IBM's policy of consistancy in naming things. Note: You may find that RACF release numbers don't correspond one for one with operating system release numbers. We have seen a new release every Spring and every Fall for some time now, but IBM is smart enough not to put out a new release if they don't have real, new function to offer at the time.

New Security Seminars from DelCreo: HIPAA Workshop, CISSP Prep, Other
DelCreo Inc. offers the classes listed below and others.

• The HIPAA Workshop is April 17 in Des Moines, IA, and May 14 near Cleveland, OH.
• The CISSP Prep class is April 8-10 in Atlanta, and June 17-19 in Des Moines.
• The Business Continuity Planning Workshop is May 12-16 near Cleveland, OH.
• The Information Security Return on Investment Class is May 12-13 near Cleveland, OH.

New Free Email Newsletter for Mainframe Auditors
To learn more about the Mainframe Audit News (MA News), check Stu's website: http://www.stuhenderson.com 

Interesting Products Column
We have not evaluated these products, but think they might be of interest to RACF administrators:

• SMA_RT (Security Monitor Alert in Real Time) by Type-80 Security Software recognizes suspect patterns of activity and sends real time alerts to the appropriate people. For more info see their website at http://www.type80.com  or call Jerry Harding at (571) 332-4444.
• RACF CLEANUP software tool named TASA from InfoSec. Inc. identifies userids, groups, group connections, and permissions actually used by RACF to resolve access checks; reports unused RACF entries and generates RACF commands to perform or restore cleanup. For info, contact John Busse (847) 381-5870 or http://www.infosecinc.com/information/TASA.htm 
• jb cubed has two products: Portal Pass (a single-signon product that acts as a "credential bridge") and Host Data Connect (which lets Windows users access the mainframe with security controlled by RACF). For more info, contact Mike Day at (703) 318-8000 or go to http://www.jbcubed.com 

New Free Email Newsletter for Mainframe Auditors
To learn more about the Mainframe Audit News (MA News), check Stu's website at: http://www.stuhenderson.com 

This Issue's Wish
Wouldn't it be nice if IBM gave us a switch in RACF to prevent users from creating dataset rules beginning with their own userids? This would protect against the following hilarious prank: Set up a CLIST which goes into an infinite loop creating RACF dataset rules (with the ADDSD command) whose names start with your userid. Then execute the CLIST, which will keep running until it fills up the RACF database. [Until IBM gives us such a switch, the next best way to prevent this problem likely be a RACDEF pre-exit.] (Such a prank should be considered grounds for termination and worse.)

NYRUG (New York RACF Users Group) and BWRUG (Baltimore/ Washington RUG) NEWS
NYRUG: At Our Next Meeting

The meeting is free, but you must register in advance by sending an email to Mark Nelson of IBM at:
markan@us.ibm.com
with
NYRUG List
as the subject and your name and company in the text.
You must get on the list by Noon, Monday, April 28th to get into the meeting. (Also be sure to bring a photo id.)
Our next meeting will is at IBM, 590 Madison Avenue, in the Eastside Theatre, Room 976. Attendees must present a photo ID to enter the building. Please note the early start and finish times. We will have three great speakers: Bob Hansel of RSH Consulting will speak on "RACF & REXX" (how to get reports from the RACF Database Unload Utility using REXX). Russ Hardgrove of IBM RACF Level 2 will speak on "SAFTRACE" (the nifty tool that lets us view all the calls to RACF). Walt Farrell from IBM RACF Development willl speak on "The World of RACF Program Control and PADS" (important stuff you need to know about using the PROGRAM class in any release and enhancements in z/OS R4).

Time:
Tuesday, April 29, 2003 from 12:30-4PM. Please note the early times, photo id requirement, and registration requirement.

Place:
IBM, 590 Madison Avenue in the Eastside Theatre, Room 976. Attendees must present a photo ID to enter the building.

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

BWRUG (Baltimore/Washington RUG):
The BWRUG will not meet this season. See you in October.

Simplified Approach to UNIXPRIV Rules
The UNIXPRIV resource class is used to control delegation of authority within USS (UNIX under MVS). [Other UNIXs only allow delegation of authority as follows: You are either SUPERUSER or nobody. Did we mention that USS is the most secure UNIX commonly available, and that it has the most precise delegation of authority?] The UNIXPRIV rules are so numerous, and have such funny names, that we thought we would simplify things by describing some of the rules whose names begin SUPERUSER.FILESYS and the power they give over USS files:

• SUPERUSER.FILESYS READ permission to this rule lets you read any [USS] file, and lets you read or search any directory. UPDATE permission lets you write to any file, but not to any directory. (UPDATE permission of course implies READ permission.) CONTROL permission lets you write to any directory as well.
• SUPERUSER.FILESYS.CHANGEPERMS READ permission lets you use the chmod command to change the permission bits of any file, and to use the setfacl command to change any ACL.
• SUPERUSER.FILESYS.CHOWN READ permission lets you change the owner of any file, not just the files you own (using the chown command).

         The Henderson Group now offers its series of "How to Audit.." 
seminars for IT auditors. These describe clearly how the associated software 
works, where the control points are, how to collect and interpret data, and 
how to conduct the audit.  The workbooks include complete audit programs.  
More information is available at our website: www.stuhenderson.com.  If you 
have a class you would like to have added to this series, please let us know.  
(See info on "RACF and Security" classes below.) 

  A)     HG70 How to Audit Cross-Platform Applications ($820)  
                  Nov. 3-4,        2003 in Clearwater, FL 

  B)     HG71 How to Audit Mainframe/Internet Connections ($820)  
                  Oct. 9-10,       2003 in Bethesda, MD (near Washington, DC)

  C)     HG72 How to Audit TCP/IP ($410)  
                  Apl. 9,          2003 in Bethesda, MD (near Washington, DC)

  D)     HG73 How to Audit CICS ($410)  
                  Oct. 8,          2003 in Bethesda, MD (near (Washington, DC) 

  E)     HG74 How to Audit RACF ($820)  
                  Nov. 5-6,        2003 in Clearwater, FL

  F)     HG75 How to Audit MVS ($410)  
                  Nov. 7,          2003 in Clearwater, FL 

         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.  For more info or to see what 
students say about these classes, please go to www.stuhenderson.com.  (See 
info on "How to Audit ..." classes above.) 

  1)     HG04 Effective RACF Administration    ($1895)  
                  May     5-8,              2003 in Seattle, WA
                  Sept. 16-19,              2003 in New York City
                  Oct.  20-23,              2003 in Cape Code, MA
                  Mar.   9-12,              2004 in Clearwater, FL

  2)     HG05 Advanced RACF Administration  ($1890)                             
                  May   12-15,              2003 in Seattle, WA
                  Sept. 23-26,              2003 in New York City
                  Feb.  17-20,              2004 in Clearwater, FL

  3)     HG06 UNIX (USS) for RACF Administrators  ($410)                                
                  May       9,              2003 in Seattle, WA
                  Sept.    22,              2003 in New York City
                  Mar.      8,              2004 in Clearwater, FL

  4)     HG17 How to Be an Effective z/OS or OS/390 (MVS) Data Security Officer)
         (covers CICS, VTAM, DB2, and JES security along with MVS security, SAF,
         OS/390, and z/OS)  ($1190)                  
                  Nov.  17-19               2003 in Bethesda, MD (near Washington, DC)

         PROC 0
         WRITE &SYSMVS &SYSNAME &SYSSMFID &SYSLRACF &SYSRACF &SYSPLEX
         WRITE &SYSDATE &SYSTIME
         EXIT