RACF (part of z/OS Security Server) is a trademark of IBM. This newsletter is not affiliated with IBM in any way.
Cincinnati RUG Starts
The Cincinnati RACF Users Group is starting
up shortly. For more info contact Barbara
Rhoads (Barbara.Rhoads@ocas.com) or Joe
Graves (Joseph.Graves@LibertyMutual.com)
What is "Zed O S"
This is how the British pronounce
"z/OS". What have they done to our
language? Do they shut down their systems
with a Zed EOD command?
Three Rules of Thumb for RACF Admins
NEW YORK RUG Meeting Dates
Wednesday, October 29, 2003 from
10AM to 4:30PM. PLEASE NOTE THIS IS A
SPECIAL MEETING WITH DIFFERENT TIMES
AND REGISTRATION REQUIRED. THIS IS
A LOT OF TRAINING AVAILABLE IN ONE
DAY. Speakers include: Bruce Wells of IBM
on USS; Russ Hardgrove of IBM on "RACF
Level 2 Update"; Tom Hackett of IBM on
Websphere security; and Paul de Graaff of
DTCC [but formerly of IBM] on security in a
web-enabled world. Admission is free, but
you must register by email in advance, and
you must provide a government-issued photo
id (details inside.) Mark your calendars
now. See inside for details. The meeting
after that will be in April, 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 April,
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.
-------------------------------------------
To Learn About New Seminar Dates
Email to stu@stuhenderson.com with Seminars in the Subject and
your name and company in the body. We will then send you brief announcements
of our new seminar dates and locations, perhaps three or four times per year.
Of course, you can always check our website
http://www.stuhenderson.com
for current information.
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
New RACF Release to Emphasize Security Labels
The next release of RACF (RACF for z/OS 1.5) will provide additional
support for security labels, including support for security labels with DB2.
Security labels were introduced back with RACF 1.9 to provide an extra layer
of security. You can attach a security label to a userid, to a dataset rule,
and to a resource rule. When a user logs on, he may be permitted to several
different userids, but he is able to log on with only ONE OF THEM AT A TIME.
Later articles in this issue explain security labels in more detail.
The latest release will expand support for security labels to TERMINALs, USS, IP addresses, and the SERVAUTH resource class for TCP/IP. There is also support for SECLABELs (security labels) by SYSID within a SYSPLEX and by Local Area Network.
Many organizations will want to make use of this, both for the extra level of security it affords, and for the flexibility it gives us in separating users, datasets, and resources. If you are a service bureau that wants to keep its clients out of each others' data, or a data center with several types of data that need to be kept separate, SECLABELS will be of great interest to you.
It is easy to implement SECLABELs clumsily, especially if you don't have centralized control. If you use them, take the time to plan it carefully. One possible starting point might be to have one SECLABEL for all non-employees and a different SECLABEL for employees.
You will also find that the SETR command has several switch settings which affect the rigor with which security labels are checked.
What's a Security Label and How Does It Work?
To explain security labels, we will first explain security levels
and security categories. Please do not confuse the two terms: label and
level.
Security Levels
Imagine that you have categorized all the datasets on your computer according to sensitivity. You have assigned each dataset one of perhaps four security levels, which you have named: PUBLIC, PRIVATE, SECRET, and FYEO (For Your Eyes Only). You want RACF to enforce these security levels automatically, so a user with PRIVATE clearance can't touch datasets marked SECRET, even if the UACC is READ. Even if the user is permitted with ALTER access. Please draw a matrix on a piece of paper with these security levels along the left-hand side, with PUBLIC at the bottom, and FYEO at the top.
So you define the security levels to RACF (using the SECDATA resource class). You then assign each user one of the four security levels. You then assign each dataset rule (and some resource rules) one of the four security levels.
Now when a user opens a dataset, the OPEN routine calls RACF to ask "Can this user READ this dataset?" RACF reads the dataset rule, sees that it has a security level, and immediately rejects the request if the user's security level (from his user record) is not sufficiently high. If the user's security level is high enough, then the regular checking of the permit list, UACC, and OPERATIONS proceeds. (Security levels can DENY access. But they never grant access. They just can grant the ability to do the rest of the checking.)
Security Categories
In a similar fashion, categories can provide an extra layer of checking. Suppose that you have identified every dataset as belonging to one of: Marketing, IT, Finance, or Operations. You want to make sure that no one in Marketing can touch Finance data, regardless of the UACC or the permission on the dataset rule. So you define four categories (again using the SECDATA resource class in RACF) named: MKT, IT, FIN, and OPS. You then assign one or more categories to each user. You then assign one or more categories to each dataset rule (and to some resource rules as well). On the paper where you listed the security levels, please list the categories across the top in order: MKT, IT, FIN, and OPS. We will come back to this matrix when we discuss security labels.
Now when a user opens a dataset and the OPEN routine calls RACF to ask permission, RACF looks at the dataset rule. If the dataset rule has one or more categories assigned to it, then the user must have ALL of those categories in his user definition, or RACF will reject the request. As with security levels, security categories can DENY access, but the don't grant access. At most, they can grant the ability to check permit list entries, UACC, and OPERATIONS.
Differences Between Security Levels and Categories
Security levels have numbers assigned to them and are hierarchical. You might assign the numbers: 10, 50, 100, and 200 to the four security levels. When a user opens a dataset, the comparison of the security level in the dataset rule to the security level in the user definition is a numeric comparison. The user's security level must be numerically equal to or higher than the security level in the dataset rule.
It follows that each user definition can have at most one security level. Each dataset and resource rule can have at most one security level.
Categories are not hierarchical and do not have numbers assigned to them. Each user and dataset and resource profile can have zero, one, two, or any number of categories. The user must have all the categories in a dataset rule in order to access the dataset.
With security levels it is possible to run out of numbers, for example assigning number 195 to one level and 196 to another level, then learning that you have to define a level between them.
With categories, it is possible to define so many categories that no on can keep track of them all.
With both security levels and categories, you must have a single, simple standard for your entire organization. Do not let several different groups of people pursue their own standards.
Most organizations do not use security levels and categories. Instead they use security labels, which are built up from the levels and categories.
Security Labels
Security labels are constructed from levels and categories. For example, suppose you wanted to have one name (perhaps BIGDEAL that represented the SECRET level in combination with both the IT and FIN categories. (Please draw a rectangle on the matrix you've been developing that includes IT and FIN, but only on the row containing SECRET. In the rectangle write BIGDEAL. You've just defined a security label named BIGDEAL. When RACF is checking security labels, it does no checking of levels and categories.
What RACF Commands Do We Use for Security Levels and Categories and Labels?
You define the security levels like this:
RDEF SECDATA SECLEVEL ADDMEM(PUBLIC/10 PRIVATE/50 SECRET/100 FYEO/200)
You define the categories like this:
RDEF SECDATA CATEGORY ADDMEM(MKT FIN IT OPS)
You add a level and a category to a user like this:
ALU USER02 SECLEVEL(SECRET) ADDCATEGORY(MKT)
You add a level and a category to a dataset rule like this:
ALD 'STU.TEST.DATA' SECLEVEL(FYEO) ADDCATEGORY(IT)
The opposite of ADDCATEGORY is DELCATEGORY. To eliminate a SECLEVEL, use NOSECLEVEL.
To define a security label:
RDEF SECLABEL BIGDEAL SECLEVEL(SECRET) ADDCAT(IT FIN) UACC(NONE)
PE BIGDEAL CLASS(SECLABEL) ACC(READ) ID(USER02)
How Do SECLABELs Work With DB2?
The next release of DB2 will let you use SECLABELs in DB2 tables. You will add a column to a table which will contain the SECLABEL for each row. When the SECLABEL checking is activated, users will only be able to access rows of the table to which their SECLABEL gives them access. This may be useful to medical insurance organziationss looking to segregate data in a table to satisfy HIPAA regulations, or to a service bureau wanting to keep its clients' data separated.
To make this work, you will define a column AS SECURITY LABEL CHAR(8) NOT NULL WITH DEFAULT.
Question and Answer
Q: We want to link all of our computers, including the mainframe, together, so that an application running on a Windows 2000, UNIX, MVS, or Novell computer can exchange data with DB2, MQ Series, CICS, IMS, and other mainframe software. We want to do this without requiring double signons, and without losing the identity of the individual user. Can this be done?
A: Yes it can be done. There are two main technologies available now on all these platforms to support what you describe. One of these is DCE (Distributed Computing Environment) which includes LDAP (Lightweight Directory Access Protocol) for storing information about users and Kerberos, the security protocol that fixes the "playback" problem. (The playback problem is the idea that a sniffer program on your LAN can learn all the userids and passwords used on that LAN to log onto the mainframe. Even if the userids and passwords are encrypted on the LAN, the sniffer program doesn't have to decrypt them. The user just has to play them back to the mainframe to log on with someone else's userid.) All the types of computer you mention, including MVS, support this now.
The second approach is digital certificates, which are also supported by all these computer types. Digital certificates will be necessary for security over the Internet as well.
RACF supports all of these technologies, and talks directly to the LDAP server software on the mainframe. Look at recent developments in RACF, including EIM (Enterprise Identity Management), AIM (Application Identity Management), Secure Sockets Layer, and PKI (Public Key Infrastructure) support in RACF. Three or four years from now, these will all be considered standard with RACF. Data Security Officers, as well as auditors, will need to be comfortable with these.
A key question will be whether the mainframe is considered the chief security server, or some other computer. To answer this, ask which platform has the best physical security, least down time, and most automated controls and support.
This Issue's Wish
Wouldn't it be great if IBM would gradually fix all the silliness in RACF syntax. For example, give the RDEF command (to create a new resource rule) a second name AR, in order to match the pattern established by AG, AU, and AD? Then give the AUDIT operand on dataset and resource rule commands a second name, maybe SMFLOG, so that AUDIT and GLOBALAUDIT wouldn't be such ridiculous names for almost the same thing.
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
NYRUG (New York RACF Users Group) and BWRUG (Baltimore/
Washington RUG) NEWS
NYRUG: Our Next Meeting
Our next meeting is at IBM, 590 Madison Avenue, in the Eastside
Theatre, Room 976. Attendees must present a government-issued photo ID to
enter the building. Please note the early start and finish times Admission
is free to hear these great speakers, but you must pre-register by emailing
before Oct. 27 to Mark Nelson (markan@us.ibm.com) with "NYRUG Meeting" in the
subject line and your name and company in the body. PLEASE NOTE THAT THIS
EMAIL ADDRESS IS A CORRECTION TO THE INCORRECT ADDRESS PUBLISHED EARLIER!
We will have some of the
best speakers possible on topics you need to learn about:
The morning session focuses on RACF and USS (UNIX System Services, UNIX under MVS), with two presentations by Bruce Wells of the IBM RACF development team: "RACF aned UNIX System Services Identities" and "RACF and UNIX System Services Files".
In the afternoon, Russ Hardgrove of IBM RACF Level 2 presents "RACF Level 2 Update: A Diagnostic Approach". Then Tom Hackett of IBM z/OS Design Support Center speaks on "Websphere Security". Last, Paul De Graaff of DTCC (formerly of IBM) presents "Security in a Web-enabled World: a User Experience".
Time:
Wednesday, October 29, 2003 from 10AM-4:30PM. Please note
the early times.
Place:
IBM, 590 Madison Avenue in the Eastside Theatre, Room 976.
Attendees must present a photo ID to enter the building and must pre-register
in advance.
==============================================================
BWRUG (Baltimore/Washington RUG):
The BWRUG will not meet this season. See you in April.
HG How to Audit Training Schedule: (includes new Fall dates)
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
Apl 1-2, 2004 in Bethesda, MD (near Washington, DC)
B) HG71 How to Audit Mainframe/Internet Connections ($820)
Oct. 9-10, 2003 in Bethesda, MD (near Washington, DC)
Mar. 1-2, 2004 in Clearwater, FL
C) HG72 How to Audit TCP/IP ($410)
Mar. 4, 2004 in Clearwater, FL
D) HG73 How to Audit CICS ($410)
Oct. 8, 2003 in Bethesda, MD (near (Washington, DC)
Mar. 3, 2004 in Clearwater, FL
E) HG74 How to Audit RACF ($820)
Nov. 5-6, 2003 in Clearwater, FL
Apl 15-16, 2004 in Bethesda, MD (near Washington, DC)
F) HG75 How to Audit MVS ($410)
Nov. 7, 2003 in Clearwater, FL
Apl 14, 2004 in Bethesda, MD (near Washington, DC)
HG RACF and Security Training 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. 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)
Oct. 20-23, 2003 in Cape Code, MA
Mar. 9-12, 2004 in Clearwater, FL
2) HG05 Advanced RACF Administration ($1890)
Feb. 17-20, 2004 in Clearwater, FL
3) HG06 UNIX (USS) for RACF Administrators ($410)
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)
HG RACF and Security Training 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. 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)
Permanently Interesting Products Column
This column has been permanently moved from this newsletter to Stu's
website. You can find it at: www.stuhenderson.com/XINFOTXT.HTM
RACF User Services (Newsletter Subscriptions / 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@listserv.uga.edu
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. You will want to set up a filter for incoming emails to direct mail from the list server to a dedicated folder or directory.
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
The RACF User News
is published two times a year
(December, March, and September) to share information
about RACF. All information in it is offered on an "as is"
basis, and should be used at your own risk, and with
your own testing.
Other Internet places: