A z/OS Security Rosetta Stone
Understanding z/OS security managers
7/15/2015 12:30:40 AM |
By Reg Harbeck
Not all monoliths are mainframes. But they often have a lot in common beyond their size, solidity and endurance, such as information.
My favorite example of such a monolith is the Rosetta Stone. Located in the British Museum in London
, it contains the same information in three ancient forms: hieroglyphs, demotic script and Greek writing. This has allowed people who understood one of these to gain important insights into the other two.
Somewhat similarly, the mainframe running z/OS has three different external security managers (ESM) that do nearly the same thing: IBM RACF, CA ACF2 and CA Top Secret. While there’s room for debate about the advantages of each (which I will not pursue in this article), they are sufficiently alike in purpose and function that knowledge of any one of them can be used to better understand the other two.
This knowledge is useful for a wide range of reasons, including:
- Sharing of mainframe security insights and best practices between people who work with different ESMs
- Dealing with mergers or acquisitions that result in environments with more than one ESM
- Moving between employers with different ESMs
- Changing or merging ESMs
Let me be clear: I do not recommend the last of these behaviors. While they all do similar work, each one is sufficiently unique, particularly in how it is configured and used in each unique environment, that it can be extremely challenging and time-consuming to move off of one and onto another. However, I recognize that it does sometimes happen, and the better prepared you are, the more pain you can avoid.
Background and Behaviors
For the first 12 years of its existence, the IBM mainframe was secured by a hodgepodge of loosely connected methods, from passwords for individual data sets (stored in the “PASSWORD” data set) to hard-coded user IDs and passwords for each individual system (such as SYS1.UADS for time sharing option and DFHSNT for CICS) to permissions stored in tables or coded in applications, or just implicit in how they worked.
This started to become a problem, especially for organizations whose mainframe users didn’t always behave in a professional manner (e.g., university students). The SHARE Security Project was founded in the early 1970s with the goal of establishing, maintaining and furthering standards for computing security. The requirements document that resulted became the genesis of modern mainframe security.
IBM, having already created the default security environment, was first to respond with the RACF product, which retained a certain amount of backward compatibility with previous configurations, and took a while to fill all the SHARE requirements—which it eventually did.
ACF2 was developed by some of the people involved with the development of the SHARE requirements document, including Barry Schrager, as well as his colleagues Eb Klemens and Scott Krueger who, together, founded SKK (their initials) and made their product available by the end of the 1970s.
Top Secret was created by the CGA Software Products Group in the early 1980’s, responding to the same requirements but with an entirely different paradigm.
And here’s where our description begins, because by the time Top Secret existed, all three products met or exceeded the same requirements, and their varying paradigms have remained roughly the same over the years.
All three products have the following basic things in common:
- They store their security information in mainframe-based databases, also known as directories, which are now externally accessible using X.500 and lightweight directory access protocol.
- They function with IBM’s z/OS Security Authorization Facility, which passes all security requests to whichever ESM is running.
- They store and use IDs or USERIDs—though they’re given different names—with which people sign on to mainframe systems, using methods such as passwords or more advanced alternatives for authentication purposes.
- These IDs, once logged on, can be given security access to systems and resources based on information stored in the directories/databases.
To understand the unique nature of each of these ESMs, the two most important ways they differ are:
By Any Other Name…
- What they call things such as IDs, permissions and groupings.
- The organization of how IDs and access permissions are stored.
Under RACF, IDs are called “User IDs.” In ACF2 they are referred to as “LIDs,” short for “Logon IDs.” And in TSS they’re called “ACIDs” for “Accessor IDs” and pronounced “ae sidz.”
To clarify how other things are named, it is time to address the definitive difference between each ESM: their security paradigms.
Profiles, Compiles and Trees
In RACF, all IDs and permissions are stored as one of four kinds of profiles:
- User – one per User ID
- Groups – groupings of User IDs; every User ID must belong to at least one
- Data set – specifically for data set (file) access
- General resource – anything other than data sets
Also, data set and general resource profiles may be “discrete” (attached to one specific resource and deleted when that resource is deleted) or “generic” (referring to all resources that the profile name most exactly describes, and persistent regardless of the deletion or creation of specific resources).
Does this make RACF “user-oriented” or “resource-oriented”? Yes and no is the best answer I can give; decide for yourself.
ACF2, on the other hand, is unambiguously resource-oriented. The IDs are stored in a separate VSAM data set from the resources, and the resources are defined, along with their access, in resource “rules” which are text-based representations of a list of who has what access to which resources. These rules, after being edited, must be “compiled” to put them into an efficient form and stored in their own VSAM data sets—one for data set rules, one for everything else.
To make these rules work, every LID also has a “UID String” which is a much longer string of characters that represents the organizational role of a given LID and is used to determine access using text string processing in the rules.
In contrast, TSS is structured like one big user-oriented tree, with the master security control ACID at the top “owning” the entire tree, and every ID and resource “belonging” somewhere in the tree to a specific ACID. The bottom level of this tree hierarchy, to which all normal user ACIDs and PROFILEs (access permission groupings) belong, is made of departments. Two optional higher levels of hierarchy are divisions (which can own departments) and zones (which can own divisions).
This is just the beginning, but if it’s whetted your appetite for more, there are a number of places to continue your journey of getting to know these three ESMs. I’m giving a presentation on this topic at SHARE in Orlando on Aug. 11 at 1:45 p.m., room “Oceanic 3.”
Visit IBM’s website for more information about RACF
. For information about ACF2 and TSS, visit CA’s website
There are also many other good articles to supplement your knowledge of the history of mainframe security, including “Making the Mainframe Secure”
and the SHARE Security and Compliance Project documentation
Reg Harbeck has been working in IT and mainframes for more than 25 years, and is very involved in the mainframe culture and ecosystem, particularly with the SHARE Board and zNextGen and Security projects. He may be reached at Reg@Harbeck.ca.