IBM Mainframe Security: Beyond the Basics-A Practical Guide from a z/OS and RACF Perspective

by Dinesh D. Dattani

Overview

Rather than rehashing basic information—such as command syntax—already available in other publications, this book focuses on important security and audit issues, business best practices, and compliance, discussing the important issues in IBM mainframe security. Mainframes are the backbone of most large IT organizations; security cannot be left to chance. With very little training available to the younger crowd, and older, more experienced personnel retiring or close to retiring, there is a need in mainframe security skills at the senior level. Based on real-life experiences, issues, and solutions to mainframe security from the author’s three decades of practical experience as a mainframe security practitioner, this book fulfills that need.

Product Details

ISBN-13:	9781583478295
Publisher:	Mc Press
Publication date:	10/15/2013
Sold by:	Barnes & Noble
Format:	eBook
Pages:	224
File size:	1 MB

About the Author

Dinesh D. Dattani is a mainframe security consultant and the president of Triple-D Mainframe Services Ltd. He has more than 30 years of mainframe security experience at a number of companies in North America, and his consulting career spans diverse industries and sectors, including banking, telecom, automotive, insurance, energy, government, and service providers. He is the author of nearly 60 articles on mainframe security, including the IBM white paper “Best Practices for System z Security: Mainframe Security Matters—Thinking Outside the Box.” He lives in Toronto.

Read an Excerpt

IBM Mainframe Security: Beyond the Basics

A Practical Guide from a z/OS and RACF Perspective

---

By Dinesh D. Dattani

MC Press

Copyright © 2013 Dinesh D. Dattani
All rights reserved.
ISBN: 978-1-58347-829-5

---

CHAPTER 1

How the Mainframe Provides Security

Any farmer will tell you, only a fool lets a fox guard the henhouse door. — Proverb

One way to implement mainframe security is to let all applications running on the system manage their own security. However, that would be akin to allowing foxes to guard the henhouse. Instead, the mainframe operating system is entrusted with providing security for all users and applications sharing the computer. Being an independent entity, the operating system has no vested interest in compromising the data.

A key integrity feature of the z/OS mainframe operating system is that all programs doing work are kept apart from each other. In other words, one program cannot see what the other is doing. This segregation is implemented via a feature called address spaces, whereby each entity in the mainframe is allocated an address space and cannot look into other address spaces.

Thus, the very foundation of the operating system provides data integrity, as shown in Figure 1.1.

While the operating system provides basic integrity, it uses an "external" security product to do all other security checking.

When we talk about an external security product, we mean it is external to the "core" operating system. However, the security product is still part of the operating system. The security checking has been externalized from the core operating system to enable competing security products to provide mainframe security.

There are three main mainframe security products: IBM's Resource Access Control Facility, or RACF, and ACF2 and Top Secret, both from CA Technologies (formerly Computer Associates International). We will use RACF throughout this book.

The operating system intercepts all authentication and validation requests. It then passes along these requests to RACF, which in turn makes its decision based on information in its security database. In this sense, the operating system is strictly a gatekeeper or go-between; it does not actively make decisions to allow or fail the security requests.

One can think of the operating system as having subcontracted all installation-specific security checking to RACF.

How RACF Does Access Checking

When RACF receives a request for access checking, it decides to grant or deny the request based on information residing in the RACF database. RACF checking for an access request is quite involved. There are of course the "access lists" in RACF profiles that specify who has access, but that's not all. Several other factors influence RACF's decision-making process. In addition to access lists, following are the main factors RACF considers before deciding whether to grant or deny access:

1. Universal access — The "universal access" (UACC) specified in the profile is above and beyond what is in the access lists. For example, if the value is READ and a user ID is not in the access list, then the user ID gets at least READ access.

2. General access — If the profile has an entry of * (an asterisk) in its access list, all user IDs have access that is specified for *. There is a subtle difference between this general access and universal access. This is covered in chapter 11, "Security Administration: Beyond the Basics."

3. Operations privilege — If a user has the OPERATIONS privilege, the user might get access because of that fact. This is discussed in detail in chapter 2, "RACF Special Privileges."

4. Global Access Checking (GAC) table — The GAC table can grant access before the pertaining profile is even checked. This is discussed in detail in chapter 5, "The Global Access Checking (GAC) Table."

5. RACF exits — RACF exits can override all access definitions in the RACF database. This is discussed in detail in chapter 16, "RACF Exits."

The RACF Access Checking Diagram

The diagram in Figure 1.2 is a simplified version of RACF authorization checking. It covers the main areas, but it does not go into the details of seldom-used cases. Let's use the diagram to understand how RACF works, by taking Quiz 1.1.

CHAPTER 2

RACF Special Privileges

In this business you don't even trust yourself. — Former colleague

RACF has provisions for users to have special privileges. The three main special privileges are OPERATIONS, SPECIAL, and AUDITOR.

These three privileges come in two flavors: group-level and system-wide. A group-level privilege is only applicable to one RACF group, and the privilege applies only to users and resources that fall within the scope of the specified group. A system-wide privilege does not have this limitation — it applies to all resources, and to all users.

Note that the following are not discussed in this chapter:

• The UNIX® SUPERUSER privilege. For information about this privilege, refer to chapter 9, "Understanding z/OS UNIX Security."

• Special privileges available in optional system components such as DB2®, CICS®, and IMS®.

The OPERATIONS privilege allows the user to read, write, create, and delete most of the installation's data.

The SPECIAL privilege allows the user to define and administer security profiles and user IDs, and to set RACF global options through the SETROPTS command in the RACF database. It does not allow the ability to manipulate any data, although users with this privilege can do that in a roundabout way, by adding themselves to the appropriate access lists of profiles.

The AUDITOR privilege allows the holder to display all profiles in the RACF database.

In addition, your company might have other special privileges for application software, both homegrown and purchased from vendors.

Logging Special Privilege Activities

The installation should log all RACF activities that are carried out because of the special privileges of their owners. This logging is optional, so it is left up to the installation to implement it. However, auditors often want to see these logs.

Two RACF commands will turn on such logging. The first will log all activities of users carried out by virtue of their OPERATIONS or group-level OPERATIONS privilege:

SETROPTS OPERAUDIT

The other command will log all activities of users carried out by virtue of their SPECIAL or group-level SPECIAL privilege:

SETROPTS SAUDIT

Note that, if you have SAUDIT or OPERAUDIT in effect, it indicates that you want to log all accesses granted to these user IDs because of their special powers.

Other superfluous logging for these user IDs will not occur. For example, when these user IDs are in the access lists of profiles and they gain access because of that fact, that access will not be logged.

Mitigating the Risk of Special Privileges

To mitigate the risk of these special privileges, you first need to find all users having special privileges. To do this, run the Data Security Monitor (DSMON) report "Selected User Attribute Report." ( DSMON reports are discussed in more detail in the next chapter.)

Here is a partial sample report:

[PROGRAM LISTING NOT REPRODUCIBLE IN ASCII]

Check this report to see who has special privileges, and make sure these users need to hold special privileges.

It goes without saying that there is a great risk of special privileges being misused or abused. Auditors quite often want to know how many users are holding special privileges. You should try to minimize their use. Make sure company policy states that special privileges are handed out sparingly, and only after management approval. You should also review the logs of activities conducted by means of special privileges.

Once special privileges are handed out to a user ID or a batch ID, it is difficult to take them away. The reason? Users might not request access rights through the proper approval process, since they already have the access via special privileges.

Over time, they will be getting access to a large number of resources not through explicit and documented channels, but by means of these special privileges.

Then, when you decide to reduce the use of special privileges — possibly because of an audit finding — you will need to determine all the access rights that the user needs legitimately and grant those accesses. Only then can you remove the special privilege. Also, the person holding the special privileges might not like the idea of losing them and might try to justify having them. So, it is better not to grant these powers indiscriminately in the first place.

Here are two rules of thumb regarding special privileges:

• The AUDITOR privilege should be given only to auditors and security administrators.

• The SPECIAL privilege should be given only to security administrators and one or two batch IDs.

How about the OPERATIONS privilege? Ideally, nobody should have this very powerful privilege! There are now alternatives to using it.

The risk associated with the OPERATIONS privilege is substantial, since the holder of this privilege can not only read, but also update and delete, most (but not all) of the installation's data.

The installation can control which RACF classes are affected by the OPERATIONS privilege: for installation-defined RACF classes, you can choose whether to give special powers to holders of the OPERATIONS privilege. You specify this at the class level, in the Class Descriptor Table (CDT).

To see which RACF classes are affected at your installation, refer to the RACF Class Descriptor Table report described in the next chapter.

Alternatives to the OPERATIONS Privilege

In the past, the OPERATIONS privilege was needed so the storage administrators could manage the company's disk storage. Their job functions include backing up and migrating all data on disk, moving data between disk volumes, and so on. It would be impractical to grant them all access to all profiles. So, it was easier to make available a privilege that would achieve the same thing.

However, over the years, RACF functionality has improved. Special profiles meant specifically for the storage administration function have been introduced. These are the STGADMIN profiles in the FACILITY class. They allow storage administration-related tasks without having the OPERATIONS privilege, so the need to use the OPERATIONS privilege has diminished. (For a complete discussion on STGDMIN profiles, refer to the IBM manual DFSMSdss Storage Administration Reference.)

There is also a RACF class called DASDVOL that allows volume-level storage functions. Another way is to use HSM (or any storage management software you might have at your installation) to perform storage management and other "housekeeping" functions by making it a TRUSTED started procedure.

If you have user IDs that have the OPERATIONS privilege, review the activities carried out by them to see whether they can be replaced with alternatives. Your goal, of course, should be to phase out and ultimately eliminate the use of this privilege.

It is common practice, though, to allow the use of the OPERATIONS privilege on an exceptional basis, such as during disaster recovery exercises and during system emergencies. At these times, typically systems programmers and storage administrators would need special privileges.

Summary

All RACF special privileges, if misused, allow unauthorized access to the installation's data and can create a number of audit issues. So, ensure that you hand out special privileges judiciously in the first place.

CHAPTER 3

The Data Security Monitor (DSMON)

You'll certainly want to know whether there are any security weaknesses at your installation. How to find out?

The Data Security Monitor (DSMON) is a program that comes with RACF. DSMON produces a set of reports that identify security weaknesses (or strengths) at your installation.

Auditors often ask for all or specific DSMON reports. RACF security practitioners, therefore, need to know how to run and interpret these reports. You should run DSMON reports regularly to make sure no potential security exposures are creeping in, and to familiarize yourself with their contents.

How to Produce DSMON Reports

Since DSMON reports contain sensitive information, not anyone can run the DSMON program — you need the RACF AUDITOR privilege.

DSMON produces a set of ten reports. You have the choice of running all the reports or just a subset of them.

The JCL in Figure 3.1 will produce all ten reports. To produce individual reports, the line FUNCTION ALL needs to be replaced, as discussed in the following pages. (For more information about DSMON, refer to the IBM manual z/OS Security Server RACF Auditor's Guide.)

Understanding DSMON Reports

All DSMON reports are important. However, some reports have more relevance than others. The reports that follow are arranged roughly in the order of their importance. In addition, some of the more important reports are covered in greater detail elsewhere in this book. Refer to the chapters indicated below for a more complete discussion of them.

The Selected User Attribute Report

To produce only the Selected User Attribute report, replace the last line of the JCL in Figure 3.1 with this:

FUNCTION RACUSR

The Selected User Attribute report shows user IDs that possess the SPECIAL, OPERATIONS, and AUDITOR attributes. This report tells you whether the attribute is system-wide or at the group level. User IDs having system-wide privileges are more of a security issue than those that have only group-level privileges. Additionally, the report shows user IDs that have been revoked. This can be used to remove (delete) inactive user IDs.

For a sample report and a complete discussion of special privileges, refer to chapter 2, "RACF Special Privileges." For a complete discussion of inactive user IDs, refer to chapter 29, "Security Best Practices."

The Selected Data Sets Report

The Selected Data Sets report lists several important operating system data sets that are defined at your installation. These include APF-authorized libraries, linklist libraries, the RACF databases, and system catalogs. For each of these data sets, the report indicates whether there is RACF protection and what the universal access (UACC) is.

To obtain individual reports for each category, do the following:

1. To get the report on linklist libraries, replace the last line in the JCL in Figure 3.1 with this:

FUNCTION SYSLNK

Note that some linklist libraries may be APF-authorized. For a sample report and a complete discussion of this topic, refer to chapter 12, "APF-Authorized Libraries."

2. To get the report on APF-authorized libraries, replace the last line in Figure 3.1 with this:

FUNCTION SYSAPF

A sample report and complete discussion of this topic is also in chapter 12.

3. To get the report on system catalogs, replace the last line in Figure 3.1 with this:

FUNCTION SYSCAT

For a sample report and a complete discussion of this topic, refer to the discussion of system catalogs in chapter 14, "Operating System Data Sets."

4. To get a report on RACF databases, replace the last line in Figure 3.1 with this:

FUNCTION RACDST

For a sample report and a complete discussion of this topic, refer to chapter 15, "RACF Databases."

5. To get the report on selected operating system data sets, replace the last line in Figure 3.1 with this:

FUNCTION SYSSDS

For a sample report and a complete discussion of this topic, refer to chapter 14.

(Continues...)

---

Excerpted from IBM Mainframe Security: Beyond the Basics by Dinesh D. Dattani. Copyright © 2013 Dinesh D. Dattani. Excerpted by permission of MC Press.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---

Table of Contents

Contents

Introduction,
PART ONE: SECURING BUSINESS DATA,
Chapter 1: How the Mainframe Provides Security,
Chapter 2: RACF Special Privileges,
Chapter 3: The Data Security Monitor (DSMON),
Chapter 4: Security Event Logging and Auditing,
Chapter 5: The Global Access Checking (GAC) Table,
Chapter 6: Understanding the FACILITY Class,
Chapter 7: The Benefits of the SEARCH Command,
Chapter 8: WARNING Mode and Its Implications,
Chapter 9: Understanding z/OS UNIX Security,
Chapter 10: The Benefits of RACF Commands in Batch Mode,
Chapter 11: Security Administration: Beyond the Basics,
PART TWO: SECURING THE z/OS OPERATING SYSTEM,
Chapter 12: APF-Authorized Libraries,
Chapter 13: The System Management Facility (SMF),
Chapter 14: Operating System Data Sets,
Chapter 15: RACF Databases,
Chapter 16: RACF Exits,
Chapter 17: System Exits,
Chapter 18: Started Procedures,
Chapter 19: Tape Bypass Label Processing (BLP),
Chapter 20: The SYS1.UADS Data Set,
Chapter 21: The System Display and Search Facility (SDSF),
Chapter 22: The Program Properties Table (PPT),
Chapter 23: Special-Use Programs,
PART THREE: SECURITY INFRASTRUCTURE MATTERS,
Chapter 24: Application and Batch ID Security,
Chapter 25: Security Architecture,
Chapter 26: The RACF Unload Database,
Chapter 27: Increasing Your Productivity,
Chapter 28: Security Compliance,
Chapter 29: Security Best Practices,
Chapter 30: Security Add-On Products,
Epilogue,
Index,