external security managers for ibm z/os: perspective · ibm will continue to support os/390 v.2r.10...

Gartner© 2003 Gartner, Inc. and/or its Affiliates. All Rights Reserved.Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to bereliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretationsthereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice.

DPRO-113843Ant Allan

Technology Overview13 May 2003

External Security Managers for IBM z/OS: Perspective

Summary

Three commercial external security managers provide access-control services for IBM’s z/OS operatingsystem, but their different approaches can yield different benefits and may also pose different problems.

Table of Contents

Technology Basics

Core Security Capabilities of a COTS OS

Identification and Authentication

Resource Access Control

Auditing

Security Management

Additional Security Capabilities

Technology Analysis

Business Use

Benefits and Risks

Selection Guidelines

Technology Leaders

Technology Alternatives

Insight

List Of Tables

Table 1: ESM Repository

Table 2: Datasets and Other MVS Resources

Table 3: Dataset Access Modes

Table 4: Technology Leaders: RACF Administration and Related Tools

Table 5: Technology Leaders: ACF2 Administration and Related Tools

Table 6: Technology Leaders: TSS Administration and Related Tools

List Of Figures

Figure 1: The System Authorization Facility (SAF)

Figure 2: ACF Group TreeR

Figure 3: ACF2 User Identification Strings


© 2003 Gartner, Inc. and/or its Affiliates. All Rights Reserved.DPRO-11384313 May 2003 2

Figure 4: TSS ACID Hierarchy

Figure 5: RACF Dataset Access

Figure 6: ACF2 Dataset Access

Figure 7: TSS Dataset Access

Figure 8: RACF Administrative Scope

Figure 9: TSS Administrative Scope

Figure 10: RACF Remote Sharing Facility



Technology Basics

Released in March 2001 for the new 64-bit zSeries eServers, z/OS succeeds the 31-bit OS/390 that hadbeen IBM’s premier mainframe operating system (OS) since 1996. The OS/390 itself superseded MultipleVirtual Storage (MVS). Among other changes, the most significant was the addition of the Unix SystemServices environment. IBM will continue to support OS/390 v.2r.10 for a couple of more years, but therelease is the final one for OS/390; it will not be enhanced with 64-bit virtual memory addressing andother new zSeries technology slated for z/OS.

Like MVS and OS/390 before it, z/OS does not in itself include all the security capabilities that might beexpected in a commercial off-the-shelf (COTS) OS. IBM’s approach is for a software package to provideaccess control services for the OS. This package is known generically as either an external securitymanager (ESM) or, sometimes, a resident security system (RSS).

The System Authorization Facility (SAF) provides the standard interface between z/OS and an ESM. SAFis a part of the OS. It receives an access request from a resource manager and directs control to anorganization-specified processing routine (or “exit”) or an ESM or both. (An ESM is not, in fact, required,but using an SAF exit alone would be severely limiting.)

Figure 1: The System Authorization Facility (SAF)

SAF passes control to an exit or to an ESM and returns the access decision to the resource manager.

Source: Gartner.

Two Vendors, Three Choices

IBM itself offers the Resource Access Control Facility (RACF), while Computer Associates (CA) offers two— eTrust CA-ACF2 Security for z/OS and OS/390 (ACF2) and eTrust CA-Top Secret Security (TSS) forz/OS and OS/390.

RACF originated on MVS in 1976. In 1996 it was incorporated within IBM’s Security Server for OS/390. In1999 IBM branded Security Server for OS/390 with the SecureWay name common to a number ofsecurity products from both IBM and Tivoli Systems. In 2000, SecureWay Security Server was announcedas an element of IBM’s new 64-bit z/OS operating system. While most components of the z/OS SecurityServer are included in the price of z/OS, RACF is separately priced.



ACF2 was developed by Schrager Klemens and Krueger (SKK) and originally marketed by CambridgeSystems Group. UCCEL Corporation acquired Cambridge and was in turn acquired by CA in 1987. TSSwas developed by CGA Software Products Group, which was acquired by CA in 1985.

CA’s parallel development of ACF2 and TSS has ensured that each product has benefited from CA’sexperience with the other. The two products have a broad commonality of function, although TSS lackssupport for Mandatory Access Control (MAC) (see the Resource Access Control section below) and eachpreserves its distinctive architecture and administrative interface. ACF2 and TSS can establish securitycontrols — for other resources not natively controlled through the SAF interface, for numerous nativeintercepts and for DB2 — via the Computer Associates Event Notification Facility (CAIENF), a componentof CA Common Services for z/OS and OS/390 (formerly known as Unicenter TNG Framework for OS/390and, previously, as CA90s Services).

Table 1: ESM Repository

RACF ACF2 TSS

The RACF database is a single logical file.

It can be split over separate datasets and volumes

based on record keys.

In addition to the primary database, an active

backup is maintained for failover protection.

ACF2 uses three logical

files:

• Logonid database —

holds user identification,

logon and password data.

• Rule database — holds

all access rules controlling

dataset access.

• Infostorage database —

holds global system

options (GSO) records,

other record types with

various functions and

resource rules controlling

access to “general”

resources (for example,

Customer Information

Control System [CICS]

transactions and Time-

Sharing Option [TSO]

procedures).

Each file is defined as

Virtual Sequential Access

Method (VSAM) key-

sequenced datasets that

can reside on multiple

volumes.

TSS’s main repository is

the Security File, an

encrypted database

consisting of the security

records that hold all user

and resource permissions

and restrictions.

Core Security Capabilities of a COTS OS

Any COTS OS should provide a range of capabilities that meet the basic security needs of its users —whether they are commercial organizations or “mainstream” government agencies. Such capabilities havebeen documented in the various computer security evaluation criteria and most recently in theInternational Organization for Standardization (ISO) 15408, or Common Criteria (CC), Controlled Access



Protection Profile (CAPP). This is roughly equivalent to the Trusted Computer System Evaluation Criteria(TCSEC) C2 level.

Core COTS OS security capabilities fall into four areas:

• Identification and authentication

• Resource access control

• Security audit

• Security management

Identification and Authentication

User identification and authentication are crucial to resource access control and auditing services;everything hinges on the true identity of the user. If users are not uniquely and unambiguously identified,and if those identities are not properly verified, an organization has no assurance that access to resourcesis properly controlled. Similarly, without properly authenticated identities, audit trails will be unreliable andprovide no accountability.

User Definition

Each user is assigned an alphanumeric user name with a maximum length of eight characters. (Becauseof limitations in the MVS Job Entry Subsystem [JES], however, user identifiers of users submitting batchjobs can be only seven characters long.) Each ESM calls this user name something different:

• RACF: user identifier, user ID or userid

• ACF2: logon identifier, logonid or LID

• TSS: accessor identifier or ACID — a normal user has a User ACID; a user with administrativecapability has a Control ACID

An ESM uses a record to define each user identity. The structure and format of the user record varies witheach ESM. In addition to the user name, the user record carries user-specific information, such as theuser’s common name and system-level privileges.

An ESM uses a user record or other records in its repository to associate a user with user/principalidentities for:

• Lotus Notes

• Novell Directory Services (NDS)

• Distributed Computing Environment (DCE)

• Unix Systems Services (USS)

• SecureWay Security Server Network Authentication and Privacy Service (Kerberos)

• Digital certificates

User Authentication

Each ESM supports at least two native (host-based) authentication methods:



• Reusable passwords — Alphanumeric strings with a maximum length of eight characters. Anorganization can define requirements for password length, format, expiry (lifetime) and the maximumnumber of consecutive password errors at logon. The ESM uses one-way Data Encryption Standard(DES) encryption to create an encrypted string from the user’s user name and password, which arestored in the user record.

• Operator identification card (OIDCARD) — A magnetic-strip “swipe” card, used in place of or inaddition to the password during terminal processing. By requiring that a person not only know apassword but also possess an OIDCARD, an organization has increased assurance that the properuser has entered the user ID (“two factor” user authentication).

Each ESM can also support client/server authentication methods, such as:

• Digital certificate (public-key certificate) — In a client/server environment, ACF2, TSS and RACFcan identify a user ID by extracting user information from a digital certificate, issued by a trustedcertificate authority, that uniquely identifies the client.

• PassTicket — Workstations and client machines in a client/server environment can use a PassTicketin place of a password. A PassTicket can be generated by the ESM or another authorized functionand can be used only once on a given computer system within 10 minutes of generation.

• Kerberos — The z/OS Security Server Network Authentication and Privacy Service providesKerberos version 5 security services. The z/OS Kerberos registry is the ESM repository. EachKerberos local principal is defined as a user within the ESM, with the user record holding the localprincipal name and maximum ticket life. The user’s key is generated from the user’s password. Auser can authenticate to the ESM with a Kerberos ticket generated by a Key Distribution Center(KDC) on another platform; for example, Microsoft Windows 2000 or Sun Solaris.

The two CA ESMs also support what CA calls Extended User Authentication (EUA). EUA integratesalternative mechanisms — such as organization-specific routines, physical tokens or biometric devices —with standard logon controls to provide strong user authentication. In RACF, an organization can — andsome do — use password “exits” to implement customized strong authentication methods.

Grouping Users

An ESM can group users to support administrative, access or system requirements, but each takes adistinct approach.

In RACF, a group is defined by a group profile in the RACF database. Each group has a group name thatis unique and distinct from any user ID. Each group can contain zero, one or many users. Each user canbe a member of one or many groups, including its default group, and one or all group memberships canbe active concurrently. A group can have zero, one or many subgroups, so a group tree can be defined.(Administrative authority propagates through the group tree where each subgroup’s owner is its superiorgroup.)

While RACF defines only one kind of group, an organization can use groups in many different ways. Forexample, a group can be defined for each organizational unit (OU) to contain users within that OU, or agroup can be used to permit access to all resources necessary for a given business role and contain allusers with that role.

Figure 2: ACF Group Tree R



Each group has one superior group. Each user will be a member of at least one group, its default group orDFLTGRP. A user may also be connected to zero or many other groups. For example, group G1311 contains fourusers but is the default group of only one, U1311A.

Source: Gartner.

ACF2, however, does not define a group of users as a single “object,” although a user’s (default) groupcan be specified in the logonid record, and the user can (if authorized) specify a different group at logon.ACF2 uses a user identification string (UID) to identify an individual user or a group of users in accessand resource rules. A user’s UID is a concatenation of fields in the logonid record, such as group,organization-defined fields and (usually) the logonid itself. The UID is built dynamically at logon. Eachorganization can define its own UID structure, up to a maximum length of 24 characters. UID masks inaccess and resource rules can be used to authorize “groups” of users whose UIDs have a common prefixor pattern. The installation can also define one of the UID string fields as a multivalue field, which means itcan hold multiple values, effectively letting a user fit several job “roles” at the same time.

Figure 3: ACF2 User Identification Strings

Here the UID is built from three organization-defined fields — country, division and department — and two standardfields — GROUP and LOGONID. The UID masks in access rules can be used to group users differently. Note thatthe UID is built dynamically, so the value of the GROUP used is not necessarily the default value from the logonidrecord. If authorized, SAM could specify a different group at logon and end up with a UID of, say,USSMSAL00000017SAM.



Source: Gartner.

TSS is more like RACF: a Profile ACID defines a functional group of one or many User and Control ACIDsfor resource authorization. (Or, more formally, the Profile ACID defines a set of resource authorizationsthat can be shared by those users.) A User or Control ACID can be associated with zero, one or manyProfile ACIDs.

Like RACF, TSS can allow a hierarchy of OUs — that is, organizational groupings of User ACIDs andControl ACIDs. Unlike RACF, these are different kinds of “group” objects:

• Zone ACID

• Division ACID

• Department ACID

Only Department ACIDs are required; each User, Control or Group ACID is associated with a DepartmentACID. Organizational ACIDs are not used for resource authorization.

Figure 4: TSS ACID Hierarchy



User (and Control) ACIDs and Profile ACIDs belong to one Department ACID. Each Department ACID optionallybelongs to one Division ACID, and each Division ACID optionally belongs to one Zone ACID. User (and Control)ACIDs can be associated with zero, one or many Profile ACIDs.

Source: Gartner.

Resource Access Control

Users’ access to data and services must be controlled to ensure the confidentiality and integrity ofcorporate information and the platform itself. CC CAPP (and earlier criteria) requires the OS to enforce adiscretionary access control (DAC) policy based on user identities and group membership and theirauthorizations to resources — that is, that can control who can do what to which resources.

Dataset and Other MVS Resource Access Control

An ESM provides a mechanism that can enforce a DAC policy for access to system objects — datasetsand other MVS resources — but, again, each takes a distinct approach.

RACF and ACF2 are most similar. In RACF, a dataset can be protected by a profile in the DATASETclass; in ACF2, it can be protected by a rule in the rule database. An RACF dataset profile or ACF2access rule can protect one or many similarly named datasets using “wildcards” in the profile name orusing a dataset name (DSN) mask in the rule.

In RACF, a profile “general resource” class can protect other MVS resources; in ACF2 they can beprotected by a resource rule in the Infostorage database. As with dataset protection, one profile or rulecan protect one or many similarly named resources.

In RACF, for some general resource classes known as “resource grouping” classes, a profile with anarbitrary name can protect objects whose names match fully specified or generic names in a “memberlist.” In ACF2, a single resource rule set with an arbitrary key can protect a group of resources whosenames match names listed in a corresponding “cross-reference resource group” (X-RGP) record. X-RGPrecords can cross-reference other X-RGP records to create larger resource groups.



Authorization in an RACF profile is defined by an access control list (ACL) of user IDs or group nameswith their permitted access modes (access levels). An ACL lists:

• Individual users by user ID

• Groups of users by group name

• Any RACF-defined user by the “*” user ID

Figure 5: RACF Dataset Access

DATASET profile DS1.** protects all datasets with names beginning “DS1” except where a dataset name is bettermatched by a more specific profile name (for example, DS1.A.** protects DS1.A). Group G31 is permitted UPDATEaccess to DS1.**, so all users connected to G31 will be allowed UPDATE access to DS1.B, DS1.C and DS1.D. Notethat access is not inherited via subgroups: users connected to G311 do not enjoy these access rights.

Source: Gartner.

In ACF2, authorization is defined by rule entries in the access or resource rule set. Each entry includes aspecification of an access environment, including a UID mask with its specified access mode(s). A UID



mask can match zero, one or many UIDs, so a UID mask can refer to no users, a single user or a “group”of users with a common UID prefix or pattern.

Figure 6: ACF2 Dataset Access

Source: Gartner.

TSS differs considerably from RACF and ACF2; it does not define records for resources, although eachresource type, or class, is defined in the resource descriptor table (RDT) (RDT records in the security file).Instead, authorization is defined by permissions within User ACID, Control ACID and Profile ACIDrecords. A resource name, a prefix or, for some resource classes, a mask containing “wildcards” isdefined in the permission. Authorization to the same resource might be defined differently for differentACIDs.

Figure 7: TSS Dataset Access



Source: Gartner.


Datasets and

Related Resources

• Direct-access storage device (DASD) and tape datasets

• DASD and tape volumes

• Temporary datasets exposed, for example, after a system failure

• Data Facility Dataset Services (Data Facility Storage Management

Subsystem/MVS [DFSMS/MVS])

• MVS/Data Facility Product (MVS/DFP)

CICS/Enterprise

Systems Architecture

(CICS/ESA)

Resources

• Destination control tables

• File control tables

• Journal control tables

• Processing program tables

• Program control tables

• Program specification blocks

• Systems programmer commands

• Temporary storage tables

• Transactions




Time-Sharing

Option/Extended

(TSO/E) Resources

• Account numbers

• Logon procedures

• Performance groups

• User authorities (for example, the ability to submit batch jobs)

MVS Subsystems • Applications

• Controlled programs (load modules)

• Devices (for example, printers)

• Job Entry Subsystem (JES) (jobs, spool writers)

• Job entry from remote nodes

• Multiple console support (MCS) consoles

• Object Linking and Embedding (OLE) for Process Control/ESA (OPC/ESA)

subsystems

• Operator commands

• System Display and Search Facility (SDSF)

Other System and

Application

Resources

• Advanced Program-to-Program Communication (APPC/MVS)

• CICSPlex System Manager (CPSM)

• Component Broker

• Information Management System/ESA (IMS/ESA)

• LAN File Service/ESA (LFS/ESA)

• Message Queue Manager/ESA (MQM/ESA)

• NetView

Authorization Definitions

MVS requires a richer set of access modes than the read/write/execute file access familiar from UnixOSs, although these modes are supported by an ESM, at least for dataset access. There are two caseswhere additional access modes are required for MVS datasets:

• MVS datasets do not live within directories, so the ability to create, rename or delete a dataset cannotbe conferred by update access to the directory.

• When a user is writing data to a Virtual Sequential Access Method (VSAM) dataset, MVS may needto perform “control-interval processing” (CIP). This may require a different access mode thanordinarily writing to the dataset.

ESMs differ in the way they implement the access modes.


Mode RACF ACF2 TSS

—x EXEC EXEC FETCH

r-x READ READ READ

-w- — — WRITE

-w- plus CIP — WRITE CONTROL

Rwx UPDATE — UPDATE

Rwx plus CIP CONTROL — —

Create* — — CREATE

Delete — — SCRATCH




Mode RACF ACF2 TSS

Create/delete/r

ename

— ALLOC —

Rwx plus CIP

plus

create/delete/r

ename

ALTER — ALL

*That is, an invocation of the Direct Access Device Storage Management (DADSM):

— Via Job Control Language (JCL) with SPACE and DISP parameters.

— Via TSO with the ALLOCATE command.

— From a program with DYALLOC macro service, which expands to Supervisor Call (SVC) 99.

In RACF, all the supported access levels are hierarchical. Each level includes all the “lower” modes. So,for example, it is not possible to allow a user to write to a dataset without also allowing the user to read it.In ACF2, apart from READ, the access modes are discrete — for example, WRITE does not automaticallyconfer read access. But access modes can be combined as required, if for example a user needs bothread and write access.

TSS supports the widest range of access modes, including both discrete and combined modes. Forexample, with TSS an administrator can authorize a user to CREATE (allocate) specified datasets but notdelete them. Furthermore, TSS lets an organization modify access mode definitions or define customaccess modes for a specified resource class or classes.

For some other MVS resources, only “READ” access is meaningful; for others, the dataset access levelscan have special meanings. ACF2 supports a different set of five access modes (“services”) for resourcerules — READ, ADD, UPDATE, DELETE and EXECUTE — but again not all services apply to allresource types.

RACF and TSS also support an access level of NONE. This allows, for example, an administrator to denyaccess to an individual user ID or User ACID where that user would otherwise be allowed access by wayof a group or Profile ACID. This kind of “negative permission” is not required in ACF2.

Classification

MAC is:

An access control service that enforces a security policy based on comparing (a) security labels (whichindicate how sensitive or critical system resources are) with (b) security clearances (which indicatesystem entities are eligible to access certain resources). (Internet Engineering Task Force [IETF] Requestfor Comments [RFC] 2828 Internet Security Glossary)

MAC is not required for CC CAPP conformance. The CC Labeled Security Protection Profile (LSPP),roughly equivalent to the TCSEC B1 level, does require it, however. RACF and ACF2 support MAC, butTSS does not.

MAC is implemented using hierarchical levels or classifications that represent data sensitivity (forexample, PUBLIC, INTERNAL, CONFIDENTIAL) and nonhierarchical categories that represent datadivisions based on organizational needs (for example, FINANCE and MARKETING).

RACF and ACF2 allow an organization to explicitly use levels or categories or both or to use securitylabels that each combine one security level and zero or more security categories.



DB2 Resource Access Control

DB2 is IBM’s relational database management system (RDBMS) for z/OS (and other platforms). DB2 hasits own internal security manager, but it may be desirable to put access to DB2 resources on z/OS underthe control of the ESM that manages access to all other MVS resources.

With IBM’s RACF/DB2 external security module (supplied with the Security Server), access to DB2resources can be controlled by RACF, eTrust CA-ACF2 Security for DB2 or eTrust CA-Top SecretSecurity for DB2. Each of the CA “for DB2” products shares the “parent” product’s repository and uses thesame administrative interfaces, auditing and reporting facilities, and so on.

One of the major differences between RACF and both of CA’s additional “DB2 ESMs” is that CA uses theCAIENF component of CA-Common Services rather than SAF to “talk to” DB2. This allows them todirectly support all of DB2’s native access modes. A limitation of this approach is that CAIENF uses non-general-use programming interfaces rather than the IBM-supplied security access point (DSNX@XAC)and parameter list (DSNDXAPL), which may cause serviceability issues.

RACF appends the DB2 access mode — or privilege name — to the DB2 resource name to give theRACF resource name, so that multiple profiles may be needed to control different DB2 access modes tothe same resource. RACF can, however, protect like-named objects with a small number of profiles.

A smaller number of profiles using either grouping profiles (which list the RACF resource names in amember list) or “RACF variables” can protect sets of dissimilarly named objects. For example, the RACFvariable &CHANGE might represent the DB2 privileges UPDATE, INSERT, DELETE and LOAD and beused as the low-level qualifier in a RACF profile name, matching any of those values in the resourcesname.

Unix Systems Services Access Control

Unix Systems Services, formerly MVS/OpenEdition, is a full Unix OS with access control based on userand group identifiers (UIDs and GIDs) and “self/group/public” permission bits.

Each ESM-defined user can be assigned a Unix user identifier (UID). The assigned UID is held in theOMVS segment of a user profile (RACF), in the OMVS PROFILE record (ACF2) or in the OMVS segmentof the ACID record (TSS).

In Unix, each user can belong to one or more groups, each of which has its own group identifier (GID). InRACF, each group can be assigned a GID (which is held in an OMVS segment). In ACF2, specialGROUP profile records contain information about Unix Systems Services groups, and in TSS, GroupACIDs (rather than Profile ACIDS) define groups of User ACIDs and Control ACIDs for use by UnixSystems Services.

A Unix user with a UID of 0 [zero] is a superuser. A superuser passes all Unix security checks and canaccess all Unix resources without restriction. In general, Unix OSs cannot natively subset superuserauthority to only specific superuser tasks. For this reason, applications are often given superuser authoritywhen they require access to only a limited number of such tasks. On z/OS (and OS/390), an ESM can beused to provide authorization for specific superuser tasks; that is, without the need to assign UID (0).

Unix protects Hierarchical File System (HFS) files and directories by means of “self/group/public”permission bits, but an ESM may optionally allow access to be controlled as for MVS resources.

From z/OS v.1r.3, Unix Systems Services allow the use of ACLs that are similar to ESM ACLs to extendpermissions assigned to users and groups:



• ACLs reside in the file system (just like permission bits).

• Administrators manage ACLs via Unix commands and programming interfaces.

• While other z/OS components provide the shell commands and programming interfaces, the ESMitself performs the ACL maintenance and access checking.

Alternatively, ACF2 Infostorage rules or TSS resource permissions can be used to protect HFS files anddirectories. As with the advanced DB2 resource access control, this mechanism uses a proprietaryinterface, CAIENF, rather than an IBM one. This approach allows an organization to use one set ofcontrols and one security policy for both MVS and Unix resources.

Auditing

An OS must record information needed to establish accountability of users initiating or participating insecurity events and actions, such as logon and logoff, resource access and administrative changes. AnOS must also ensure the security of this record and the “audit trail” and should also provide suitablereporting tools.

In z/OS, audit log records are written to the System Management Facility (SMF) journal dataset. RACFand ACF2 each use SMF logging. For TSS, however, SMF logging is optional. TSS audit log records arenormally written to the TSS Audit/Tracking File. Furthermore, TSS commands — administration events —are logged only in the TSS Recovery File.

The subject user name is always recorded in the audit log record. Where users use digital-certificateauthentication to access mainframe resources via a Web interface using a shared user name, informationfrom the X.509 certificate is written to the SMF record to preserve individual accountability. Each recordalso records information such as:

• Time and date

• Event type

• Object resource name (if appropriate)

• Object profile, rule or resource name (if appropriate)

• Outcome (success or failure)

The live SMF datasets contain nonsecurity event information so users other than security administratorsor auditors will normally have access. Archive SMF datasets can be created using standard utilities;separate “security” archive datasets can be created.

Audit trail reports can be generated using ESM utilities and additional tools. A z/OS SMF Data Unloadfacility can be used to dump SMF records to a sequential dataset that can be:

• Manipulated by sort/merge utilities

• Uploaded to a database manager (for example, DB2)

• Viewed directly or used as input for reporting utilities (for example, using SAS Institute’s SAS andMerrill Consultants’ MXG)

IBM’s DFSORT Icetool can produce reports from SMF Data Unload data. IBM provides about 15 pre-defined RACF audit reports. ACF2 administrators can use the supplied ACF2 reports and utilities or



Advantage CA-Earl to generate reports from SMF datasets. TSS provides a number of batch and real-time reporting utilities.

All SMF datasets can be protected by the ESM, just like any other dataset. Access can be permitted tosecurity users (for example, administrators or an auditor), and the audit trail data can be protected fromunauthorized modification or deletion. All access attempts (successes or failures) can be logged.

For ACF2 and TSS, the optional eTrust CA-ACF2 Security WorkStation or eTrust CA-Top Secret SecurityWorkStation provides real-time monitoring of security events. Each uses the Unicenter TNG FrameworkConsole and Event Manager to automatically notify specified users and respond to events according toorganization-defined policies.

Security Management

An OS must provide a mechanism that ensures only designated persons — “authorized administrators” —can make changes to system configurations and the security policies for authentication, access controland audit. An OS should also provide a suitable interface and suitable reporting tools.

Administrative Interface

Administrators can manage an ESM using TSO/E commands that can be executed in the foreground orbackground (batch). RACF commands, ACF2 commands and TSS commands can also be issued asoperator commands. Both vendors provide Interactive System Productivity Facility (ISPF) menu-drivenpanels to build and execute commands. CA also provides CICS and IMS administrator interfaces for bothACF2 and TSS.

All or some ESM functions may be available via another software product. RACF users and groups canbe administered via the z/OS Security Server Lightweight Directory Access Protocol (LDAP) Server. CAoffers an optional product for each ESM, CA-ACF2 Workstation and CA-Top Secret Workstation thatprovides a Microsoft Windows Graphical User Interface (GUI) for administrators. ACF2 and TSS can alsobe administered via Unicenter TNG and also through LDAP.

Independent Software Vendor Administrative Tools

Some independent software vendors (ISVs) offer administrative tools for the three ESMs. By far the mostnumerous are the tools for RACF, which offer both management and reporting functions. An organizationmay also administer RACF, ACF2 or TSS via a user-provisioning product, such as IBM Tivoli IdentityManager or CA eTrust Admin. (See Technology Leaders.)

Administrative Authority and Scope

An ESM allows the organization to set up system administrators with the ability to view, create, modifyand delete all profiles, rules or records and to change ESM configurations:

• RACF — A user with the SPECIAL attribute. (In addition, a user with access to appropriate FACILITYprofiles can view user profiles and reset passwords for all users except privileged users.)

• ACF2 — A user with the SECURITY and ACCOUNT privileges — the ACCOUNT privilege allows auser to create and delete logonids, which the SECURITY privilege does not. (ACF2 adds furtherprivileges — CONSULT and LEADER — with restricted authority over logonid records.)

• TSS — A Central Security Control ACID (SCA). An administrator’s authority can be limited withinACID, DATA, RESOURCE and other types. For example, ACID CREATE confers the ability to createACIDs.



An ESM allows the organization to set up system auditors with the ability to view all profiles and changeuser and system-wide audit settings:

• RACF — A user with the AUDITOR attribute

• ACF2 — A user with the AUDIT privilege

• TSS — An SCA with appropriate AUDIT authorities

An ESM also allows the organization to set up “local” security administrators and auditors:

• RACF — The SPECIAL and AUDITOR attributes can be assigned to a user at a group level. Thescope of the user’s authority is limited to all profiles owned by that group, by the groups it owns andso on.

• ACF2 — A SCPLIST record can restrict the scope of a user’s authority to a limited set of logonids,UIDs, dataset access rules and Infostorage records. In addition, any user can be granted full orrestricted change authority to individual rule sets with the %CHANGE and %RCHANGE controlstatements.

• TSS — There are two broad kinds of “local” administrators:

• With scope based on OUs as defined by Zone, Division or Department ACIDS — either a ZonalControl ACID (ZCA), Divisional Control ACID (VCA) or Department Control ACID (DCA)

• With arbitrary scope limited by a SCOPE authority — a Limited Security Control ACID (LSCA)

Figure 8: RACF Administrative Scope

User U000A is connected to group G1 with the SPECIAL attribute. This confers administrative scope over thatbranch of the group tree unless the owner of each subgroup (or user) is the superior group (or default group). GroupG12 and the users who are only connected to groups G1311 and G1312 are outside this scope.



Source: Gartner.

Figure 9: TSS Administrative Scope

User ZCA1 is set up as a Zonal Control ACID for Zone ACID ZONE1. This confers administrative scope over allsubsidiary Division ACIDs, Department ACIDs and their associated User ACIDs and Profile ACIDs. It does not givescope over other User ACIDs associated with the Profile ACIDs, however.



Source: Gartner.

Multiple-Image Environments

An organization may have multiple z/OS images over one or many zSeries eServers. (Multiple images onone server are called a logical partition [LPAR].) Images can be simply networked together or moreformally coupled to for a “sysplex” (systems complex).

An ESM might be shared by multiple images in a sysplex or not. In a sysplex, RACF data can be cachedin a data sharing address space (RACFDS) using the coupling facility, reducing I/O against the databaseitself.

Alternatively, the ESM can provide some level of synchronization between instances across multipleimages to reduce administration workload. (Cross-ESM synchronization is not supported, except by theuse of a higher-level user-provisioning product.)

RACF’s RACF Remote Sharing Facility (RRSF) allows an organization to administer multiple z/OSimages with multiple RACF databases as a single entity:

• Command direction — RACF commands can be directed to a particular remote node in a network ofRRSF nodes, allowing selective remote administration.

• Password synchronization — A user with user IDs on multiple systems within an RRSF network canlink several user IDs on all (or some) of the other systems such that a password change on any ofthese is automatically synchronized on the others. The user IDs do not have to be the same on all ofthe systems. (In fact, a user with multiple user IDs on a single RACF system can link these forpassword synchronization.) An administrator can set up password synchronization for multiple users(automatic password synchronization).

• Automatic command direction — System administrators can set up a policy, expressed inRRSFDATA-class general-resource profiles, that specifies what commands for which classes will bedirected to which nodes in the RRSF network.



• Automatic direction of application updates — RACF supports updates to RACF information viacertain programmatic interfaces. RRSF “sees” such updates and automatically passes theappropriate update to other systems in the RRSF network keeping the same information.

Figure 10: RACF Remote Sharing Facility

RRSF is enabled between four nodes (one of which is a multisystem node; that is, with two images sharing a RACFdatabase). If “Lincoln” is the local node, “York” and “Durham” are remote nodes — but there is no direct connectionwith “Bath” and “Wells,” so, for example, user password changes can be synchronized to “York” and “Durham” only.

Source: Gartner.

The CA ESMs offer similar features via:



• CA’s Command Propagation Facility (CPF), which propagates database modifications as well as userpasswords and status changes in both sysplex and nonsysplex environments

• IBM’s Cross-Systems Communications Facility (XCF), which automatically notifies and processessecurity updates to other processors in a sysplex environment

Both ACF2 and TSS provide the capability to use the sysplex XES data-sharing facility. An ACF2 systemcan use it to share the ACF2 databases with other ACF2 systems within the sysplex environment, just asa TSS system can use it to share the TSS security file with other TSS systems within the sysplexenvironment.

Additional Security Capabilities

A secure system, however, does not rely on the security of the OS alone. There are a number of areaswhere additional security capabilities may be desirable.

Digital Certificate Support

Each ESM can be used to create, register, store and administer digital certificates and their associatedprivate keys and to build certificate requests that can be sent to a certification authority for signing. EachESM can also be used to manage key rings of stored digital certificates. Each ESM can manage threetypes of digital certificates:

• User certificate — a certificate that is associated with a user name and is used to authenticate theuser’s identity

• Certification-authority certificate — a certificate that is associated with a certification authority and isused to verify signatures in other certificates

• Site certificate — a certificate that is associated with a server or network entity other than a user orcertification authority

Each ESM can be used to administer certificates in two ways:

• To register and store an individual certificate, associating it with a specific user ID. Certificates canalso be connected to key rings.

• To map several certificates, without storing them, to one or more user names that can be shared byseveral users. This method is called “certificate name filtering.”

RACF uses general resource profiles to store certificates, key rings, certificate name filters and specialFACILITY profiles to provide authorization and audit capabilities for digital certificate managementfunctions. ACF2 uses Infostorage records to store certificates, key rings and certificate name filters andprovides authorization and audit capabilities for digital certificate management functions. TSS storescertificates, key rings and certificate name filters in the user record and Static Data Table (SDT) andprovides authorization and audit capabilities for digital certificate management functions.

Technology Analysis

Business Use

An ESM is an all but essential component of an organization’s z/OS environment. Without an ESM, anorganization would struggle to provide the necessary access control services for its mainframes.

An ESM provides a repository of user identity information. Before the rise of LDAP-based corporatedirectories, many an organization cast its ESM repository in that role. Today, an organization



implementing a modern identity and access management (IAM) product — for example, Netegrity’sSiteMinder extranet access management (EAM) product — can treat its ESM repository as anauthoritative source of user identity information. One user-provisioning product — Allen System Group’sASG-Entact ID — can use an RACF database as its central user identity and access repository (ratherthan the more commonly used LDAP directory or Open Database Connectivity [ODBC] database).

An ESM provides all the necessary CC CAPP-compliant features and functions to manage access to acommercial organization’s mainframe applications and data in accordance with its information securitypolicy. Two ESMs — RACF and ACF2 — can also provide CC LSPP-compliant features and functionsnecessary for “high security” organizations.

An organization can control access to all mainframe resources for all kinds of users, both internal andexternal. An ESM also can implement features that allow external users to be handled more easily andwith “backward compatibility” for internal users.

For example, an ESM can allow any of a grouping of external users that authenticates using a digitalcertificate to use a single common-user definition giving access appropriate to that grouping. This easesadministration, as only one user definition is required for each grouping, while user accountability ispreserved through use of the name from the particular user’s certificate.

In RACF, a profile for an external user can be set up with the RESTRICTED attribute so that the user isallowed only access that is explicitly permitted (directly or via a group). This allows the organization tomaintain any default — universal and public — access that it has set up historically without creating asecurity exposure rather than having to explicitly permit all access for internal users. ACF2 and TSS bothhave a “protection by default” philosophy, so an equivalent of RESTRICTED is not needed by eitherproduct.

Benefits and Risks

Benefits

An ESM Provides Access Control Services for z/OS

This is the major significant benefit of an ESM. It provides a very rich range of access-control services,managing user identities and managing and enforcing users’ access rights across multiple applications onz/OS (and OS/390) images.

Risks

ESM Complexity Requires Skilled Administrators

While there are differences in the ease of administration between the three commercially available ESMs,all of them are extremely complex products. Correctly setting up users and access rules requires thoroughunderstanding of the sometimes rather opaque technicalities of the ESM.

ESM Complexity May Lead to Errors

This is more than just a corollary of the previous point. An ESM’s complexity means that evenexperienced administrators can make errors. Errors can give rise to:

• Operational problems (for example, inconsistent definitions that put the Virtual TelecommunicationsAccess Method [VTAM]-started task out of action at initial program load [IPL])

• Security vulnerabilities (for example, a sensitive dataset might be covered by a rule allowing wideaccess to other similarly named but less-sensitive datasets)



An organization at least needs to put contingency plans in place to deal with possible problems. It canalso benefit by appropriate use of third-party tools that can identify problematic situations.

Selection Guidelines

Many organizations are migrating from older mainframes to IBM zSeries eServers and from OS/390 toz/OS. Very few, however, are coming new to the platform and facing a free choice of ESM. Mostorganizations will simply continue with what they already have. The most likely situations prompting a newbuying decision are:

• The organization has two different ESMs on different servers (or different images), typically due to amerger or an acquisition, and is looking to move to a single ESM.

• The organization has a single ESM on all servers and images but is contemplating a change of ESMfor software licensing or support reasons.

All three commercially available ESMs offer broadly the same features and functions, so selection boilsdown to the focused but telling differences. Both ACF2 and TSS provide security for partitioned dataset(PDS) members, better integrated USS resource security and Record Level Protection controls for CICS.An organization must consider not only which is the ESM that best meets its needs, but also if the benefitsof moving to a new/single ESM justify the costs and risk of migration.

Does It Provide All Necessary Features and Functions?

All ESMs are broadly CC CAPP-compliant (although none has been evaluated). Only RACF and ACF2are CC LSPP-compliant (although, again, none has been evaluated), so TSS is ruled out for “highsecurity” organizations obliged to implement MAC.

It is possible that an organization migrating from one ESM to another may find that the lack of certainfunctions or features in the new ESM product might create operational problems or even securityexposures.

Does It Provide All Desirable Features and Functions?

All ESMs are broadly similar, but there are subtle differences that may make one or another the moresuitable choice.

ACF2 and TSS can handle DB2 and Unix System Services differently from RACF. If an organizationmakes extensive use of either DB2 or USS, it may find that ACF2’s or TSS’s CAIENF interface offersoperational benefits. It must bear in mind, however, that CAIENF is a CA-proprietary interface, withpossible serviceability issues, and that (for DB2) it must license a supplemental product.

RACF and ACF2 have a “resource focused” approach to access control, whereas TSS has a “userfocused” approach. TSS’s approach is unusual across access control services on all platforms, but whichapproach is better is moot.

Is It Easy to Administer?

The ESMs differ in their ease of administration. There is a vigorous market for RACF administration tools,which indicates that RACF is lacking in this respect. An organization contemplating a move from ACF2 orTSS to RACF should consider if such an administrative tool is desirable and bear in mind the additionallicensing cost. CA offers Windows GUI tools for ACF2 and TSS; many third-party vendors offer WindowsGUI tools for RACF.



The ESMs also differ in their support for delegated (or distributed or local) administration. TSS, with itshierarchical OU ACIDs and fine-grained control of administrator authority scores highly here. RACF israther poor; however, in particular, there is no standard way of restricting administrator authority. Forexample, an administrator cannot set up a local administrator with just the authority to reset users’passwords. Some of the third-party RACF administration tools can provide fine-grained control. BothACF2 and TSS provide native fine-grained control of delegated administrative authority, although themodels differ considerably.

Can the Organization Provide Skilled Staff?

An organization moving to a different ESM will need to look at the ease with which it can provide skilledstaff. It needs to consider the costs of hiring new staff or the costs of retraining established staff.

Acquiring a third-party administrative tool (if moving to RACF), a CA Windows GUI (for ACF2 or TSS) or auser-provisioning product can reduce the number or technical level of staff that the organization willrequire. (But an organization will likely not be able to justify the acquisition of a user-provisioning producton this basis alone.)

What Is the Cost of Migrating to the New ESM?

An organization must consider the cost of migrating from one ESM to another. That is, it must considerthe cost of creating user and access definitions in the new ESM that reflect the established user andaccess definitions. The new definitions do not have to be an exact match, but the match must be veryclose. As the ESMs’ architectures differ, especially if one of them is TSS, achieving this can pose a hugeanalytical task. An organization may choose to resource this internally, if staff with the necessary skills isavailable, but it is more likely to engage professional services staff from one of the ESM vendors or athird-party consultancy.

What Are the Risks in Migrating to the New ESM?

An organization must consider the risks in migrating from one ESM to another. If the analysis or creationof the new user and access definitions is flawed, either or both of two problems can arise:

• Users may be permitted unnecessary access or higher-than-necessary levels of access.

• Users may be denied necessary (levels of) access.

The latter problem has the most obvious and immediate impact and may damage the organizationthrough lost productivity.

The former, however, might pose the bigger risk, as it may not come to light until long after the migration— after damage has been done. It can be especially dangerous if it allows illicit write access to AuthorizedProgram Facility (APF)-authorized datasets allowing users to create programs that bypass the ESM.

Technology Leaders

The leading ESM vendors and products are covered extensively in the body of this report. The followingtables set out the leading ancillary products that simplify the administration or enhance the functionality ofa particular ESM.

Note that an ESM can also be administered through a multiplatform user-provisioning product, such as:

• BMC Software Control-SA

• CA eTrust Admin



• IBM Tivoli Identity Manager/Access360 enRole

• Systor SAM Jupiter

• Waveset Lighthouse


Beta Systems

Software

• Beta 88 zSecurity

Administrator

(formerly Beta 88

RACF Manager)

• Beta 88 zSecurity

Helpdesk (formerly

Beta 88 Distributed

Administration

Facility)

(Internet:

www.betasystems.co

m)

Beta 88 zSecurity Administrator is based on a relational database that is

synchronized with RACF. The product features flexible reporting and management

functions based on a proprietary scripting language, Beta 88 Reporting Language.

Beta 88 zSecurity Helpdesk provides a Windows GUI and CICS, IMS and VTAM

interfaces for RACF administration. It is fully integrated with Beta 88 zSecurity

Administrator.

Beta Systems also offers:

• Beta 88 zSecurity Auditor, which provides a Windows GUI and CICS, IMS and

VTAM interfaces for:

— “Historical” SMF reporting online or in batch

— “Historical” and current z/OS and RACF status auditing

Beta 89 zSecurity Monitor, which provides real-time alerting of RACF events from

SMF, records (a kind of host-based intrusion detection [IDS] for the mainframe).




CONSUL Risk

Management

• Consul/zAdmin

RACF (formerly

Consul/RACF)

• Consul/zVisual

(formerly

Consul/RACF

Administrator for

Windows)

• Consul/zLock

(formerly

Consul/Command

Verification Option)

• Consul/zToolkit

(formerly Consul

CICS/RACF toolkit)

(Internet:

www.consul.com)

Consul/zAdmin RACF is a powerful product, particularly suited to expert RACF

users (“system administrators”), but CONSUL has specific user interfaces aimed at

less technical users as well.

Consul/zAdmin RACF works with the live RACF database and “historical” database

unloads and features:

• Flexible reporting and management functions, based on a proprietary scripting

language, Consul Auditing and Reporting Language (CARLa)

• An APF-authorized program, CNGRACF, which can be executed from

Consul/zAdmin RACF, ISPF panels, CLISTs and Rexx programs, and provides

RACF functions for administrators who do not have the system or group SPECIAL

attribute

• RACF status reports that allow a level of auditing of the RACF database

• Tools for RACF database cleanup and reorganization; for example, algorithm-

assisted merging of RACF databases

Consul/zVisual RACF provides a Windows GUI for RACF administration on the live

RACF database. It is fully integrated with Consul/zAdmin RACF and executes

RACF and CNGRACF commands via a USS daemon.

Consul/zLock ensures that RACF commands comply with installation security

policies and other corporate standards (for example, naming conventions). It can be

used to limit what system-SPECIAL users are allowed to change.

Consul/zToolkit provides a CICS interface for RACF administration and allows

RACF commands to be issued from a CICS application. It is a distinct product from

Consul/zAdmin RACF and uses CICS specific profiles to control the administrator

authorities.

CONSUL also offers two more products for RACF:

• Consul/zAudit RACF provides:

— “Historical” online or batch reporting for a very wide range of SMF record types,

not just type 30 and 80. It also supports reporting from the active (VSAM) SMF

datasets.

—Extensive z/OS and RACF status auditing.

—Status and event auditing of Unix (USS) on z/OS.

—Detection and management of changes on RACF and z/OS

• Consul/zAlert provides rule-based IDS for z/OS and RACF. It reacts on single

events that require immediate attention and events that exceed an installation-

defined threshold. Signaling takes place via e-mail, write-to-operator (WTO) or

Simple Network Management Protocol (SNMP).

• Consul/zHelp, a Web browser-based self-service password reset tool.




Vanguard Integrity

Professionals

• Vanguard

Administrator

• RioVision

• Vanguard

ezADMIN

(Internet:

www.go2vanguard.c

om)

Vanguard Administrator is a very straightforward product with a clean user interface

that is well liked by less technical RACF users (“administrators”).

RioVision provides a Windows GUI for RACF administration. It is a distinct product

from Vanguard Administrator, which Vanguard acquired from another company.

Vanguard ezADMIN is an application programming interface (API) for C++, COM,

Java and Assembler that allows RACF administration from custom applications on a

wide variety of platforms on the organization’s network or over the Internet.

Vanguard also offers other software solutions, including some for multiplatform

environments. The following fit z/OS environments with RACF:

• Vanguard Advisor (formerly called Reporter), which provides real-time event

analysis, detection and notification as well as “historical” SMF reporting

• Vanguard Analyzer, which provides z/OS and RACF security assessment, risk

identification and threat analysis

• Vanguard INCompliance, which provides RACF security policy compliance

analysis from a Web-browser GUI

• Vanguard Enforcer, which provides z/OS intrusion detection; it can detect policy

variances/violations in real time, log them, issue e-mail notices to designated

personnel and, where appropriate, take corrective action

• Vanguard ezRESET for RACF, a Web browser-based self-service password reset

tool (a Microsoft Windows version is also available)


Computer

Associates

• eTrust CA-ACF2

Security

WorkStation

(Internet:

www.ca.com)

eTrust CA-ACF2 Security WorkStation provides a Windows GUI for ACF2

administration.

It combines centralized monitoring and reporting of security events in a

multiplatform environment through Unicenter TNG.

CONSUL Risk

Management

• Consul/zAudit

ACF2 (formerly

Consul/Audit for

ACF2)

(Internet:

www.consul.com)

Consul/zAudit ACF2 is the ACF2 equivalent of Consul/zAudit RACF. It provides no

ACF2 management functions, but its ACF2 reporting functions can be useful to

ACF2 administrators.




Eberhard Klemens

(EKC)

• EKC Tools for

ACF2 (ETF/A)

(Internet:

www.ekcinc.com)

ETF/A provides a range of enhancements to ACF2:

• ETF/A File Maintenance Facility allows for global rule alteration and modeling.

• Quick Recover allows real-time recovery of logonids, dataset rules and resource

rules.

• Rule Aging Facility identifies rule lines unused over time, which can then be

removed by a security administrator through ETF/A.

• ETF/A Rule Test Facility allows you to test new rules alongside of production rules

without impacting your environment.

• ETF/A Firecall Facility allows controlled usage of special privileges for emergency

situations.

• ETF/A Multiple UID Facility allows users to have additional UID strings associated

with their logonid.

• ETF/A Dormant Rules Report identifies dataset and resource rules that cannot be

used for validation.

(Eberhard Klemens is one of the original developers of ACF2.)

Table 6: Technology Leaders: TSS Administration and Related Tools

Computer

Associates

• eTrust CA-Top

Secret Security

WorkStation

(Internet:

www.ca.com)

eTrust CA-Top Secret Security WorkStation provides a Windows GUI for TSS

administration.

It combines centralized monitoring and reporting of security events in a

multiplatform environment through Unicenter TNG.

Technology Alternatives

Any organization using z/OS (or OS/390) is unlikely to use anything other than one (or more) of the threecommercially available ESMs.

IBM’s architecture for z/OS allows access requests from resource managers to be handled byorganization-specified processing routines (or “exits”) as well as an ESM. In principle, an organizationcould use exits alone. But providing the same rich functionality as a commercially available ESM this waywould be horrendously complex.

More speculatively, an organization might build exits that can use the Security Assertions MarkupLanguage (SAML), an Extensible Markup Language (XML)-based security standard for exchangingauthentication and authorization information. This approach would allow an organization to manageaccess control to at least some kinds of z/OS resources through an SAML-compliant extranet accessmanagement (EAM) product. Where an organization needs to provide external users with access to z/OS-hosted applications, it could then use only the same identity and access management infrastructure as forits Web applications rather than having to set up consistent access rules in both the EAM product and thez/OS ESM.

Insight

An ESM is a necessity for any organization using z/OS on an IBM zSeries eServer (or OS/390 on anearlier mainframe). All three commercially available ESMs are robust and proven products that providethe core security capabilities for a COTS operating system that z/OS (and OS/390) requires. While many



organizations are happy with RACF’s administration tools and batch utilities, others, particularly largerorganizations, employ third-party tools to provide more streamlined, task-oriented administration andmore sophisticated reporting options. CA’s products offer, for example, finer authorization granularity, anddelegated administration is well supported. The most significant difference between the CA products is intheir architecture. While there are some telling functional differences between the RACF, ACF2 and TSS,organizations contemplating consolidation on a single ESM or a change of ESM may give as much weightto the products’ “look and feel.” Ultimately, the decision will likely come down to the balance between thecost and risks of migration and the potential licensing savings.

external security managers for ibm z/os: perspective · ibm will continue to support os/390 v.2r.10...

Documents