GARUG Alive and Well

The Georgia RACF Users Group (GARUG) is thriving again, under the direction of Simon Dodge. Their next meeting will be in October. Learn more, and get on their distribution list, by contacting them at http://www.garug.net . Please note that the end or the address is net and not something else. GARUG is famous for providing great, free SAS programs on their website.

Carolina RUG Is Underway

The Carolinas (both North and South) RACF Users Group is also back in business. For more info, please visit: http://www.rshconsulting.com/rugs/CRUG.htm  for details.

New Study on Tape Protection Available

As a result of discussion on the RACF-L, Russell Witt and Stu Henderson (with technical assistance from a variety of vendors) identified critical, often- neglected issues in mainframe tape security. They then identified ways to address these issues, with whatever tape management software you have. They documented the issues and solutions in a presentation to SHARE, and the handout from the presentation is now available at http://www.stuhenderson.com/TAPESEC1.PDF 

NEW YORK RUG Meeting Dates

Thursday, October 27, 2005 from 10AM to around 5PM. PLEASE NOTE THAT PRE-REGISTRATION IS REQUIRED. THIS IS A LOT OF TRAINING AVAILABLE IN ONE DAY. You will not be allowed to attend without pre-registering (it's free), as described inside. Mark your calendars now. See inside for details. The meeting after that will be in April, 2006, probably on a Tuesday, Wednesday, or Friday. Please note the NYRUG will meet twice a year from now on.

-------------------------------------------

Todays Proverb

"If you don't measure it, then you can't manage it." (applies to number of RACF violations in the violations report, and to other places)

Southern California RUG Active Again

Under Mark Hahn. Visit http://www.rshconsulting.com/rugs/SCRUG.htm  for more info.

Vanguard Conference on West Coast in 2006

It's scheduled for July 8-12, 2006 in San Diego, CA. Note that the regular sessions start on the Sunday, not the Monday.

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: www.stuhenderson.com.

The Health Checker

IBM has added a new feature to z/OS 1.7 which affects RACF administrators, as well as auditors. It is the Health Checker. This is a started task which runs all the time in the back of your computer (UNIX people might call this a daemon), and which checks that certain system settings (including RACF settings) are correct.

Each rule describing a setting to be verified is called a check. Checks are organized by software product (including RACF). You will want to know what checks can be set for RACF (and for your tape management software too). And you will want to know what reporting happens when a check fails. (IBM suggests that notifying appropriate parties would be better than implementing automated corrections.)

For each check, you can specify: how often it is checked, its severity, and message routing and descriptive codes.

Each check can be active or inactive. Each check can be enable or disabled.

The Health Checker runs with supervisor state and a USS UID of 0 (Superuser). The programs which are the checks also execute in supervisor state, making them a possible source of malicious or accidental system problems. You will want strong change control and quality assurance over any home grown checks.

IBM provides pre-defined checks for us for these software products and elements: consoles, GRS, RACF, RSM, SDUMP, USS, VSM, and XCF.

When a check detects a problem, it decides whether the problem is serious. If not serious, the Health Checker merely logs the problem. If serious the Health Checker can issue an exception message. Often these are Write to Operators (WTOs). You will want to be sure that your operators have clear written instructions on how to respond to various Health Checker messages.

Since you can specify route codes for messages, you can have all the security messages get routed to you. Routecode 9 is reserved for security messages. You can dedicate a TSO session in your office to be a virtual console (with the CONSOLE command in TSO, and permission to the TSOAUTH resource class rule named CONSOLE and an OPERPARM segment on your RACF user record. Set it up so that only route code 9 messages are sent to your console. Make sure that Health Checker messages you're interested in are assigned route code 9.

You will need to set up the Health Checker with a RACF rule in the STARTED class, as well as giving it a userid.

The Health Checker calls RACF for various security functions, using a new resource class named XFACILIT. (Looks like the FACILITY class got overloaded. Maybe when this one gets overloaded, IBM will give us the YFACILIT class, and then the ZFACILIT class.)

You can learn more about the Health Checker from this IBM manual: "IBM Health Check for z/OS User's Guide" SA22-7994-00.

RACF Commands for New Features

In earlier issues, we have described some of the RACF enhancements with the latest release, including dynamic definition of new classes, additional support for security labels (especially with DB2), recoverable passwords, and synchronization of passwords between LDAP and RACF. Here are some commands to get familiar with:

1) To allow upper and lower case passwords for userids:

SETR PASSWORD(MIXEDCASE) and to undo it: SETR PASSWORD(NOMIXEDCASE)

(Don't turn this one on until you are sure you want it. It's very hard to turn it off after many users have entered passwords with lower case characters.) Also, this is a great excuse to expose users to a training program in how to make passwords "easy to remember, but difficult to guess". Also, if you don't already, this is a great excuse to make passwords be ALPHANUMERIC, which in RACF requires at least one number and at least one letter, without specifying where they have to be. This makes it more difficult to guess passwords. An even better requirement would be to replace ALPHANUMERIC with MIXEDNUM, as described on the next page under Password Rules.

Along with this, you will need to define new password rules, as described next.

2) To set new rules for passwords to accept upper and lower case letters in passwords:

SETR PASSWORD(RULE5 (LENGTH(6:8) content (1:8))) where content is one of the new options: MIXEDCONSONANT, MIXEDVOWEL, or MIXEDNUM. For more detail, see the following section on Password Rules.

3) To set a new minimum password change interval (for example, ten days), issue:

SETR PASSWORD( MINCHANGE(10))

This will have the effect of preventing users from cycling through the password history all in one day to allow them to re-use the same password they've been using all along.

4) To define a new resource class named $PRETZEL dynamically: SETR CLASSACT(CDT) AUDIT(CDT) RACLIST(CDT) RDEF CDT $PRETZEL UACC(NONE) CDTINFO(POSIT(19) MAXLENGTH(8) + FIRST(ALPHA) OTHER(ALPHANUM) RACLIST(ALLOWED) + DEFAULTUACC(NONE) GENLIST(DISALLOWED) OPERATIONS(YES) ) SETR RACLIST(CDT) REFRESH

Password Rules

Password rules set with the SETR command can be confusing, especially with the new mixed case options. Here's a brief summary and a strong recommendation. You can specify up to eight rules. A new password typed in by a user will be accepted if it matches any of the up to 8 rules. So you can put in a new rule, wait a few weeks, and then remove an old rule if you want to change gracefully. DO NOT USE THE FOLLOWING EXAMPLE UNTIL YOU HAVE READ ALL THE DETAIL BELOW IT. To create rule number 5, specifying that for any password with a length of 6 to 8, the positions 1 to 8 must be filled with mixed numerics, you would issue:

SETR PASSWORD(RULE5 (LENGTH(6:8) MIXEDNUM (1:8)))

If this were the only rule, it would imply a minimum length of six. Length can never be more than eight characters.

In RACF, ALPHANUM and MIXEDNUM have special meanings. ALPHANUM allows letters and numbers, and also requires at least one letter and at least one number, without specifying where. (The three special characters $, @, and # in the US, are of course treated as upper case alphabetic consonants, as you can tell from the way they sound.) MIXEDNUM allows upper and lower case letters, and numbers, and requires at least one upper case letter and at least one lower case letter and at least one number, without specifying where. The three special characters are of course considered to be upper case. We strongly recommend use of ALPHANUM to start, and eventual conversion to MIXEDNUM, but only after proper training of users. These will make it harder to guess passwords.

If Your Installation is Like Most Others,

Then the idea of IPLing every weekend is obsolete. Many z/OS shops are scheduling IPLs at least a month, in some cases, six months apart. And the number of un-scheduled IPLs is approaching zero. IBM says that with a properly configured sysplex, you should expect no more than three to four minutes of unscheduled down time PER YEAR. RACF is helping to support this development by letting us make changes on the fly (with the STARTED and CDT resource classes for example), and by continuing to be reliable.

How to Tell Whether Your Mainframe Talks to the Internet

Issue the TSO command NETSTAT at the READY prompt. The output will tell you the name of every started task using TCP/IP, as well as the IP address and port number it uses. Each of these is a path into your system. You'll want to know that it's safe, or that you have secured it with RACF. The SERVAUTH resource class in RACF can help you to do this.

A Different Opinion on Reviewing the Violations Report

It is a common audit recommendation that "RACF administration should review the violations report daily." In the opinion of Larry Merry Ogleby, our resident RACF theoretician, this is a mistake. "I challange your readers to name one instance where reviewing the violations report has had any effect other than the creation of headaches in administrators and irritation in users. This is asking RACF administrators to take on responsibility without giving them the authority to go with it. They often get punished as a result." Over a long lunch in his favorite Bethesda Mexican restaurant, Larry expounded on his topic. "To simplify things, you should break violation attempts into two types: RACINIT and RACHECK. RACINIT violations have to do with answering the question "Who is this user?". RACHECK violations have to do with answering "Can this user do X?", and should be treated very differently.

"RACINIT violations could be from fat-fingering the password on your keyboard, carelessness, failure to train users, or someone trying to hack your system by guessing passwords. You should evaluate these for patterns: by user, by department, by trend over time (looking both for spikes and for very gradual, but long-term degradation). Reviewing any individual RACINIT violation is not likely to prove useful.

"RACHECK violations describe when someone tried to do something she shouldn't have. They should be treated differently, depending upon the situation. A simple way to break them down is to separate datasets and resource classes, and then to break them down further by violations against each of: individual user's datasets and resources, testing datasets and resources, system datasets and resources, and production datasets and resources.

"In the case of violations against individual user's datasets and resources, you leave it to the users to sort it out, much like letting children sort their differences over their toys.

"For violations of test datasets and resources, you would consider violations as evidence that security is being tested as well as functionality for an application. This would be a positive development. In a perfect world, the Production Turnover or Quality Assurance group would require evidence of testing violations before moving an application into production. In a perfect world, RACF administration would be informed of and involved in the planning for a new application and there would be no hunger in the world.

"In the case of violation attempts against system or production datasets and resources, senior management should be informed. The RACF administrator should not be expected to enforce company discipline, because the RACF administrator does not have the authority to do so. If in a typical year there are more than one or two violation attempts against system or production datasets or resources, and an informed senior management does not change the situation, then the message to all users is that such behavior is acceptable. This will encourage some users to keep poking at RACF and your system until they find a hole. However, this is not a problem if your RACF implementation has no holes.

"If on the other hand, you get stuck reviewing a long violation report which doesn't distinguish among the types of violation, then you should make a point of taking a ten minute break every hour, allowing your eyes to relax by looking at something far away."

Thanks Larry

NYRUG (New York RACF Users Group):

Our next meeting is at IBM, 590 Madison Avenue, Room (room 1219). Attendees must present a government issued photo ID to enter the building. Admission is free to hear these great speakers, but you must pre-register by emailing NO LATER THAN NOON OCTOBER 26, 2005 to Mark Nelson (markan@us.ibm.com) with "NYRUG MEET" in the subject line and your name and company in the body. Pre-registration is highly recommended. Once again, we have some of the best speakers possible on topics you need to learn about.

Starting at 10AM: Ending a Little Before 5PM

Starting at 10:00 AM

• RACF for z/OS 1.7 Update (Walt Farrell, IBM)
• IBM's new Health Checker for z/OS and RACF (Mark Nelson, IBM)
• The SPARCLE privacy policy management functional code (Clare-Marie Karat, IBM)
• Lunch around noon to 1PM (on your own or the IBM cafeteria)
• How to Secure APPN, the Vulnerable Path (Stu Henderson, the Henderson Group and Peter Hager, Net'Q)
• RRSF (Remote Resource Sharing Facility) (Russ Hardgrove, RACF Level 2 Support, IBM)
• Break around 3PM
• RACF Audit Report Generation (Mary Winfield and Francis DeCostanzo, Platinum Precision Software)

  A)    HG64 How to Audit MVS, RACF, ACF2, CICS, and DB2 ($1450 in 2005, $1550 in
        2006)      
                Nov. 2-4,        2005 in Washington, DC
                Apl. 5-7,        2006 in Washington, DC
                Nov. 1-3,        2006 in Clearwater, FL


 

  B)    HG65 How to Audit z/OS with USS, TCP/IP, FTP, and the Internet
                (This class is a logical follow on to HG64.)
                         Date and Location to be Announced 

  1)    HG04 Effective RACF Administration    ($1995)  
                Feb. 27-Mar. 2,          2006 in Clearwater, FL
                Sept. 18-21,             2006 in Washington, DC

  2)    HG05 Advanced RACF Administration  ($1990)                        
                Mar.  6-9,               2006 in Clearwater, FL

  3)    HG06 UNIX (USS) for RACF Administrators  ($460)   
                March    3,              2006 in Clearwater, FL

  4)    HG17 Comprehensive z/OS Security (Formerly: 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)  ($1290)                  
                TBD        2006 in Washington, DC