eTrust™ CA-ACF2® Security for z/OS and OS/390

eTrust™ CA-ACF2 Security for z/OS and OS/390

Auditor Guide 6.5

H00037-1E

This documentation and related computer software program (hereinafter referred to as the “Documentation”) is for the end user’s informational purposes only and is subject to change or withdrawal by Computer Associates International, Inc. (“CA”) at any time.

This documentation may not be copied, transferred, reproduced, disclosed or duplicated, in whole or in part, without the prior written consent of CA. This documentation is proprietary information of CA and protected by the copyright laws of the United States and international treaties.

Notwithstanding the foregoing, licensed users may print a reasonable number of copies of this documentation for their own internal use, provided that all CA copyright notices and legends are affixed to each reproduced copy. Only authorized employees, consultants, or agents of the user who are bound by the confidentiality provisions of the license for the software are permitted to have access to such copies.

This right to print copies is limited to the period during which the license for the product remains in full force and effect. Should the license terminate for any reason, it shall be the user’s responsibility to return to CA the reproduced copies or to certify to CA that same have been destroyed.

To the extent permitted by applicable law, CA provides this documentation “as is” without warranty of any kind, including without limitation, any implied warranties of merchantability, fitness for a particular purpose or noninfringement. In no event will CA be liable to the end user or any third party for any loss or damage, direct or indirect, from the use of this documentation, including without limitation, lost profits, business interruption, goodwill, or lost data, even if CA is expressly advised of such loss or damage.

The use of any product referenced in this documentation and this documentation is governed by the end user’s applicable license agreement.

The manufacturer of this documentation is Computer Associates International, Inc.

Provided with “Restricted Rights” as set forth in 48 C.F.R. Section 12.212, 48 C.F.R. Sections 52.227-19(c)(1) and (2) or DFARS Section 252.227-7013(c)(1)(ii) or applicable successor provisions.

2004 Computer Associates International, Inc.

All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.

Contents

Chapter 1: Introduction eTrust CA-ACF2 Security Philosophy........................................................... 1-1 Components of eTrust CA-ACF2 ............................................................... 1-2

Chapter 2: Scope of eTrust CA-ACF2 System Options............................................................................... 2-1 eTrust CA-ACF2 Boundaries Set With the ACFFDR and GSO ..................................... 2-2

Displaying eTrust CA-ACF2 Control Options................................................ 2-2 Important GSO Record Control Options..................................................... 2-3

eTrust CA-ACF2 and IMS ..................................................................... 2-8 eTrust CA-ACF2 IMS TM Interface ......................................................... 2-8 eTrust CA-ACF2 IMS Batch Interface ...................................................... 2-10

eTrust CA-ACF2 and CICS ................................................................... 2-11 eTrust CA-ACF2 SAF Interface................................................................ 2-13 Use of Local Exits ............................................................................ 2-13 External Environment ........................................................................ 2-18

Chapter 3: System Access Control The Logonid Record .......................................................................... 3-1 Separation of Function ........................................................................ 3-2 Special Users ................................................................................. 3-2

SECURITY ............................................................................... 3-2 ACCOUNT............................................................................... 3-3 AUDIT................................................................................... 3-4 LEADER ................................................................................. 3-4 CONSULT ............................................................................... 3-4

Contents iii

System Options and Special Users .............................................................. 3-4 Reviewing @CFDE Settings in the ACFFDR .................................................. 3-5 Reviewing Decompile Authority in GSO RULEOPTS Record .................................. 3-6

Centralized and Decentralized Administration ................................................... 3-6 Scope Records............................................................................. 3-6 Displaying Scope Records .................................................................. 3-7 Rule Compilation and DECOMP Authorities ................................................. 3-8

Displaying and Changing Infostorage Records ..................................................3-10 Critical Logonid Record Fields.................................................................3-10 Sensitive Logonid Record Fields ...............................................................3-11

Chapter 4: Data Set Access Control The Access Rule Set ........................................................................... 4-3

Rule Entries............................................................................... 4-5 Reviewing Access Rules ....................................................................... 4-8 Production Jobs ..............................................................................4-10

Job Submission ...........................................................................4-11

Chapter 5: Resource and Program Access Control Resource Controls ............................................................................. 5-1 Program Controls ............................................................................. 5-3

Using Tape Bypass Label Processing ........................................................ 5-3 Logging Program Accesses ................................................................. 5-3

Defining Restricted Program Names..................................................... 5-4 Defining Maintenance Logonids, Programs, and Libraries ..................................... 5-4 Defining Libraries in the System Link List.................................................... 5-5

Chapter 6: Reports and Audit Trails Logging Data Set, Volume, or Resource Access................................................... 6-1 Logging User Access .......................................................................... 6-2 Combined SMF Records ....................................................................... 6-3 eTrust CA-ACF2 Reports....................................................................... 6-3

ACFRPTXR—Cross-Reference Report ....................................................... 6-4 ACFRPTIX—Data Set Index Report ......................................................... 6-4 ACFRPTDS—Data Set/Program Event Log .................................................. 6-4 ACFRPTRV—Generalized Resource Event Log............................................... 6-5 ACFRPTEL—Information Storage Update Log ............................................... 6-5

iv Auditor Guide

ACFRPTNV—The Environment Report ..................................................... 6-5 ACFRPTPW—Invalid Password/Authority Log ............................................. 6-5 ACFRPTRX—Logonid Access Report ....................................................... 6-5 ACFRPTLL—Logonid Modification Log .................................................... 6-6 ACFRPTJL—Restricted Logonid Job Log .................................................... 6-6 ACFRPTRL—Rule-ID Modification Log ..................................................... 6-6 ACFRPTSL—Selected Logonid List ......................................................... 6-6 ACFRPTCR—TSO Command Statistics Log ................................................. 6-6 ACFRPTST—SAF Trace Report............................................................. 6-6 ACFRPTOM—OpenEdition Report ......................................................... 6-7 Other Reports ............................................................................ 6-7

Using Reports for Auditing .................................................................... 6-7 Report Authorization ......................................................................... 6-8

Chapter 7: Migrating to Security Steps ........................................................................................ 7-1

Appendix A: ACF Command in Batch TSO Terminal Monitor Program (TMP) .........................................................A-1 ACFBATCH Utility ...........................................................................A-1

Appendix B: Sample SHOW Outputs Sample SHOW ACTIVE Output................................................................ B-1 Sample SHOW APPLDEF Output .............................................................. B-2 Sample SHOW CLASMAP Output ............................................................. B-3 Sample SHOW CPF Output.................................................................... B-4 Sample SHOW DB2 Output.................................................................... B-4 Sample SHOW DDSN Output ................................................................. B-5 Sample SHOW FIELDS Output ................................................................ B-6 Sample SHOW LDS Output.................................................................... B-7 Sample SHOW MODE Output ................................................................. B-8 Sample SHOW NJE Output .................................................................... B-8 Sample SHOW PROGRAMS Output............................................................ B-9 Sample SHOW RESIDENT Output ............................................................. B-9 Sample SHOW RSRCTYPE Output ............................................................ B-10 Sample SHOW RSVWORDS Output........................................................... B-10 Sample SHOW SAFDEF Output............................................................... B-11

Contents v

Sample SHOW STATE Output.................................................................B-11 Sample SHOW SYSPLEX Output ..............................................................B-12 Sample SHOW SYSTEMS Output ..............................................................B-13 Sample SHOW TNG Output ..................................................................B-13 Sample SHOW TSO Output ...................................................................B-14 Sample SHOW UNIXOPT Output .............................................................B-14 Sample SHOW ZEROFLDS Output ............................................................B-15

Appendix C: Rule Writing Examples Data Set Access Rule Writing Example ......................................................... C-1 Resource Rule Writing Example ............................................................... C-3 General Rule Writing Comments .............................................................. C-6

Appendix D: Sample eTrust CA-ACF2 Audit Survey Questions Components of eTrust CA-ACF2............................................................... D-1 Other Products............................................................................... D-2 ACFFDR and GSO Options.................................................................... D-2 Logonid Records ............................................................................. D-4 Rule Records................................................................................. D-5 eTrust CA-ACF2 Reports...................................................................... D-5

Index

vi Auditor Guide

Chapter

1 Introduction

An important managerial responsibility is the review and evaluation of an organization’s automated systems. Because sensitive organizational information is frequently stored on these systems, sound-auditing practices must be implemented to maximize security.

Several professional associations have recommended that all organizations have effective internal controls, especially those with automated systems—the Independent Commission on Auditors’ Responsibilities, the Financial Executives Institute, the Institute of Internal Auditors, and the American Institute of Certified Public Accountants (AICPA). Also, several laws have been implemented in many countries that require organizations to establish accounting and auditing procedures.

For example, in the United States, the Securities and Exchange Commission (SEC) has stated that public companies must “review their accounting procedures, systems of internal accounting controls and business practices” to comply with the requirements of the Foreign Corrupt Practices Act of 1978. This act applies not only to foreign transactions, but also to the assessment and verification of existing domestic accounting and data processing controls. If the controls are insufficient, an organization must promptly implement a plan that affords effective security with auditing capability.

eTrust CA-ACF2 Security Philosophy The authors of eTrust CA-ACF2 Security for z/OS and OS/390 (eTrust CA-ACF2) define data security as the protection of data against unauthorized disclosure, modification, or destruction. eTrust CA-ACF2 protects all data by default, and it shares data only on explicit action by the data owner or security administrator. Therefore, eTrust CA-ACF2 is not only a data protection system, but also a system that provides for the controlled sharing of data in accordance with the authorizations defined to it by the site.

Introduction 1–1

Components of eTrust CA-ACF2

Components of eTrust CA-ACF2 eTrust CA-ACF2 uses an algorithmic method to determine whether to grant access to a given data set or other defined resource to an individual user under a specific environment. The eTrust CA-ACF2 algorithms, called rule sets, are composed of access or resource rules. An authorized eTrust CA-ACF2 user (perhaps a data set owner or a security administrator) compiles rule sets. eTrust CA-ACF2 transforms the rule set into object records. These object records are stored in the eTrust CA-ACF2 Rule database or Infostorage database. When eTrust CA-ACF2 needs to consult rules to determine whether a service should be performed (for example, the opening of a data set), eTrust CA-ACF2 translates the related rule set.

eTrust CA-ACF2 places intercepts in the z/OS and OS/390 operating system components and in various subsystem components such as TSO, JES, IMS, DB2, and CICS. Using these intercepts, eTrust CA-ACF2 gains control and decides if the request should be processed in one of three ways:

■ Allow

■ Allow but log to SMF

■ Deny and log to SMF

eTrust CA-ACF2 makes this decision based on the total environment of the request and whether a rule specifies that an access under those conditions should be granted. The “total environment” might include (for a data set access) aspects such as the user making the request, the data set name, the volume it is on, where the job came from, the program making the request and the library it came from, the ddname specified in the job’s JCL, the date of the request, and additional local items if specified.

eTrust CA-ACF2 includes other special control features, such as specific controls over certain programs, over the use of various TSO commands or bypass label processing (BLP), over the use of terminals and readers, and so forth. eTrust CA-ACF2 also includes numerous report generators, TSO commands, and other aids to assist in the administration and audit of the system.

1–2 Auditor Guide

Chapter

2 Scope of eTrust CA-ACF2

One of the most important aspects of eTrust CA-ACF2 that you should address is identifying the scope of the eTrust CA-ACF2 controls at a site.

System Options eTrust CA-ACF2 can be easily tailored to different needs and surrounding environments. Many eTrust CA-ACF2 options are available and the site’s choices in the use of these options can have a dramatic effect on how much control eTrust CA-ACF2 does or does not provide at that site. The three means of defining system options to eTrust CA-ACF2 are:

■ The eTrust CA-ACF2 Field Definition Record (ACFFDR) macros. See the Getting Started guide for a complete description of the ACFFDR macros and their function.

■ eTrust CA-ACF2 records, including Global System Options (GSO) records, Cache (CAC) records, and Command Propagation Facility (CPF) records. These records are stored in the eTrust CA-ACF2 Infostorage database. See the Administrator Guide for complete information about each record and associated options.

■ The GSO CLASMAP and SAFDEF records customize System Authorization Facility (SAF) processing. Many system and application products secure functions using SAF calls. eTrust CA-ACF2 secures all SAF calls by default. The CLASMAP records map the external CLASS name used in the SAF calls to an eTrust CA-ACF2 generalized resource type. The SHOW CLASMAP command displays the mappings currently active on your system. The SAFDEF record lets you to customize processing of specific SAF requests; you can, for example, establish a SAFDEF record that causes specific SAFDEF requests. The SHOW SAFDEF command lets you display SAFDEF definitions active on your system. For additional information on eTrust CA-ACF2 SAF support, see the Administrator Guide.

Scope of eTrust CA-ACF2 2–1

eTrust CA-ACF2 Boundaries Set With the ACFFDR and GSO

■ Optionally, you can use eTrust CA-ACF2 to protect resources available through CICS (the IBM Customer Information Control System), and IMS (the IBM Information Management System). The scope of eTrust CA-ACF2 controls for these products is defined on an individual basis for each CICS and IMS address space. Control options for each of these product interfaces are described in the appropriate eTrust CA-ACF2 support guide (for example, the CICS Support Guide describes the options available for CICS).

You should review the detailed description of every possible option by referring to the appropriate guides. Review the values cited in the ACFFDR, the infostorage records, IMS, and CICS systems frequently and thoroughly. This step should also be taken very early during an eTrust CA-ACF2 audit.

Some of the more critical control options are reviewed in this chapter to help identify their importance and how they can significantly alter the level of eTrust CA-ACF2 protection at a site.

eTrust CA-ACF2 Boundaries Set With the ACFFDR and GSO Several of the values defined in the ACFFDR macros and the GSO records affect the boundaries of the eTrust CA-ACF2 controls. Check the current settings of these values at the site to determine what portions of eTrust CA-ACF2 controls are active. To check the ACFFDR values, review the input to the ACFFDR assembly processing or the output of this process as long as adequate controls are in place so that you are confident you are reviewing the appropriate (active) copy.

Displaying eTrust CA-ACF2 Control Options

You can verify most of the ACFFDR and GSO values online with the SHOW subcommand on TSO, such as SHOW ACF2, SHOW SYSTEM, and SHOW STATE. You can submit ACF commands or subcommands in batch jobs by running the TMP in batch or by running the utility ACFBATCH (see the “ACF Command in Batch” appendix for sample JCL). In addition, you can use Interactive System Productivity Facility (ISPF) panels to display the eTrust CA-ACF2 system parameters, logonid records, GSO records, access rules, resource rules, and so forth.

Samples of the outputs from the ACF SHOW subcommand are included in the “Sample SHOW Outputs” appendix. The SHOW subcommand lets any auditor or security administrator (or any eTrust CA-ACF2 user with the AUDIT or SECURITY attribute, regardless of any scope field values) display the system options currently active at that site as generated with the latest ACFFDR assembly and GSO entries.

2–2 Auditor Guide


If your site uses the command propagation facility (CPF), the SHOW subcommand lets you view the CPF nodes and options that are in effect. CPF enables a site that runs eTrust CA-ACF2 on multiple, networked CPUs to administer eTrust CA-ACF2 on all the networked nodes from a single node. CPF options are set in the CPF NODEDEF and OPTIONS records. In addition, if your site uses the Database Synchronization Component (DSC), the SHOW subcommand lets you view the DSC nodes and options that are in effect. DSC allows a site to propagate database record changes that occur on a eTrust CA-ACF2 system to a eTrust CA-ACF2 VM system, and vice versa. DSC uses CPF to propagate these changes. DSC options are also set in the CPF NODEDEF and OPTIONS records. For more information about CPF or DSC, see “Using the Command Propagation Facility” in the Administrator Guide.

Important GSO Record Control Options

Some of the GSO values displayed by SHOW subcommands that are of particular interest in determining the active eTrust CA-ACF2 boundaries are described in this section.

OPTS MODE

Displayed using the SHOW STATE subcommand as: MODE = ABORT|WARN|LOG|QUIET|RULE,norule,no$mode

This identifies the mode the main eTrust CA-ACF2 system is in. This applies to all eTrust CA-ACF2 processing, except each CA-IMS and CICS region (each have their own individual MODE values), or any portion of eTrust CA-ACF2 processing whose mode is affected by local eTrust CA-ACF2 exit coding. If this system mode is set to anything other than ABORT or RULE, minimal protection is offered by eTrust CA-ACF2 because even access attempts specifically prevented by the rules are permitted (though logged if in LOG or WARN mode). QUIET, LOG, RULE, and WARN modes are provided only to assist in the transition to full eTrust CA-ACF2 security; your site should proceed to ABORT mode as soon as possible. Also, if the mode is RULE or ABORT, you must carefully audit use of various system exits to determine if any local coding grants accesses that eTrust CA-ACF2 would consider violations. This use of exits circumvents eTrust CA-ACF2 rules and the ABORT mode. See Use of Local Exits later in this chapter.

Note: When MODE=RULE is specified, the SHOW STATE output includes three mode specifications, such as MODE=RULE,ABORT,ABORT. In this example, the second parameter of ABORT is taken when no rule record is found, and the third parameter of ABORT is taken when no $MODE control statement is included in the rule set.



OPTS NOSORT

Displayed using the SHOW STATE subcommand as: NOSORT=YES|NO

If NOSORT is in effect and a $NOSORT control statement is used in a rule, the normal eTrust CA-ACF2 sorting of rules from most specific to most general is suppressed. Therefore, all rule sets with the $NOSORT control statement should be carefully reviewed to ascertain that rule entries are in the proper sequence and that no general rule placed early in the rule set inadvertently supersedes a more specific rule appearing later in the rule set. The use of $NOSORT should be very limited and any use should be justified by the data owner or the security administer responsible for the rule set.

OPTS NOTIFY

Displayed using the SHOW SYSTEM subcommand as: NOTIFY=YES|NO

When this option is in effect, an informational message is produced for users whenever they log on or sign on to the system. The message indicates the date and time of the last system access. Users should be instructed to use the information displayed to verify that no unauthorized use of their logonid occurred since their last legitimate session.

SAFDEF

Displayed as a list using the SHOW SAFDEF or the SHOW ACF2 subcommand. Appears under the heading: SYSTEM AUTHORIZATION FACILITY DEFINITIONS

eTrust CA-ACF2 validates all SAF calls by default. It is possible to override the way eTrust CA-ACF2 processes these calls using SAFDEF records. The SHOW SAFDEF and SHOW ACF2 subcommands display the values in the SAFDEF records, allowing you to determine if any SAF processing has been changed.

OPTS STC

Displayed using the SHOW STATE subcommand as: STC OPTION=ON|OFF

2–4 Auditor Guide


This indicates if eTrust CA-ACF2 validates any access requests made by any system (started) tasks. If STC is not in effect, any system task can access any data set regardless of eTrust CA-ACF2 access rules. Current STCs on the system, as well as the procedures and controls for adding new STCs to the system, should be reviewed carefully if STC is not in effect.

OPTS UADS

Displayed using the SHOW STATE subcommand as: UADS=BYPASS|USE

This value indicates if the user attribute data set (UADS) is bypassed (the SYS1.UADS data set is bypassed) so that TSO users are defined in only one place. This can change the TSO logon procedure for existing users. If UADS is used, the majority of the fields in the TSO section (Group 5) of the eTrust CA-ACF2 logonid record are not active (that is, not used by eTrust CA-ACF2). eTrust CA-ACF2 obtains the necessary value from the UADS file rather than from eTrust CA-ACF2 logonid records. The only fields in the TSO section that are not affected by this option are ALLCMDS, CMD-LONG, VLD-ACCT, VLD-PROC, and WTP. These fields are always active. All other TSO fields in the eTrust CA-ACF2 logonid record are active only when NOUADS is in effect. If UADS is used, you should review procedures for the control and maintenance of the UADS data set.

AUTOERAS

Displayed using the SHOW STATE subcommand, under the heading: -- AUTOMATIC ERASE VOLUMES --

The record specifies the types of data sets and volumes for which physical erasure is performed during deletion. This takes place prior to the release of that space to the system for later allocation.

PPGM

Displayed as a list using the SHOW PROGRAMS or the SHOW PGMS subcommand. Appears under the heading: -- RESTRICTED PROGRAM NAMES --



This is used to identify each specific program name or program name pattern that eTrust CA-ACF2 controls based on the execution of programs by that name, regardless of the library it is from or what accesses it is attempting. Only users with the PPGM, NON-CNCL, or unscoped SECURITY attribute can execute programs matching this list. eTrust CA-ACF2 logs the occurrence of each execution. The programs that should be identified on this list are those that do not use standard system services (such as the standard OPEN SVC) and thus could bypass system security by avoiding the eTrust CA-ACF2 system intercept points. Some programs of this type are the Innovation Data Processing Fast Dump and Restore (FDR and FDRDSF) product and the IBM utilities IEHDASDR and DRWDASDR. For those programs specified in PPGM, each should also be stored in an eTrust CA-ACF2-protected library with close control over who can read (copy) programs from that library so that the program cannot be easily copied, renamed, or executed under an uncontrolled name. Also see “Resource and Program Access Control,” for further discussion of PPGM and other records (such as MAINT, BLPPGM, LINKLST, and LOGPGM) and eTrust CA-ACF2 controls that relate to monitoring program use.

RESVOLS

Displayed as a list using the SHOW STATE subcommand. Appears under the heading: -- DSNAME PROTECTED VOLUMES --

For accesses to data sets on DASD, eTrust CA-ACF2 always first checks the DASD volume name against the list specified by RESVOLS. If the volume name matches a volume name or name pattern on this list (RESVOLS could be six asterisks, in which case all DASD volumes would be considered as matching), eTrust CA-ACF2 checks the access request against the data set name access rules in the normal manner. If a match is not found on RESVOLS, SECVOLS is checked.

See the OPTS TAPEDSN description for additional information.

SECVOLS

Displayed as a list using the SHOW STATE subcommand. Appears under the heading: -- VOLSER PROTECTED VOLUMES --

2–6 Auditor Guide


eTrust CA-ACF2 checks the SECVOLS list for a matching volume name or name pattern if the volume name does not match the RESVOLS list. If there is a match on SECVOLS, eTrust CA-ACF2 checks the access request against a special access rule under the volume’s name. The access rule uses the pseudo data set name @volser.VOLUME or VOLUME.@volser, depending on which option your site selected during eTrust CA-ACF2 installation. Issue the SHOW STATE subcommand and refer to the VOLUME PSEUDO DSN= value to see your site’s pseudo data set name format.

See the OPTS TAPEDSN description for additional information.

OPTS TAPEDSN

Displayed using the SHOW STATE subcommand as: TAPE DSN=YES|NO

The RESVOLS, SECVOLS, and OPTS TAPEDSN specifications must be considered jointly, as together they determine on which media and to what extent access to data sets is controlled by eTrust CA-ACF2 access rules. The information from the RESVOLS and SECVOLS descriptions is repeated here to clarify the relationship of these records.

For accesses to data sets on DASD, eTrust CA-ACF2 always first checks the DASD volume name against the list specified by RESVOLS. If the volume name matches a volume name or name pattern on this list (RESVOLS could be six asterisks, in which case all DASD volumes would be considered as matching), eTrust CA-ACF2 checks the access request against the data set name access rules in the normal manner. If a match is found on RESVOLS, SECVOLS is not checked.

If the volume name does not match the RESVOLS list, eTrust CA-ACF2 checks the SECVOLS list for a matching volume name or name pattern. If there is a match on SECVOLS, eTrust CA-ACF2 checks the access request against a special access rule under the volume’s name. The access rule uses the pseudo data set name @volser.VOLUME or VOLUME.@volser, depending on which option your site selected during eTrust CA-ACF2 installation. Issue the SHOW STATE subcommand and refer to the VOLUME PSEUDO DSN= value to see your site’s pseudo data set name format.

If the DASD volume name does not match the RESVOLS list or the SECVOLS list, accesses to the volume are not controlled by eTrust CA-ACF2 (that is, no access rules are checked and any access attempt, including allocate or scratch, is unconditionally allowed unless otherwise checked by a local exit).


eTrust CA-ACF2 and IMS

For accesses to data sets on tape, eTrust CA-ACF2 does not check the RESVOLS list, but does check the SECVOLS list. If the tape volume name matches a name or name pattern on the SECVOLS list, the applicable volume name rule is used to validate the request. If the tape volume name does not match any SECVOLS entries, the OPTS TAPEDSN field value is checked. If this is set to NOTAPEDSN, no rule checking is done by eTrust CA-ACF2 and accesses to that tape volume are not controlled by eTrust CA-ACF2. However, use of BLP is controlled by eTrust CA-ACF2 and is active independent of the SECVOLS and OPTS TAPEDSN values. If OPTS TAPEDSN is in effect, eTrust CA-ACF2 validates access requests for data sets on tape at the data set name level, checking the normal data set access rules.

A good configuration for a site is a RESVOLS value of “******”, no SECVOLS entries, and OPTS TAPEDSN. This ensures that accesses to all present and future data sets, regardless of storage media, are validated at the data set name level by eTrust CA-ACF2. Other considerations, such as non-standard labeled tapes, the availability and use of a tape management system, and multiple data sets on a single tape volume must be taken into account when reviewing the full scope of the security afforded and the best approach for an installation.

eTrust CA-ACF2 and IMS The two eTrust CA-ACF2 IMS interfaces are the eTrust CA-ACF2 IMS TM interface and the eTrust CA-ACF2 IMS Batch Interface. Each interface is described in this section.

eTrust CA-ACF2 IMS TM Interface

eTrust CA-ACF2 support can be defined for each IMS control region to provide security in the IMS TM (online) environment. Structured infostorage records similar to GSO records contain the eTrust CA-ACF2 IMS options for each IMS control region. Each site specifies the resources that eTrust CA-ACF2 protects and a three-character resource type code for each resource protected by eTrust CA-ACF2. See the IMS Support Guide for further details on the eTrust CA-ACF2 IMS TM interface.

The eTrust CA-ACF2 IMS TM Interface, by default, includes resource validation for the following IMS resources:

■ Transactions

■ Application group names (AGNs)

■ Commands

■ Program specification blocks (PSBs)

2–8 Auditor Guide


Validation of IMS resources is controlled by the RESOURCE structured infostorage records and the MODE option of the OPTS structured infostorage record.

MODE=QUIET|LOG|ABORT The MODE parameter specifies the security mode of the eTrust CA-ACF2 IMS system. Valid options are QUIET, LOG, and ABORT. Unless ABORT is specified, eTrust CA-ACF2 does not deny a user access to IMS resources. The QUIET and LOG options are provided as transition aids to be used during initial implementation of eTrust CA-ACF2 IMS. LOG causes resource validation to be performed, but users are granted access to the resource (with an SMF logging) even if a rule does not specifically grant the access. When in QUIET mode, eTrust CA-ACF2 IMS does no resource validation.

RESOURCE Structured Infostorage Records The parameters on the RESOURCE structured infostorage records indicate the types of IMS processing that are controlled by eTrust CA-ACF2 resource rules and the eTrust CA-ACF2 resource rule type code that is used to store the rules for each resource being protected.

The parameters on the IMS structured infostorage records that control resource validation are NAME, TYPE, and VALIDATE|NOVALIDATE.

NAME Specifies the IMS resources that are controlled by eTrust CA-ACF2 resource rules. Possible values for the NAME parameter are:

■ $PRITRAN Identifies the RESOURCE record for primary transactions.

■ $SECTRAN Identifies the RESOURCE record for secondary transactions.

■ $AGN Identifies the RESOURCE record for application group names.

■ $COMMAND Identifies the RESOURCE record for commands entered from a terminal.

■ $TRANCMD Identifies the RESOURCE record for commands initiated from a transaction program.

■ $PSB Identifies the RESOURCE record for program specification blocks (PSBs).

TYPE Specifies the eTrust CA-ACF2 resource rule type code for the IMS resource identified in the NAME parameter.



VALIDATE|NOVALIDATE Specifies whether eTrust CA-ACF2 protects the identified IMS resource.

The /ACF SHOW STATE command is provided to display the eTrust CA-ACF2 IMS system options currently in effect. The RESOURCE parameters and the MODE setting are displayed.

eTrust CA-ACF2 IMS Batch Interface

eTrust CA-ACF2 support can be defined to provide security in the IMS batch environment. Structured infostorage records similar to GSO records contain the eTrust CA-ACF2 IMS options for the IMS batch environment. Each installation specifies the resources that eTrust CA-ACF2 IMS protects and a three-character resource type code for each resource protected by eTrust CA-ACF2. See the IMS Batch Support Guide for further details on the eTrust CA-ACF2 IMS Batch interface.

The eTrust CA-ACF2 IMS Batch Interface, by default, includes resource validation for the following IMS resources:

■ PSBs

■ Databases and database segments

Validation of IMS resources is controlled by the PSBTYPE, SEGTYPE, and MODE options of the DLI structured infostorage records.

PSBTYPE PSB Rule Type Code Specifies the resource type code used to validate the PSB associated with the application program. If you choose IGNORE, access to PSBs is not validated.

SEGTYPE Segment Rule Type Code Specifies the resource type code used to validate the segments associated with the database calls. If you choose IGNORE, access to database segments is not validated.

MODE=QUIET|LOG|WARN|ABORT Specifies the security mode in which the eTrust CA-ACF2 IMS Batch Interface operates. When in QUIET mode, eTrust CA-ACF2 does no resource validation; all access requests are allowed. LOG specifies that all access requests are allowed, but are logged if access would normally be denied in ABORT mode. With WARN, access violations are logged, warning messages are issued, and processing can continue. ABORT denies access with a system abend code or a DLI status code.

2–10 Auditor Guide

eTrust CA-ACF2 and CICS

eTrust CA-ACF2 and CICS eTrust CA-ACF2 support must be defined for each CICS region. Separate control parameters must be built for each region. The site specifies the resources that eTrust CA-ACF2 CICS protects. The site can also specify a three-character resource type code for each resource to be protected by eTrust CA-ACF2. See the CICS Support Guide for further details on the eTrust CA-ACF2 CICS security subsystem.

The eTrust CA-ACF2 CICS subsystem includes resource validation for the following CICS resources:

■ Transactions

■ Programs

■ Files

■ Transient data

■ DL/I calls

■ Temporary storage

■ MRO requests (Multiple Region Operation)

■ User resources

eTrust CA-ACF2 must be explicitly directed to validate access to all of these resources through the eTrust CA-ACF2 CICS system initialization parameters. The parameters are defined in a sequential data set by the systems programmer who installs the eTrust CA-ACF2 CICS subsystem. For this reason, adequate access controls must be in place for the data set that contains these parameters.

In addition, a transaction named ACFM is provided that enables these eTrust CA-ACF2 CICS control parameters to be dynamically updated from a CICS terminal. All ACFM functions can be individually secured. Strict controls should be placed on who can use the ACFM transaction and it might be desirable to log all use of ACFM. ACFM also enables all current eTrust CA-ACF2 CICS control parameters to be displayed at a CICS terminal, which is a convenient tool for auditors.


eTrust CA-ACF2 and CICS

Control parameters that you should be particularly concerned with are:

CICSKEY Describes a particular CICS resource and directs eTrust CA-ACF2 to validate requests to the resource or to ignore (always allow) accesses to the resource. There can be any number of CICSKEY parameters for each CICS region. The CICSKEY parameter also defines the three-character eTrust CA-ACF2 resource type code to be associated with a particular type of CICS resource. By default, eTrust CA-ACF2 uses the following type codes:

■ CKC Transactions

■ CPC Programs

■ CFC Files

■ CTD Transient data

■ CPB DL/I calls

■ CTS Temporary storage

■ CMR MRO SYSIDs

■ XCD CICS commands

OPTION MODE=QUIET|LOG|ABORT Specifies the security mode of the eTrust CA-ACF2 CICS subsystem. Options are QUIET, LOG, and ABORT. Unless ABORT is specified, eTrust CA-ACF2 does not deny a user access to CICS resources. The QUIET and LOG options are provided as transition aids used during initial implementation of eTrust CA-ACF2 CICS. LOG causes resource validation to be performed (based on CICSKEY parameters), but users are granted access to the resource (with an SMF logging) even if a rule does not specifically grant the access. When in QUIET mode, eTrust CA-ACF2 CICS does no resource validation.

SAFELIST Define those CICS resources that all CICS users can access. No eTrust CA-ACF2 CICS validation is performed when a user requests access to a “safe” resource. You should ensure that the SAFELIST parameter does not inadvertently grant users access to a sensitive resource.


eTrust CA-ACF2 SAF Interface

USERKEY Similar to CICSKEY definitions, USERKEY definitions allow a site to secure user-defined resources. eTrust CA-ACF2 CICS provides and uses the ACF2CTRL USERKEY resource to provide security for the various subfunctions of the ACFM master terminal transaction.

eTrust CA-ACF2 CICS security depends on the correct installation and operation of the CA-Common Services CAIENF and CAIENF-CICS components. Installation instructions for the CA-Common Services can be found in the CA-Common Services Getting Started (or CA90s Services Installation Guide). Installation instructions for eTrust CA-ACF2 CICS can be found in the CICS Support Guide.

Selecting which CICS/ESA 4.1.0 and above regions are to be protected by eTrust CA-ACF2 CICS is made by setting the ACF2CICS privilege in the CICS region logonid. The following additional changes are also required:

■ Add/modify JCL statements for eTrust CA-ACF2 CICS libraries and data sets

■ Add/modify eTrust CA-ACF2 CICS program and transaction definitions to the CICS DFHCSD RDO file

eTrust CA-ACF2 SAF Interface eTrust CA-ACF2 intercepts all calls to the System Authorization Facility (SAF) and processes these requests for security services. For detailed information on SAF protection, see “Understanding SAF” in the Administrator Guide.

A site can exclude or alter eTrust CA-ACF2 SAF processing through the use of the GSO SAFDEF record. You should examine SAFDEF records to ensure that site policies concerning the use of SAF are adequately reflected in the implementation of eTrust CA-ACF2.

Use of Local Exits A significant factor that affects the total scope of eTrust CA-ACF2 protection is the use of exits to insert local code and thus alter (or circumvent) the eTrust CA-ACF2 decision processes. There are many local exits provided in the standard eTrust CA-ACF2 product. Additionally, exits in other subsystems can also be used to alter the results of eTrust CA-ACF2 controls (for example, Logon Preprompt user exit, SMF exits, or JES exits). One of the first things that you should check when you review an eTrust CA-ACF2 site is the use of these exits. If these exits are used, you must review the actual code placed in each one to determine exactly what takes place.


Use of Local Exits

The need to review these exits early in the system review stems from two important considerations. First, you should check the exits to ascertain that only authorized activities take place there. Also review procedures and controls over changes to these exits. Second, you should understand the authorized activities that do take place before the rest of the eTrust CA-ACF2 parameters, rules, and records are checked, because these exits could have a profound impact on how eTrust CA-ACF2 processing proceeds. For example, an exit could affect which access rule eTrust CA-ACF2 actually uses to check a data set access request, or it could decide to bypass the eTrust CA-ACF2 check altogether. The effect of local exits is not apparent from a review of decompiled rules or with the ACF TEST subcommand. Therefore, you must carefully check the exits themselves.

You can use the SHOW ACTIVE subcommand to review the eTrust CA-ACF2 exits. Issue this subcommand to view a panel that identifies each of the eTrust CA-ACF2 exits that has active code at your site. The panel also displays the module name used for the code. The various eTrust CA-ACF2 exits and some of the effects they could have on eTrust CA-ACF2 processing are described in the Systems Programmer Guide. These include:

Data Set and Program Prevalidation Exit This exit could alter the data set name or rule set key eTrust CA-ACF2 uses for validation, or instruct eTrust CA-ACF2 to unconditionally allow, log, warn, or abort a request without rule checking. The GSO EXITS record field is VLDEXIT. The SHOW ACTIVE text is DSN PRE-VALIDATE.

Data Set and Program Postvalidation Exit This exit receives control after eTrust CA-ACF2 has determined if an attempted data set access is allowed. The GSO EXITS record field is DSNPOST. The SHOW ACTIVE text is DSN POST-VALIDATE.

Data Set and Program Violation Exit This exit can alter the eTrust CA-ACF2 recommendations (for example, allow the access versus abort). The GSO EXITS record field is VIOEXIT. The SHOW ACTIVE text is DSN VIOLATION.

Expired Password Exit This exit can grant system access even when the user’s password is expired and can set a new password for the user (and display it to him). The GSO EXITS record field is EXPPXIT. The SHOW ACTIVE text is PASSWORD EXPIRATION.

Infostorage Database Preprocessing Exit This exit is similar to the access rule exit previously described and grants site control of the retrieval of records in the Infostorage database. This exit enables changes to access privileges as well as to information in the Infostorage database. The GSO EXITS record field is INFOPRE. The SHOW ACTIVE text is INFO PRE-PROCESS.


Use of Local Exits

Infostorage Database Postprocessing Exit This exit grants site control of the storing of records in the Infostorage database. The GSO EXITS record field is INFOPST. The SHOW ACTIVE text is INFO POST-PROCESS.

JESx USER01 Exits Local code in these exits could affect eTrust CA-ACF2 processing by altering the logonid or the source name, or by having the system bypass password validation requirements. There is not a field on the GSO EXITS record for JESx USER01 exits. There is no SHOW ACTIVE text for these exits. Use the $DEXITS console operator command to display JES2 exits. Use the Dump Core utility to display the JES3 exits.

Logon Parameter Exit This exit lets sites alter certain selected parameters (for example, account and procname, before eTrust CA-ACF2 builds the JCL to complete logon validation process). The GSO EXITS record field is LGNPARMS. The SHOW ACTIVE text is TSO LOGON PARM.

Logon Postvalidation Exit This exit can modify information sent to TSO or used to build the TSO JCL. The GSO EXITS record field is LGNPXIT. The SHOW ACTIVE text is LOGON POST-VALIDATE.

Logon Preprompt Exit This exit receives control after all eTrust CA-ACF2 processing has completed and enables you to perform further logon work area (LWA) processing. You cannot specify this exit in the GSO EXITS record. The exit name must always be USREFLD.

Logon Prevalidation Exit This exit can modify the logonid (or the password) that eTrust CA-ACF2 uses for checking. The GSO EXITS record field is LGNIXIT. The SHOW ACTIVE text is LOGON PRE-VALIDATE.

Logon Terminal Exit This exit enables sites to identify special printing devices. The GSO EXITS record field is LGNTERM. The SHOW ACTIVE text is TSO LOGON TERM TYPE.

Logonid Database Preprocessing Exit The GSO EXITS record field is LIDPRE. The SHOW ACTIVE text is LID PRE-PROCESS. This exit grants site control of the retrieval of logonid records. This exit enables changes to access privileges and to information in the logonid database.

Logonid Database Postprocessing Exit This exit grants site control of the storing of logonid records. The GSO EXITS record field is LIDPOST. The SHOW ACTIVE text is LID POST-PROCESS.


Use of Local Exits

Logonid Search Sequence Modification Exit This exit is used to modify the eTrust CA-ACF2 Distributed Database search sequence when looking for a logonid. The GSO EXITS record field is LIDLOC. The SHOW ACTIVE text is DDB LID NODE LOC.

Logonid Record Modification Exit This exit is used to change a logonid record that DDB is about to ship to a remote node. The GSO EXITS record field is LIDMOD. The SHOW ACTIVE text is DDB USER INFO MOD.

New Password Exit This exit can enforce certain syntax or formats on user’s passwords. If these formats are too stringent or the permissible patterns are too widely known, this could lead to easy guessing of passwords. The GSO EXITS record field is NEWPXIT. The SHOW ACTIVE text is NEW PSWD VALIDATE.

Pseudo Data Set Name Generator Exit This exit can alter the data set name eTrust CA-ACF2 uses for validation against the rules. It can also select (point eTrust CA-ACF2 to) the rule set key that is used. This exit can also instruct eTrust CA-ACF2 to unconditionally allow, log, warn, or abort a request without eTrust CA-ACF2 doing any rule checking. The GSO EXITS record field is DSNGEN. The SHOW ACTIVE text is PSEUDO DSN GENERATE.

Program Override Exit This exit lets you change a program that eTrust CA-ACF2 determines is performing a data set OPEN for program pathing purposes. The GSO EXITS record field is PGMOVRD.

Resource Prevalidation Exit This exit can do everything the Pseudo Data Set Name Generator or Data Set Prevalidation exit can do, except that it applies to resource rules instead of data set access rules. The GSO EXITS record field is RSCXIT1. The SHOW ACTIVE text is RSRC PRE-VALIDATE.

Resource Postvalidation Exit This exit can alter the eTrust CA-ACF2 recommendations. For example, it can change the eTrust CA-ACF2 decision to abort the request to “allow, no log.” The GSO EXITS record field is RSCXIT2. The SHOW ACTIVE text is RSRC POST-VALIDATE.

Rule Database Preprocessing Exit This exit grants a site control of the retrieval of access rule records. This exit enables changes to access privileges as well as to information in the Rule database. The GSO EXITS record field is RULEPRE. The SHOW ACTIVE text is RULE PRE-PROCESS.

Rule Database Postprocessing Exit This exit enables site control of the storing of access rule records. The GSO EXITS record field is RULEPST. The SHOW ACTIVE text is RULE POST-PROCESS.


Use of Local Exits

Source Name Modification Exit This exit can modify the source name eTrust CA-ACF2 uses for validating the user’s access to the system or for matching rules. This can make the access request appear as if it were from a different entry point than it really was. The GSO EXITS record field is SRCXIT. The SHOW ACTIVE text is SOURCE MODIFICATION.

Started Task Validation Exit This exit could modify the logonid used to validate accesses by started tasks. The GSO EXITS record field is STCXIT. The SHOW ACTIVE text is STC VALIDATE.

Supervisor Call Initialization Exit This exit receives control before eTrust CA-ACF2 supervisor call processing begins. Your site can use this exit to change the address of the ACUCB or ACMCB that eTrust CA-ACF2 uses to validate access, program, and alter requests. It is particularly useful within a MUSASS environment. The GSO EXITS record field is SVCIXIT. The SHOW ACTIVE text is SVC INITIALIZATION.

System Entry Validation Preprocessing Exit This exit can alter the attributes used to gain access to the system before validation takes place. The GSO EXITS record field is SEVPRE. The SHOW ACTIVE text is SEV PRE-PROCESS.

System Entry Validation Postprocessing Exit This exit could alter the attributes used to gain access to the system after validation takes place. The GSO EXITS record field is SEVPOST. The SHOW ACTIVE text is SEV POST-PROCESS.

You should carefully review the exits present at your site for use, and their effect on the rest of eTrust CA-ACF2 processing. Most of this guide (as well as other eTrust CA-ACF2 guides) is written assuming no exits are present to alter eTrust CA-ACF2 processing. Thus, when these exits are used, you must consider the consequences when reading any other section of the guide and when auditing the system. This can involve trying to manually simulate the exit processing when reviewing rules or output reports.


External Environment

External Environment As mentioned earlier, the purpose of this guide is to address the management, administration, and audit of the eTrust CA-ACF2 portion of your site’s approach to data processing security. There are many other aspects of security outside the scope of direct eTrust CA-ACF2 control, and outside the scope of this guide. However, these related aspects are very important, and no security implementation or EDP audit is complete without giving these areas careful consideration. The controls provided by eTrust CA-ACF2 are only as secure as the foundation on which the operating system is built and the environment in which it exists.

To ensure that all internal and eTrust CA-ACF2 controls are operating properly, system maintenance procedures must be carefully reviewed. Some of these areas are referred to in this guide—for example, comments on the necessity to check the procedures and controls related to the local establishment and modification of eTrust CA-ACF2 exits. Others are not discussed in this guide but should not be overlooked because of their impact on the overall validity of your system controls.

Some examples of these other areas for investigation are:

■ The procedures and controls for adding or changing:

– SVCs

– STCs

– PPT (program properties table)

– APF (authorized programs/libraries, PARMLIB, and so forth)

– System and subsystem code (vendor provided or locally generated).

■ The procedures and controls that exist for:

– Reassembling the ACFFDR

– Altering GSO entries

– Relinking eTrust CA-ACF2

– Modifying or adding eTrust CA-ACF2 exit code

– Changing the TSO command limiting load modules

– Changing the eTrust CA-ACF2 parameters for CICS, IMS, and CA-IDMS interfaces or other product interfaces.

■ The method in which operating system integrity problems are reported, documented, tested, and fixed.

■ The procedures and controls for hands-on (physical) access to the computer system (for example, operator consoles) and data (for example, disk packs and tape volumes).


Chapter

3 System Access Control

Because eTrust CA-ACF2 determines whether an individual user should be permitted access to a resource, it must be able to associate a user’s identity with each job or time-sharing session. No job can run on an eTrust CA-ACF2-controlled system unless it can first be identified with a valid, predefined user. Thus, eTrust CA-ACF2 is also protecting the resources of the computer system itself. No one can use processing time on your system unless they are running under a logonid you have previously defined to eTrust CA-ACF2.

Verify that each user is assigned a unique logonid for eTrust CA-ACF2 control. Encourage the use of individual logonids for each individual user and review the procedures for assigning, changing, and using logonids.

Review reports to see how the logonids are used, with special attention to powerful logonids and production jobs. eTrust CA-ACF2 default logonids are provided as eTrust CA-ACF2 implementation aids, and should appear only infrequently after the initial transition period. Because the default IDs are only assigned to jobs for which valid regular logonids were not available, there is no control over the actual submitting user. Therefore, rules should not let default IDs access data or have other special privileges.

The key to eTrust CA-ACF2 control of system access is the logonid. The rest of this chapter describes the logonid record.

The Logonid Record The eTrust CA-ACF2 logonid record contains the information about each user that eTrust CA-ACF2 needs to make decisions regarding access to resources and the user’s authority to update eTrust CA-ACF2 databases. It can also contain some site-specified fields. Some of these fields are informational for efficiency and ease, while others are very critical to the operation of eTrust CA-ACF2 and the definition of controls at that site.

System Access Control 3–1

Separation of Function

Additional user-related information can be maintained in a number of ancillary records called User Profile records. This information is application-specific and is maintained by the security system rather than the individual application and/or system products. The SAF RACROUTE REQUEST=EXTRACT call is used to request this information from the security system.

You can use the PROFILE keyword on the ACF command LIST subcommand to list any profile records that have been defined for a userid. For example, the following command lists the TESTLID logonid record and any profile records defined for this logonid: LIST TESTLID PROFILE(ALL)

For more information about the use of Profile records, see the “Maintaining Profile Records” chapter in the Administrator Guide.

Separation of Function You must ascertain if there is adequate separation of function between different activities and between users with different powers. Use of eTrust CA-ACF2 is no exception. There are a number of special privileges and special powers that can be granted to users with eTrust CA-ACF2 logonid and system options. There are also related activities (such as system maintenance functions) that take place at a site and that should be considered due to their possible impact on eTrust CA-ACF2 controls.

Special Users One important area that you should review is the assignment of the eTrust CA-ACF2 attributes of SECURITY, ACCOUNT, AUDIT, LEADER, and CONSULT. Each of these attributes carries with it special powers that should not be available to the normal eTrust CA-ACF2 user. No user should have all of these attributes. In fact, SECURITY and AUDIT should usually be mutually exclusive to help enforce separation of function. However, many of the exact privileges that each of these attributes entails is variable (changeable by the site itself), so policies on the use of each of these can be different for each site. Listed in the following is a general description of each of these attributes.

SECURITY

Users with this attribute are usually the data security administrators for the site. Normally their duties include the maintenance of all access rule and resource rule records, input source entry records, and scope and shift records.

3–2 Auditor Guide

Special Users

An unrestricted security administrator (one with SECURITY and no scope limits) can create, change, list, or delete any rule record or eTrust CA-ACF2 infostorage record (such as entry records, scope records, and shift definitions). The unrestricted security administrator can also access any resource because, even if a permitting rule does not exist, he has the authority to create or change such a rule. However, eTrust CA-ACF2 logs and flags any accesses by security administrators that are not specifically authorized through eTrust CA-ACF2 rules.

The unrestricted security administrator can also execute any program on the restricted programs list (PPGM). He can also change and display certain fields in logonid records that no other users (including restricted security administrators) can change; however, the privileges related to changing selected logonid record fields are modifiable by the site. A person with the SECURITY attribute cannot establish or delete logonid records unless he or she also has the ACCOUNT attribute.

A restricted security administrator has the SECURITY attribute but his authority is limited with a scope record. This record is named in the SCPLIST field of the administrator’s logonid record. The restricted security administrator has full SECURITY privileges but can apply them only to rules and records, including logonid records that fall within this scope. See the Centralized and Decentralized Administration section later in this chapter for more information regarding scope fields.

Any security administrator (restricted or unrestricted) can use various TSO ACF subcommands not available to the normal user (such as SHOW STATE, SHOW ACTIVE, and SHOW TSO).

ACCOUNT

Users with this attribute are usually assigned the responsibility to establish, maintain, and delete logonid records. The ACCOUNT attribute grants no privileges relative to the Rule database or the Infostorage database.

Persons with ACCOUNT can also use the various SHOW subcommands. They can also change and display a large number of individual logonid fields (these fields can be defined by the site).

Only unrestricted account managers (users with ACCOUNT and no scope record assigned to them) can execute the SYNCH command to synchronize the eTrust CA-ACF2 Logonid database with the TSO BRODCAST data set.

Note: A user with both the SECURITY and the ACCOUNT attributes is considered more powerful than one with only one of these attributes. A user with only one attribute cannot modify the logonid record of a user with both attributes.


System Options and Special Users

AUDIT

A user with this attribute can usually display all records in any eTrust CA-ACF2 database (and use the SHOW subcommands). An auditor does not have the authority to update or delete any of these records or to access any resources except those specifically authorized to him with access or resource rules. Through scope records, an auditor can be restricted to only certain rules, certain logonid records, and to certain infostorage records. The READALL privilege (defined in the logonid record) can be set to grant an auditor or any other privileged user the ability to read and execute all data sets at the site, regardless of the access rules. This is similar to the NON-CNCL attribute, but grants only read and execute accesses; eTrust CA-ACF2 continues to enforce the existing rules for any other type of access.

LEADER

This attribute does not grant any special powers relative to the Rule or Infostorage database. Leaders cannot create or delete logonid records (unless they also have ACCOUNT). Leaders can, however, change or display a limited number of fields in existing logonid records. The fields they have access to can be controlled at the field level at the site, and the logonid records they have access to can be controlled through scope records. Leaders are usually not too powerful and they usually have very limited scopes.

CONSULT

This attribute is usually assigned to users who assist other users in using the computer system. Usually consultants cannot update anything significant in logonid records but can display some of the less sensitive fields to help answer questions. The site controls which fields consultants can display or alter, and, through scope records, which logonid records consultants can access.

System Options and Special Users A combination of system options (set in the ACFFDR and GSO) and individual logonid record values determine the extent of some of the powers associated with each of these eTrust CA-ACF2 special privileges. These must be reviewed together as there are a number of interrelationships.

3–4 Auditor Guide

System Options and Special Users

Reviewing @CFDE Settings in the ACFFDR

Review the assignment of ALTER, AUTH, FLAGS and LIST values for each field of the logonid record. These values are in the ACFFDR @CFDE macros (there is one @CFDE entry for each eTrust CA-ACF2 logonid record field).

ALTER The keywords listed after ALTER= in each @CFDE identify the special eTrust CA-ACF2 privileges (SECURITY, ACCOUNT, AUDIT, LEADER, CONSULT, or USER) a user must have to alter the value of that field in his (or anyone else’s) logonid record.

AUTH Additionally, the AUTH= parameter in the @CFDE macro indicates that eTrust CA-ACF2 checks the requester’s logonid record for a site-defined attribute before passing control to ALTER= processing. Some fields have no ALTER values; these fields should be updated by eTrust CA-ACF2 only (internally) and no users should be authorized to change them. (AUTH validation checking is optional and is performed after ALTER validation checking.)

FLAGS The authority to change a field can also be affected by the FLAGS parameter. If ALTER=SECURITY but FLAGS=RESTRICT (or RESTRICT plus any other parameters), only unrestricted security administrators can change the field.

LIST The LIST values in the @CFDE macro indicate the user privileges that are needed to display the values of that field. You should ensure that the AUDIT attribute is included as one of the LIST= attributes on every field (except PASSWORD, which nobody can list) so that an auditor has the authority to see values of all logonid data elements for a user. Similarly, no field (other than PASSWORD) should have FLAGS=NEVER, as this would prohibit an auditor or anyone else from displaying that field’s value, regardless of the LIST= parameters.

Even though the format for the ALTER and LIST parameters requires plus signs (+), a user needs only one of the listed attributes to be granted that authority. For example, if a logonid record field has ALTER = SECURITY + ACCOUNT + LEADER in its @CFDE entry, any user with the SECURITY, ACCOUNT, or LEADER attribute could change that particular field (assuming the logonid record being changed belonged to a user within his scope see the discussion about scope limitations in the next section, Centralized and Decentralized Administration.


Centralized and Decentralized Administration

Many eTrust CA-ACF2 logonid record fields are predefined. That is, these fields have @CFDE macros in the default ACFFDR that comes with the eTrust CA-ACF2 product. For a list and description of these fields, see the Getting Started guide. Your site might have changed these default values or created a logonid field that contains multiple values, so be sure to review the actual @CFDE ACFFDR values your site is running.

Reviewing Decompile Authority in GSO RULEOPTS Record

Another control over the definitions of SECURITY, ACCOUNT, and similar eTrust CA-ACF2 authorities is the GSO RULEOPTS record DECOMP field. This field defines the types of users that are authorized to decompile and display rule records on a general basis. See Centralized and Decentralized Administration next for related controls. Also, review how DECOMP is set by looking at the SHOW STATE output for the DECOMP AUTHORITY = value. The default value enables users with SECURITY or AUDIT to perform decompiles.

Centralized and Decentralized Administration eTrust CA-ACF2 provides facilities to help you centralize or decentralize different aspects of eTrust CA-ACF2 administration. You must review these to determine who has the authority to add or change user logonid records or rules, who can further delegate these authorities, and what separation of function is in effect. For example, a scope field in each logonid record provides the ability to limit an individual’s authority to access the eTrust CA-ACF2 databases.

Scope Records

You can limit the powers of users with the SECURITY, ACCOUNT, AUDIT, LEADER, or CONSULT attribute by assigning scope records to their logonids. The scope record defines a group of eTrust CA-ACF2 records or rules. The name of this record is listed in the SCPLIST field of a logonid record to limit that user’s display or change authority to only those records or rules. The presence of the SCPLIST field in a user’s logonid record defines him as restricted.

For example, suppose that the ACFFDR @CFDE macro for the NAME field shows ALTER=ACCOUNT. This lets a user with the ACCOUNT privilege change the NAME field in logonid records. However, if a user with the ACCOUNT privilege also has a scope record listed in his logonids SCPLIST field, he can change the NAME field only in those logonid records that are included in that scope.

3–6 Auditor Guide


Note: The LID and UID fields work together. If you scope an ACCOUNT logonid, both the LID and UID fields require an entry. See the Administrator Guide for additional information.

The scope record can define a combination of logonid records, infostorage records, and rules. When you assign a scope record to a user (with the SCPLIST field of the logonid record) you place multiple data set indexes, logonid records, and UIDs in the user’s authority, and deny the user access to all other rules and records.

You should carefully audit the use of scope records. Scope records that are very long (for example, numerous entries for the same type) or that use a lot of masking can be a concern. Display these records regularly and review their use.

Displaying Scope Records

After you issue the ACF SET SCOPE(SCP) subcommand to establish the scope setting, you can use the ACF LIST subcommand to display scope records. The following is the syntax for this subcommand. LIST {*|scope-name|LIKE(scope-name-mask)} [ALL,DSN,INF,LID,UID]

The LIST subcommand displays:

■ A single record (enter one scope name)

■ The previous scope record referenced in this session (enter an asterisk (*))

■ A group of records (enter the LIKE operand and a mask).

See the “Maintaining Scope Records” chapter in the Administrator Guide for more information about scope records and a description of how to use ACF subcommands to maintain them.

Scope records are not effective until they are applied to a logonid. To determine which scopes are in use, display the privileged logonids using the LIST IF(privilege) subcommand under the LID setting. For example, to display all security administrator records, use LIST IF(SECURITY). See the Administrator Guide for more information about this subcommand.

You can also use the Selected Logonid List (ACFRPTSL) report to determine which scopes are in effect. See the Reports and Utilities Guide for a detailed description of this report.



Rule Compilation and DECOMP Authorities

The following options determine access to the Rule database:

SECURITY attribute

Security administrators (users with the SECURITY attribute in their logonid record) can write or change any rule set with a key (high-level index) that matches the value defined in their assigned scope record (or to any rule set if their logonid does not contain a SCPLIST field.) If the DSN parameter of the SCPLIST field contains no entries, the logonid associated with the scope is completely restricted from using the privilege relative to the Rule database.

DECOMP

Displayed using the SHOW STATE subcommand as: DECOMP AUTHORITY = SECURITY, AUDIT

The DECOMP field in the GSO RULEOPTS record specifies the authority required to decompile access or resource rules. Logonids with the authority levels listed in this field can decompile (but not change) rules regardless of any restrictions imposed by a scope.

NOCENTRAL

Displayed using the SHOW STATE subcommand as: CONTROL=CENTRALIZED|DECENTRALIZED

If the GSO RULEOPTS record CENTRAL field is set to NOCENTRAL, eTrust CA-ACF2 rule writing authority is not centralized (for security administrators only) but rather is decentralized. Each user has the authority to change the rule set or sets that match their own data set prefix (in the logonid record field named PREFIX). For TSO users, PREFIX is usually equal to the user’s TSO logonid. The user could write or change the rule set whose key (high-level index) is his logonid. Because PREFIX can contain a mask (pattern), it could match multiple high-level indexes. A user with a PREFIX field of all asterisks under NOCENTRAL could change any rule set, even though he is not a security administrator. The CENTRAL field is a system-wide option.

3–8 Auditor Guide


%CHANGE

Displayed using the SHOW STATE subcommand as: %CHANGE=ALLOWED|DISABLED

A %CHANGE control statement can be present in any access or resource rule set. When a %CHANGE control statement is present, the users who match the listed UIDs are usually permitted to:

■ Decompile, compile, and store the rule set

■ Change rule entries and control statements in the set

■ Further delegate the %CHANGE authority (by changing the %CHANGE control statement in the set)

The CHANGE field of the GSO RULEOPTS record specifies whether %CHANGE and %RCHANGE are recognized in access rules. If NOCHANGE is specified, %CHANGE and %RCHANGE control statements are ignored. The default value is CHANGE, which enables security administrators at a site to specify %CHANGE and %RCHANGE in rule sets.

%RCHANGE

Displayed using the SHOW STATE subcommand as: %CHANGE=ALLOWED|DISABLED

A %RCHANGE control statement indicates restricted %CHANGE authority. The users who match the UIDs listed in %RCHANGE can change only rule entries in the rule set. They cannot change control statements, and therefore cannot further delegate %CHANGE or %RCHANGE authority. However, there are two more fields that affect how %CHANGE and %RCHANGE operate at a site (see NOCHANGE and NO-STORE).

The CHANGE field in the GSO RULEOPTS record specifies whether %CHANGE and %RCHANGE are recognized in access rules. If NOCHANGE is specified, %CHANGE and %RCHANGE lines are ignored. The default value is CHANGE, which enables %CHANGE and %RCHANGE in rule sets.

NOCHANGE

Displayed using the SHOW STATE subcommand as: %CHANGE=DISABLED

If the GSO RULEOPTS record CHANGE field is set to NOCHANGE, then the %CHANGE and %RCHANGE authorities are not operational at that site. This is a system-wide field.


Displaying and Changing Infostorage Records

NO-STORE

If a user has the NO-STORE logonid attribute, he cannot store (change) or delete access or resource rule sets regardless of whether he owns the data by virtue of his logonid PREFIX value, has the SECURITY attribute, or has %CHANGE or %RCHANGE authority. The user can decompile (display) or compile and test a rule.

Displaying and Changing Infostorage Records Users with the unrestricted SECURITY attribute can list, delete, insert, and change any record that resides in the eTrust CA-ACF2 Infostorage database. These records include resource rules, entry records, GSO records, scope records, shift, and zone records.

As previously noted, the authority of the SECURITY user can be restricted by the presence of the SCPLIST field in the logonid record. However, there is an option in the OPTS record called INFOLIST that can be used to enable scoped users to list (read-only access) all records residing in the Infostorage database with the exception of resource rules.

The INFOLIST option specifies the logonid attributes (such as ACCOUNT, SECURITY, or AUDIT) required to list records in the Infostorage database.

Critical Logonid Record Fields There are logonid record fields that, as eTrust CA-ACF2 is distributed, cannot be changed by any user except an unrestricted security administrator (that is, ALTER=SECURITY only and FLAGS=RESTRICT in the @CFDE entry in the ACFFDR). These fields represent extremely powerful attributes that must be carefully assigned. These fields are:

■ ACCOUNT ■ SECURITY ■ READALL ■ RULEVLD

■ LOGSHIFT ■ AUTODUMP ■ TAPE-LBL ■ CMD-PROP

■ NON-CNCL ■ MUSASS ■ JOBFROM ■ MUSDIDINF

■ SCPLIST ■ PREFIX ■ NO-SMC ■ PRIV-CTL

■ AUDIT ■ STC ■ REFRESH ■ RSRCVLD

■ MAINT ■ DUMPAUTH ■ UIDSCOPE ■ TAPE-BLP

■ PPGM ■ MUSUPDT ■ NO-STORE ■ UNICNTR


Sensitive Logonid Record Fields

■ ACCOUNT ■ SECURITY ■ READALL ■ RULEVLD

■ LDS

Descriptions of each field can be found in the chapter, “Maintaining Logonid Records” in the Administrator Guide or with the ACF command HELP FIELDS subcommand. Some of the other logonid fields that authorize powerful privileges are:

■ RESTRICT, SUBAUTH, and PROGRAM

■ LEADER and CONSULT (powers are site-dependent)

■ PREFIX

Additional critical logonid record fields are PASSWORD and any field that makes up part of the UID concatenation for the site. You should review who can alter any of these fields on any user’s record.

Two things are important when reviewing the use of these critical fields. First, carefully check the contents of each of these fields (by reviewing the ALTER, LIST, AUTH, and FLAGS parameters of each related @CFDE macro in the ACFFDR). Second, be sure any logonids with special privileges really require those privileges. This can be done for each of the bit fields listed (a bit field is one that represents a privilege that can be turned on or off) by using the ACF LIST IF subcommand. The ACFRPTSL (Selected Logonid List) report can also be used to select and list groups of users with special privileges.

Sensitive Logonid Record Fields Sites should carefully select those users who have the authority to alter or list critical and sensitive fields in the logonid records because they can influence the overall effectiveness of the security system.

Most of these sensitive logonid record fields come defined in the standard eTrust CA-ACF2 package (in the ACFFDR @CFDE entries). A security administrator or an account manager can modify them. These fields should usually be controlled at that level, and should not be alterable by the user himself or leaders, consultants, or auditors. However, the circumstances at any given site can differ. Carefully review the @CFDE entries for your site with respect to local conditions.



No one should have the authority to alter the logonid fields that eTrust CA-ACF2 maintains internally. Again, the local @CFDE entries should be checked to see who (if anyone) is authorized to ALTER these fields. The default ACFFDR @CFDE macros specify that no one can alter the following fields: ACC-CNT, ACC-DATE, ACC-SRCE, ACC-TIME, CSDATE, CSWHO, PSWD-TOD, PSWD-SRC, PSWD-TIM, UPD-TOD, and GROUP. Enabling users, even security administrators, to change these fields, could jeopardize correct operation of eTrust CA-ACF2. For example, the PSWD-TOD value is used in the password encryption algorithm. If it were changed, the password would no longer match. However, under special circumstances, a site can want to grant special user authority to change one of these fields.

For example, it might be appropriate to permit a security administrator to reset some or all ACC-CNT fields to zero and use the field to help identify which users were the heaviest system users, or whether some special logonid (like a batch production logonid or a default ID) was being overused.

The logonid record fields that can be displayed or changed by a user can also be determined via the ACF SHOW FIELDS subcommand. Examples of outputs from this subcommand are in the “Sample SHOW Outputs” appendix. The SHOW subcommands can be executed through TSO, batch utilities, and also through eTrust CA-ACF2-supplied ISPF panels.

Field Descriptions

Sensitive fields in the logonid record include:

NAME The name of the user assigned that logonid. This is displayed on logging and security reports.

CANCEL, SUSPEND, MONITOR, TRACE, TSO-TRC These fields are used to temporarily or permanently remove a user’s privilege to access the system and produce special audit trails (reports) of his activities.

IDLE This field controls IMS and CICS operations by specifying the number of minutes an operator can leave his terminal inactive (no transactions submitted) before being forced to revalidate his password (IMS and CICS) or sign-on again (CICS). If it is set too high or not set at all, operators can leave their terminals for extended periods of time without signing off. Parameters in the interfaces can specify that this field is ignored.



GROUP This field displays the last group name associated with the user at system entry and cannot be altered. eTrust CA-ACF2 validates the GROUP logon parameter entered at system entry against resource rules of the type TGR and, if access is granted, stores this value in the logonid record field. This field affects data access if the GROUP logonid field is defined in the site’s UID specification. Because the user can specify different values for GROUP at each system entry, the user can have different access privileges for each session if GROUP is part of the UID.

MAXDAYS This field identifies the maximum number of days permitted between password changes by the user before eTrust CA-ACF2 expires the password and forces a change. This value can be different for each user, and should be a smaller number for those users with more powers (such as security administrators) to help prevent their passwords from being discovered by others.

MINDAYS This field defines the minimum number of days that a newly changed password must remain active before the user can change it. One use for this field is to keep users from changing their password to a temporary password and then immediately changing back to the old one again.

However, setting MINDAYS to greater than zero will prevent a user from quickly changing his or her password if it is inadvertently exposed.

SOURCE, CICS, IMS, JOB, TSO These fields identify the input sources from which a user can submit jobs or enter the system. They can help control the use of various logonids. These fields can be used independently or with the SOURCE fields in the rule records.

PSWD-DAT, PSWD-VIO, SEC-VIO, SHIFT, ZONE These fields include information on the number of violations a user incurs, allowable access time periods, and time zone definitions. They are useful for monitoring users’ activities, and are vital to certain eTrust CA-ACF2 routines in determining when to suspend a user’s privileges.

TSOCMDS This field indicates the name of the list of TSO commands the user is authorized to use. It can help control use of various powerful commands, including the ACF command itself. The list that is assigned to each user and the contents of each list should be reviewed. Command processing is effective for all logonids (even privileged ones) but is not effective when eTrust CA-ACF2 is in QUIET mode.


Chapter

4 Data Set Access Control

eTrust CA-ACF2 protects all data by default from everyone except the data owner. Each logonid on the system has an owned data set prefix that is equal to the value of the PREFIX field in the logonid record. During an attempted access to a data set, eTrust CA-ACF2 compares the high-level index (the characters in the data set name before the first period) to the value of the user’s PREFIX field. If they match, access is automatically permitted. Otherwise, eTrust CA-ACF2 searches for an access rule set that governs access to that index. If no access rule set for that index exists, eTrust CA-ACF2 denies the access unless RULE mode is in effect. (RULE mode is an interim mode sites use gradually to migrate to full security.) You can set the PREFIX field to blanks, effectively requiring eTrust CA-ACF2 to check all of that user’s accesses. Similarly, you can turn on the RULEVLD field of the logonid record for this user, requiring eTrust CA-ACF2 check the rules for all data set accesses.

When eTrust CA-ACF2 locates the access rule set, it interprets the access rules to locate one that matches the environment that currently exists. If no access rule matches the environment, eTrust CA-ACF2 denies access to the data set unless RULE mode is in effect. If RULE mode is active, the site specifies the access that occurs in the absence of access rules. On the other hand, after eTrust CA-ACF2 locates an access rule that matches the current environment, eTrust CA-ACF2 compares the access request against the READ, WRITE, ALLOCATE and EXECUTE access permissions specified in that access rule. In accordance with what the rule specifies for these permissions, eTrust CA-ACF2:

■ Grants the access

■ Grants the access and writes an informational journal entry

■ Prevents the access and writes a “violation attempt” journal entry

Access rules also refer to a pseudo field of the logonid record called the user identification string (UID). eTrust CA-ACF2 constructs the UID dynamically at job initiation by concatenating specific character fields from the user’s logonid record. A site specifies the fields that are concatenated to form the UID string in the ACFFDR @UID macro. For example, the UID for a site can be composed of the department, job responsibility code, and the user’s logonid, such as: dpjlogonid

Data Set Access Control 4–1

Data Set Access Control

Where dp is the department, j is the responsibility code, and logonid is the user’s logonid.

As a specific example of the above, take an accounting department with its personnel split between receivables and payables. The UID looks like:

■ ACRlogonid for the Accounting department employees authorized to work on receivables

■ ACPlogonid for the Accounting department employees authorized to work on payables

The logonid value is the individual’s logonid.

eTrust CA-ACF2 lets you use an asterisk (*) anywhere in the specification of the UID to indicate that any character in the user’s UID is considered valid (or matched). In addition, eTrust CA-ACF2 pads UID specifications on the right with asterisks to the maximum length of the UID so that you only need to specify the left-hand portion. Using the previous example, some valid UID specifications are:

■ UID(AC) refers to anyone in the accounting department

■ UID(ACR) refers to anyone in receivables

■ UID(ACP) refers to anyone in payables

■ UID(AC*T1234) refers to users with logonids beginning with T1234 and who are in the accounting department

This sample UID and rule writing scheme works well if your employees perform only one job function. However, suppose that you have a person whose job responsibilities encompass both the receivables and payables function within the accounting department. How could you establish a security environment for this condition without having to modify your existing rules or having to resort to creating multiple Logonid records for each occurrence of an employees job function?

Short of completely restructuring your UID string (and changing all rules), you can redefine the job function field as a multi-valued Logonid field. This lets the job function field contain more than one value, thereby allowing you to let one Logonid be associated with more than one job function. See Specifying Multi-value Logonid Fields and UID Strings in the “Controlling System Entry” chapter in the Administrator Guide and Modifying the UID in the “eTrust CA-ACF2 Field Definition Record Generation” appendix in the Getting Started guide for additional information on the use of multi-valued Logonid fields within the UID string.

The rest of this chapter describes the elements of the eTrust CA-ACF2 access rule set.

4–2 Auditor Guide

The Access Rule Set

The Access Rule Set Access rule sets consist of control statements, optional comments, and rules. The rule set syntax follows:

■ Control statements are denoted by a dollar sign ($) or a percent sign (%) and must begin in column one. The $ control statements must appear before any % control statements or any rule entries.

■ Comments are denoted by an asterisk (*) in column one. You can place comment lines anywhere in a rule set, except between continuation lines of a single rule entry. eTrust CA-ACF2 does not save comments during compilation so that when the rule is later decompiled (with the DECOMP subcommand), they do not appear in the output. However, they are not removed from a PDS member if the site’s rules are compiled from it.

■ Rule entries should start in column two (although they can start in column one if they do not start with a $, %, or *). You can continue them by ending the line with a dash (-).

Here is a sample rule set: $KEY(key) $MODE(QUIET|LOG|WARN|ABORT) $NORULELNG $NOSORT $OWNER(owner-id) $PREFIX $RESOWNER $USERDATA %CHANGE uid1,uid2,...,uidn %RCHANGE uid1,uid2,...,uidn * sample comment rule entry # 1 - continued rule entry # 1 * sample comment rule entry # 2 rule entry # 3

A description of each of the access rule set control statements follows:

$KEY Contains the high-level index of the data set name that this rule set governs. Users who have no authority to write rules for data other than what they own, as specified in the PREFIX field of the logonid record, enter their logonid in the $KEY statement.

$MODE Indicates the mode for this individual rule set. It is effective only if MODE(RULE) is set in the GSO OPTS record. We provide this control statement as a transition tool to ease the system into ABORT mode.

$NORULELNG Indicates that eTrust CA-ACF2 should use a compact record format when this rule set is compiled.


The Access Rule Set

$NOSORT Indicates that eTrust CA-ACF2 does not sort this rule set. It might not be in most specific to most general order. Carefully review the Rule database for any rule set that contains $NOSORT to ensure that a valid reason exists for the use of this control statement in the set and that the rule entry sequence is proper.

$OWNER Indicates an informational field of up to 24 characters used for local tracking or reporting purposes.

$PREFIX Indicates that local exit coding (Data Set Prevalidation exit) alters the eTrust CA-ACF2 rule selection process. Take extra care to ensure that the rule you are reviewing is really the one eTrust CA-ACF2 (as the exit modified it) uses. Additionally, the $PREFIX statement is specified when the NEXTKEY feature points to an alternate rule set eTrust CA-ACF2 checks. Ensure that proper control of NEXTKEY is maintained, because up to 25 alternate rule sets can be referenced. Also make sure, when you review a rule entry with a NEXTKEY, that you check the correct alternate rule set. (See the NEXTKEY description later in this chapter.)

$RESOWNER Specifies the logonid acting as the resource owner (RESOWNER) of the data set. eTrust CA-ACF2 submits this logonid to the IBM Data Facility Storage Management Subsystem (DFSMS) for validating a user’s access to the storage management resource classes.

$USERDATA Contains up to 64 characters of comments that are stored with the rule set (unlike comment statements that are discarded at compilation time).

%CHANGE Lists the UIDs of logonids that can update the access rule set. The permission is granted automatically to unscoped security administrators. Therefore, the %CHANGE control statement delegates authority for rule replacement.

%RCHANGE Indicates users with restricted %CHANGE authority. They can change rule entries only and cannot change control statements. Thus, they cannot further delegate the %RCHANGE authority. If a UID matches both %CHANGE and %RCHANGE control statements, the higher authority (%CHANGE) applies. You can fully specify or mask this UID. You can also specify a list of UIDs or masks. Multiple users could have the authority to change or delete the same rule set.

4–4 Auditor Guide

The Access Rule Set

Rule Entries

The format of an access rule entry is: dsnmask [Volume(volsermask)][UId(uidmask)][SOurce(sourcemask)] - [SHift(shiftname)][Library(libmask)] - [PGm(pgmmask)|PRogram(pgmmask)] [DDname(ddnamemask)][Until(date)|For(days)|Active(date)] - [DAta(data)][|Nextkey(nextkey)] - [Read(Allow|Log|Prevent)][Write(Allow|Log|Prevent)] - [Allocate(Allow|Log|Prevent)][Execute(Allow|Log|Prevent)]

We describe these parameters more fully in the following section. A dash as the last nonblank character on a line indicates that the rule is continued on the next line.

A description of each of these parameters follows:

Dsnmask (Required)—A data set name pattern. The compiler/interpreter always prefixes it with the high-level index specified by the $KEY control statement (unless a $PREFIX field is also present for that rule set, in which case the value of the $PREFIX field prefixes any data set name in the rule set).

You can specify this value as a fully qualified data set name or as a mask. An asterisk (*) indicates that any character can be present. A dash (-) as the only character in an index level indicates that any number of index levels can be substituted. Some examples of data set masks are:

A*.DATA matches:

■ A.DATA

■ AB.DATA

■ A1.DATA

A*******.DATA matches:

■ A.DATA

■ A1234567.DATA

A- matches:

■ A.DATA

■ A.B.C.D.DATA

■ A

-LOAD matches:

■ A.LOAD

■ A.B.C.D.LOAD

■ LOAD


The Access Rule Set

In addition, you can also use a dash as a shorthand notation for padding the index level with asterisks. For example, A*******.DATA is equivalent to -DATA.

VOLUME(volsermask) (Optional)—A pattern that specifies the specific set of volumes where the data set must reside to match this rule. If omitted, any volume is allowed.

UID(uidmask) (Optional)—A pattern that specifies the set of users this rule applies to. If omitted, all users of the system are considered matched.

SOURCE(sourcemask) (Optional)—The job input source group name this rule applies to. If omitted, any input source is valid. Contact your security administrator for a list of valid source names or entry types SRC and SGP under the ENTRY setting.

SHIFT(shiftname) (Optional)—The name of the shift record in the Infostorage database that applied to this rule entry. It defines the days, dates, and times that this rule entry is in force. If omitted, the rule is always in effect.

LIBRARY(libmask) (Optional)—A data set pattern specifying the set of libraries where the currently executing program must reside for this rule to apply. If you do not specify this pattern in quotation marks, the compiler prefixes it with the index specified by the $KEY control statement (or the $PREFIX control statement, if one is present). The library name SYS1.LINKLIB specifies all the libraries in the system link list and link pack area. If omitted, any library name is considered matching the rule.

PGM(pgmmask)|PROGRAM(pgmmask) (Optional)—A program name or a pattern defining the set of program names (in the set of libraries specified by the LIB keyword) that must be the executing program for this rule to apply. If omitted, any program is considered matched. Short forms are PROG or PGM.

DDNAME(ddnamemask) (Optional)—A pattern that specifies the ddname that must be used in the JCL for the applicable DD statement for this rule to apply. If omitted, any ddname is considered matched.

UNTIL(date) (Optional)—A Gregorian date specified as mm/dd/yy (or dd/mm/yy or yy/mm/dd, depending on the site option) that is the last date when this rule is considered valid.

FOR(days) (Optional)—The number of days from the day the access rule set was compiled that this rule is considered valid. You can specify the minimum number as 0 (meaning today) and the maximum number as 365.

4–6 Auditor Guide

The Access Rule Set

ACTIVE(date) A Gregorian date in the form mm/dd/yy, yy/mm/dd, or dd/mm/yy, depending on a site option (see the DATE field of the GSO OPTS record), that is the first date on which this rule is considered valid. Years specified as 70-99 assume a date in the 20th century (1970-1999); years specified as 00-69 assume a date in the 21st century (2000-2069).

DATA(data) (Optional)—Any character string up to 64 characters. This string is retained with the rule set and formatted when the rule set is decompiled. Your site can have standards concerning the format and use of this string.

NEXTKEY(nextkey) (Optional)—The next or alternate rule key eTrust CA-ACF2 checks. Use this option to split large rule sets, such as SYS1, into smaller ones. NEXTKEY can also merge groups of data sets that have identical access requirements. eTrust CA-ACF2 uses NEXTKEY only when an ABORT condition is detected (if a rule entry grants access, the NEXTKEY is not searched). See the chapters “Maintaining Access Rules” and “Maintaining Resource Rules” in the Administrator Guide for detailed examples of the use of this feature.

READ(Allow|Log|Prevent) (Optional)—The letter A, L, or P. It specifies that the read access (opening the data set for input) permission applies if there is a successful match of the data set name, VOLUME, UID, SOURCE, LIB, PROGRAM, and DDN parameters.

A—Allows access

L—Allows and journals (logs) the access

P—Prevents access

The default value is P for prevent.

WRITE(Allow|Log|Prevent) (Optional)—The same as the options for READ except that it applies to write access (opening the data set for output).

ALLOCATE(Allow|Log|Prevent) (Optional)—The same as the options for READ except that it applies to new data set allocation, deletion, rename, or catalog functions.

EXECUTE(Allow|Log|Prevent) (Optional)—The same as the options for READ except that it applies initiator access or the TSO CALL command for program loading. If omitted, the value is set to the READ value.


Reviewing Access Rules

When the eTrust CA-ACF2 compiler is invoked for a rule set, it reorders access rules so that the rule defining the most specific environment is first. This is the order that eTrust CA-ACF2 uses to search rules at execution time when eTrust CA-ACF2 consults the rule set to determine if access should be permitted. You can display this order by first compiling and then decompiling (through the DECOMP subcommand) an access rule set. The order specified in the output of the DECOMP subcommand is the order eTrust CA-ACF2 uses in its search. Rules become active as soon as they are stored through the STORE subcommand, the ACFCOMP command, or the ACFBCOMP program. However, because an access rule set is obtained from the eTrust CA-ACF2 database only once per job or online session, a new or revised rule cannot affect jobs or sessions already in progress when the access rule set was stored, unless the ACF SET NORULES subcommand is used to reset the rules.

The $NOSORT control statement prevents standard eTrust CA-ACF2 sorting of access rules when a rule set is stored. The rules remain in the order that they were first entered into the compiler through the terminal or a partitioned data set. Use this statement with caution because a general access rule can prevent eTrust CA-ACF2 from evaluating a more specific rule. The $NOSORT statement is effective only when the site specified $NOSORT in the GSO RULEOPTS record.

Reviewing Access Rules Now that you understand how to use rules, you should recognize that there are many aspects to review. First, you should ensure that each existing high-level index has a rule set (with the possible exceptions of items such as TSO logonid data sets not shared by their owners). After you identify all the rules, review each rule set in detail. When you review each rule set, keep the company security policies and standard good business practices in mind. The eTrust CA-ACF2 rules are an attempt to automate the enforcement of these policies and practices. You should check the following common areas:

■ Rule entries are correct. Check for the wrong number of asterisks in a name mask pattern, for contradictory entries, and so forth.

■ Rule entries are not too general for adequate controls. For example, be sure that the dash (-), which means everything allowed, is used sparingly in rule entries and that allocate authority is granted appropriately.

■ Use LOG, instead of ALLOW, where access is authorized but you want audit trails.

■ Site rules enforce local naming conventions, need-to-know, and similar policies.

4–8 Auditor Guide

Reviewing Access Rules

■ The authority to modify the rules is not inappropriately delegated (through %CHANGE, %RCHANGE, PREFIX entries, or multiple security administrators).

■ The correct mode is enforced. That is, if $MODE is used in individual rule sets, then MODE(RULE) should be set in the ACFFDR. You should also specify default modes for no$mode and norule set conditions. Be aware that the $MODE value can override a rule entry READ, WRITE, ALLOCATE, or EXECUTE access permission.

■ If you use the $NOSORT control statement, verify that the rule entries are in the correct sequence.

■ If you use the NEXTKEY feature, verify that the correct alternate rule set is referenced.

■ The operating environment is reliable.

These issues are in addition to the obvious topics of your review, such as whether the rules protect the sensitive, secret, and critical data appropriately and they correctly authorize only those with need-to-know to access the data. You should give early and careful attention to sensitive data sets, such as system or production data sets (like the master payroll file). In addition, ensure that the appropriate rules and the logging (SMF) data sets protect the eTrust CA-ACF2 control data sets and their alternate and backup data sets.

One tool to help check that sensitive and critical data sets are appropriately protected is the ACFRPTXR (Cross-Reference) report. Given a specific data set name, list of data set names, or resource name, this utility identifies each and every user who has access to that data set or resource or has the authority to change the rules. Additionally, the Logonid Access Report (ACFRPTRX) provides this information in logonid order, and matches users with data set and resource rules.

In addition to the rules themselves, you should review a number of system options and user logonid record fields since they can impact the way the system is running. These related elements are the CENTRAL, CHANGE, and DECOMP fields of the GSO RULEOPTS record, the MODE field of the GSO OPTS record (see the logonid record fields NO-STORE, NON-CNCL, PREFIX, READALL, SCPLIST, and SECURITY in “System Access Control” chapter.)

You can decompile or display a rule set online through TSO or eTrust CA-ACF2 ISPF panels (DECOMP subcommand of ACF) or in batch (ACFBDCMP batch decompiler or DECOMP command through batch TMP. See the “ACF Command in Batch” appendix or the Reports and Utilities Guide for details.). This output indicates who last changed and stored this rule set, when that was done, and the percentage of available space used.


Production Jobs

eTrust CA-ACF2 displays the decompiled output the way it checks the rules. This is always “from most specific to most general” unless the $NOSORT control statement is specified and is active (GSO RULEOPTS record $NOSORT field). $NOSORT indicates that eTrust CA-ACF2 does no sorting of the rule set. You can also use the ACF TEST subcommand to test rule interpretations. This is particularly useful for large or complicated rule sets to test that the rules are operating as designed and that accesses are authorized or prevented under varying circumstances.

In some cases, you must review the past versions of rules (and who changed them and when). You can use batch utilities and report generators provided with the eTrust CA-ACF2 package. See the Reports and Utilities Guide, specifically the ACFRPTIX (Data Set Index) report and the ACFRPTXR (Cross-Reference) report. Finally, when you review rules, be aware of any local exit code on the system that can affect rule selection, interpretation, or effectiveness. (See Use of Local Exits in “Scope of eTrust CA-ACF2”. See “Rule Writing Examples” for examples of rule writing techniques and additional hints on what to look for when you review or audit access rules.

Production Jobs Controlling production jobs is a critical factor in establishing a thorough system of security. Production jobs are very powerful and require powerful logonids to ensure proper control. They should be run under production logonids that are easily and clearly distinguished from user logonids.

Ensure that the following recommendations for protecting production jobs are entered:

■ Restrict access to production data files to production programs. Test programs should access only test files. You should log all programmer accesses. Log any non-production access of production data and periodically audit them to determine if proper access controls are maintained.

■ Restrict changes to production program libraries. Allow only individuals or groups of individuals assigned the task of system libraries to alter these libraries.

■ Control changes to production JCL, cataloged procedures, and the JCL for jobs submitted by production job streams. Production JCL should come only from a highly controlled library. Do not store production logonids and passwords with the JCL.

■ Control the use of a production logonid to submit production jobs. eTrust CA-ACF2 must control the submitter, source, and path of submission.


Production Jobs

■ Use access rules to track changes and updates to production libraries. You can monitor them to ensure a controlled environment. Access rules should protect procedure libraries.

■ Limit production data access to production logonids through access rules. You can give support programmers the same privileges, but log the accesses.

■ Restrict production logonids. Restricted logonids do not require a password but are logged on system entry. They cannot be used for online processing. These logonids can contain the name of the program that must submit any JCL with the logonid. The submitting program can be required to come from an APF-authorized library and from an allowable submission source.

You can also use two eTrust CA-ACF2 programs to control the submission of production jobs, ACFSUB and JOBCOPY. For additional information regarding these programs, see the Reports and Utilities Guide.

Job Submission

Consider how and where jobs are submitted. They can enter the system through local or remote statement readers, as started tasks the operator initiated, or from TSO, CICS, or IMS. Once inside the system, jobs can submit other jobs to the internal reader. Every job submitted to the system has a source eTrust CA-ACF2 can identify. Control all aspects of production processing. Check that the following controls exist:

■ Control access to JCL libraries and cataloged procedure libraries to prevent unauthorized additions, changes, or deletions.

■ Permit only a small group of people to set up and submit production jobs.

■ Restrict the submission of production jobs through a specific program stored in a highly controlled library accessible only to authorized personnel.

■ Limit access to production data to production logonids and possibly to specific support programmers. Ensure that all accesses to production data are logged.


Chapter

5 Resource and Program Access Control

This chapter describes how to use eTrust CA-ACF2 to control access to your resources and to special programs.

Resource Controls Resource rules (similar to access rules) control resource access. Resource rule sets consist of control statements, optional comments, and rule entries. Resource rule set syntax is as follows:

■ Control statements are denoted by a dollar sign ($) or a percent sign (%) in column one. The $ control statements must appear before any % control statements or any rule entries.

■ Comments are denoted by an asterisk (*) in column one. You can place comment lines anywhere in a rule set except between continuation lines of a single rule entry. eTrust CA-ACF2 does not preserve comments during rule compilation so that when the rule set is later decompiled, they do not show in the output.

■ Rule entries should start in column two (although they can start in column one if they do not start with a $, %, or *). You can continue them on another line by specifying a dash (-) as the last character on the first line.

Here is a sample rule set followed by descriptions of each of the rule set control statements: $KEY(resourcename) TYPE(typecode) $NORULELNG $NOSORT $USERDATA %CHANGE uid1 uid2 .... uidn * sample comment rule entry #1 - continued rule entry #1 * sample comment rule entry #2 rule entry #3

Resource and Program Access Control 5–1

Resource Controls

For descriptions of these control statements, see The Access Rule Set in “Data Set Access Control.”

$KEY The $KEY control statement in resource rules, unlike in access rules, can be a mask. A mask for a resource rule ID follows the conventions for logonid masking, except that a resource name mask cannot contain a dash (-). It can only contain asterisks. The site must use the GSO RESDIR or GSO INFODIR record to create a directory for those resource rule type codes that use masks in the $KEY field. Any audit or review of the resource rule sets must take these masks into account when determining which rules apply to which resources.

For example, you can specify the use of a directory for type code TAC (TSO account number validations) and use masks in the $KEY of TYPE(TAC) rule sets. If the TSO account numbers followed a naming convention of two alphabetic characters followed by three numerics, some possible $KEY values are AB123, AB***, A*12*, *B***, **123, or **1**. When you review the decompiled rule sets to determine who has the authority to use a given TSO account number under certain conditions, be careful to review the appropriate rule set. In the previous example of $KEY values, the samples listed are in the sequence that eTrust CA-ACF2 checks for a match on the requested account number. eTrust CA-ACF2 still processes the most specific record first and proceeds only until it finds the first match.

Most of the other comments made earlier about access rule sets also apply to resource rule sets. For example, the %CHANGE control statement, the system options CHANGE and DECOMP, and the use of the SECURITY and NO-STORE attributes all affect who can list and change rules.

For examples of some resource rules and some comments on their use and interpretation, see “Rule Writing Examples.”

The format of a resource rule entry is: [UId(uidmask)][SHift(shiftname)][SOurce(sourcemask)] - [Data(data)][SErvice(Read,Add,Update,Delete)] - [UNtil(date)|FOR(days)][ACTIVE(date)][Verify][Allow|Log|Prevent]

The descriptions for these fields are the same as given previously in the “Data Set Access Control” chapter with the exception of the SERVICE(READ,ADD,UPDATE,DELETE) and VERIFY fields.

SERVICE(READ,ADD,UPDATE,DELETE) Specifies the type of resource access associated with the access attempt. You can specify one or more of the access keywords. Possible keywords are:

■ READ—Indicates read-only access.

■ ADD—Indicates access for adding new records to an existing file.

■ UPDATE—Indicates access for modifying existing records.

■ DELETE—Indicates access for deleting records.

5–2 Auditor Guide

Program Controls

VERIFY Requests password validation for any access attempt made under this rule. The subsystem requesting access to a resource is informed of the request for password validation.

Program Controls This section describes a number of options and facilities in eTrust CA-ACF2 that let you set up program controls and privileges. Of course, all program source and load libraries are data sets that eTrust CA-ACF2 access rules protect to help control who can change programs (write authority), who can look at or copy programs (read authority), and who can execute programs (execute-only authority). Carefully segregate programs (including commands) into multiple libraries with users granted only the minimum access authorities needed to do their jobs. Take special care to secure powerful commands and utilities and to protect critical and proprietary software from unauthorized or unnecessary destruction, disclosure (including copying), or modification.

Using Tape Bypass Label Processing

In addition to using access rules for library protection, there are other system and user options that relate to programs. For example, you can specify the authority to use tape bypass label processing (BLP) at the program name level in addition to or instead of granting BLP authority to users. This is done through the GSO BLPPGM record and displayed in SHOW PROGRAMS as a list of program and library names under the heading TAPE BYPASS LABEL PROGRAMS/LIBRARIES. In addition, you can use the GSO OPTS record BLPLOG field to log all uses of BLP, by a program authorized in the GSO BLPPGM record or by a user authorized through the TAPE-BLP or TAPE-LBL attribute in his logonid record. The value active for your site for the BLP parameter is displayed in a SHOW STATE subcommand as TAPE BLP=LOG or TAPE BLP=NOLOG.

Logging Program Accesses

Another option related to programs is the GSO LOGPGM record. The site lists the names of programs it wants eTrust CA-ACF2 to maintain an audit trail for in this record. You can find these program names displayed in the SHOW PROGRAMS subcommand under the title LOGGED PROGRAMS. Suggested candidates for this list might be Superzap under its various names.


Program Controls

Although access rules and other options control the use of these programs, the LOGPGM record does provide a facility to produce audit trails that indicate any data sets accessed by any of these selected programs. This audit trail is edited as the fourth part of the ACFRPTDS report. See “Reports and Audit Trails” in this guide and the Reports and Utilities Guide for more information about eTrust CA-ACF2 audit reports.

Defining Restricted Program Names

The GSO PPGM record lets the site specify a list of program names that only a user who has the PPGM or NON-CNCL logonid attribute or who is an unrestricted security administrator can execute. PPGM provides an audit trail at step initiation. Programs put on this list are displayed in the SHOW PROGRAMS subcommand as RESTRICTED PROGRAM NAMES. Examples of programs that should probably be on this list are IEHDASDR and FDRDSF; they do not use standard open SVCs for data set processing and thus could bypass other eTrust CA-ACF2 controls. If these types of programs are not on this list, review alternate controls in place for these programs (such as putting them in special libraries with very limited access). See PPGM in “Scope of eTrust CA-ACF2.”

Defining Maintenance Logonids, Programs, and Libraries

The GSO MAINT record designates special combinations of users (logonids), program names, and program library names that are authorized to access and process any data set without checking the access rules and without creating any eTrust CA-ACF2 logging records. The specified combinations are listed in the SHOW PROGRAMS subcommand under MAINTENANCE LOGONIDS/PROGRAMS/LIBRARIES. The logonids included in these entries must have the NON-CNCL or the MAINT attribute. Because no rules are enforced for these combinations and no logging records or audit trails are created, keep the authorized combinations on this list to the minimum necessary to allow for reasonable operations (for example, standard archiving and disk compression utilities a lead operator or shift supervisor runs).

Additional information describing the different uses of the GSO MAINT, PPGM, and LOGPGM records is described in the “Maintaining Global System Options Records” chapter in the Administrator Guide.

5–4 Auditor Guide

Program Controls

Defining Libraries in the System Link List

The GSO LINKLST record defines one or more libraries that eTrust CA-ACF2 considers a logical extension to the system link list. This macro provides added flexibility in terms of eTrust CA-ACF2 program pathing facility. The SHOW LINKLST subcommand displays the GSO LINKLST record specifications. Do not define user libraries in the LINKLST; a large number of entries are similarly suspect.


Chapter

6 Reports and Audit Trails

eTrust CA-ACF2 provides numerous report generators and sample JCL to create various reports for audit trail purposes. Any attempted violation eTrust CA-ACF2 detects appears on a report. In addition, standard reports display each update to any of the three eTrust CA-ACF2 control databases (Logonid, Rule, or Infostorage). Thus, any addition, change, or deletion of any of eTrust CA-ACF2 user or rule control information is visible to a person reviewing these reports. Records produced from these three databases and SMF records provide information presented in the various eTrust CA-ACF2 reports. (Attempts to input concatenated SMF files result in a eTrust CA-ACF2 error message, as only the first file is passed to the report generator.) Last, but not least, numerous other reports are available to record occurrences or produce audit trails of authorized activities. These are of various types. You can produce each type independently of the others. They are explained in the following sections.

Logging Data Set, Volume, or Resource Access Access and resource rules control the production of the logging reports and audit trails of data set or resource access. In all cases, you can specify a rule authorizing an access in one of two ways: ALLOW (permitting access or use and creating no report records), or LOG (granting the access but creating a logging report record). These permissions in rule records create logging records (LOG) or do not (ALLOW), regardless of whether eTrust CA-ACF2 is in LOG, WARN, RULE, or ABORT mode (no records are created in QUIET mode). In other words, an access matching a rule with an ALLOW permission does not create a logging record even in LOG mode.

You can write rules at various levels of detail and specify various conditions. eTrust CA-ACF2 creates logging records for almost any set of circumstances. Rules can readily change (authorized people can modify rules dynamically using eTrust CA-ACF2 TSO commands).

Reports and Audit Trails 6–1

Logging User Access

The following rule set allows all users whose UIDs begin with AB to read and write to the data set PROD.DATASET.NR1. However, those updates (writes) of users with C as the third character of their UIDs are logged. $KEY(PROD) DATASET.NR1 UID(ABC) R(A) W(L) DATASET.NR1 UID(AB) R(A) W(A)

The next rule set allows all users with UIDs beginning with AB to read and write to PROD.DATASET.NR2, but users with ABC have their updates logged for the first 30 days. After 30 days, the first entry expires and disappears from the rule and ABC users are permitted access under the second entry (and the logging of their updates ceases). $KEY(PROD) DATASET.NR2 UID(ABC) FOR(30) R(A) W(L) DATASET.NR2 UID(AB) R(A) W(A)

This third rule set example allows any user whose UID begins with AB to read, write, or allocate PROD.DATASET.NR3 with any program from any library, but if any program other than program name PROD01 from library PROD.LOADLIB is used, eTrust CA-ACF2 logs the access. $KEY(PROD) DATASET.NR3 UID(AB) PGM(PROD01) LIB(LOADLIB) R(A) W(A) A(A) DATASET.NR3 UID(AB) R(L) W(L) A(L)

Logging User Access eTrust CA-ACF2 lets sites who specify LOG versus ALLOW in their rules to log user accesses to specific data sets or resources. It also provides options that allow sites to create a logging record of all activities of a given user, regardless of the rules. You can turn on the TRACE attribute in a user’s logonid record to tell eTrust CA-ACF2 to create a logging record for all data and resource accesses that a user attempts. These print on the reports as trace records.

Under z/OS and OS/390, the logonid record TSO-TRC attribute creates logging records for each TSO command or CLIST the user issued while on TSO. These are printed on a special TSO commands report, sorted by user. When set to YES, a eTrust CA-ACF2 systems option under the GSO OPTS record CMDREC field creates TSO command report records for all TSO users (works the same as turning on TSO-TRC for all users). These options and this report (the TSO Command Log) are available only at z/OS and OS/390 TSO sites.

6–2 Auditor Guide

Combined SMF Records

When the MONITOR attribute is turned on in a logonid record, each time the user enters the system (for example, TSO logon or a batch job submission) eTrust CA-ACF2 sends a message to the security console identifying this activity (this does not create a logging record). This can identify a person in the act of entering the system. eTrust CA-ACF2 also automatically creates logging records each time a logonid with the RESTRICT attribute (that is, no password is required) enters the system. These records are printed on the Restricted Logonid Job Log report.

eTrust CA-ACF2 logs all system accesses a user with the LOGSHIFT privilege makes when outside the dates and times specified in the SHIFT field of the logonid record. These loggings are listed on the Invalid Password/Authority Log produced by ACFRPTPW.

Combined SMF Records In eTrust CA-ACF2, a single System Management Facility (SMF) record is produced for all eTrust CA-ACF2 security loggings. The eTrust CA-ACF2 report generators use the record whose number is specified in the eTrust CA-ACF2 parameter of the @SMF macro. See the “eTrust CA-ACF2 Field Definition Record Generation” appendix in the Getting Started guide for more information.

eTrust CA-ACF2 supports the old record parameters if you have SMF tapes created under a previous release of eTrust CA-ACF2. Those parameters are PSWD, DSN, LID, RULE, JTRACE, COMMAND, INFO, and RSRC. eTrust CA-ACF2 has extended support for these parameters so that auditors can generate reports using pre-Release 4.0 records. The report generators can internally convert the old records into the new form.

eTrust CA-ACF2 Reports The Reports and Utilities Guide contains detailed information about the contents and format of each eTrust CA-ACF2 report (including sample outputs). We also briefly describe each of these reports here to identify what is generally available.


eTrust CA-ACF2 Reports

ACFRPTXR—Cross-Reference Report

This report was created for auditors, security administrators, and management to identify which users could access which data sets and resources. You can obtain historical information (by using backup copies of the eTrust CA-ACF2 data sets taken at a previous point in time) or current status (by using the online databases). Normally, this utility is used to provide a set of data set names (such as critical system and production data sets or all data sets from the master catalog) and resource names as input to the report. The report displays a list of every system user who has any access to each data set and resource specified. The utility identifies users that are granted access through eTrust CA-ACF2 rules, and users who are given access because of other eTrust CA-ACF2 attributes (such as security administrators, matching PREFIX field, or the NON-CNCL logonid privilege.)

ACFRPTIX—Data Set Index Report

This is a special report usually produced by request only and potentially very useful to auditors. This report identifies all changes to the access rules affecting any specified high-level index (or pattern) over any period of time (assuming the input SMF records are available). For example, you can request all changes to the eTrust CA-ACF2 databases that could have affected the access rule for high-level index PAYROLL. You can identify previous versions of the PAYROLL rules, those that were decompiled and displayed, and any changes to logonid records with PREFIX or security administrator privileges that could affect the PAYROLL high-level index.

ACFRPTDS—Data Set/Program Event Log

This report has four parts and includes all data set and volume access requests that were created due to:

■ Logging options such as:

- Rule entries that specify the LOG or WARN mode

- The BLPLOG field turned on in the GSO OPTS record

- Access allowed because the user has the SECURITY or NON-CNCL logonid privilege

■ Trace requests (logonids with TRACE set on)

■ Access violation attempts, where eTrust CA-ACF2 denied the access request and recorded as a violation attempt

■ Accesses allowed but journaled due to some program use logging request (for example, LOGPGM record)

6–4 Auditor Guide


ACFRPTRV—Generalized Resource Event Log

This report is in three parts, similar to the first three mentioned for the ACFRPTDS report, but reports on accesses to resources protected through eTrust CA-ACF2 resource rules.

ACFRPTEL—Information Storage Update Log

This report displays all changes, additions, or deletions that occurred to any entry records, resource rules, or other records in the eTrust CA-ACF2 Infostorage database. This report also includes detailed information (using a before- and after-image format) showing all modifications made to Global System Options (GSO) records.

ACFRPTNV—The Environment Report

This report generator produces a report that notes the use of the following commands: START (S ACF2), STOP (P ACF2), and MODIFY (F ACF2). The report shows the date and the time that each command was used. In addition, this report includes the date and time of each system IPL and highlights possible losses of SMF data.

ACFRPTPW—Invalid Password/Authority Log

This report contains an entry for each attempt to access the system that eTrust CA-ACF2 denied for any reason. The reason for denial is also identified. Some common reasons are invalid password given, logonid not found or found but canceled or suspended, invalid input source or submitting program used, password expired and no new valid password provided, or an invalid OID statement. This report also includes any SHIFT violations related to system access attempts, and all LOGSHIFT loggings.

ACFRPTRX—Logonid Access Report

This report is similar to the Cross-Reference Report produced by ACFRPTXR. This report is sorted by logonid record and matches users with data set and resource rules.



ACFRPTLL—Logonid Modification Log

This report contains an entry for each occurrence of an update to the eTrust CA-ACF2 Logonid database. This includes any change, insert (add a new record), or delete logonid activity. Optionally, you can produce the report in before- and after-image format to enable the auditor to carefully review all logonid record changes.

ACFRPTJL—Restricted Logonid Job Log

This report contains an entry for each time a restricted logonid (with an activated RESTRICT attribute) enters the system.

ACFRPTRL—Rule-ID Modification Log

This report has an entry for each change, addition, or deletion of any access rule record.

ACFRPTSL—Selected Logonid List

This report enables the flexible selection and display of logonid information. Because you can select logonid records for the report with an IF statement with multiple criteria, you can identify almost any combination of users. For example, you can produce reports that list all users who have not changed their passwords in the last 90 days, or who have not accessed the system in the last 30 days, or who have a particular default TSO account number. You can use the IF criteria to determine which logonids have a particular value defined in their multi-value logonid field. You can quickly identify almost any subsection of users.

ACFRPTCR—TSO Command Statistics Log

This report contains a record for each TSO command or CLIST issued during any TSO session by users with TSO-TRC set in their logonid records, or for all TSO users if the CMDREC bit is set in the GSO OPTS record. This applies to z/OS and OS/390 TSO sites only.

ACFRPTST—SAF Trace Report

This report provides output from the SECTRACE command, including RACROUTE parameter lists and environmental information.

6–6 Auditor Guide

Using Reports for Auditing

ACFRPTOM—OpenEdition Report

This report provides OpenEdition system logging.

Other Reports

The eTrust CA-ACF2 report Preprocessor (ACFRPTPP) and the eTrust CA-ACF2 recovery program (ACFRECVR) also generate reports. We provide descriptions of the SMF records eTrust CA-ACF2 produces so that you can write additional report generators.

See the Reporting with Advantage™ CA-Earl® guide for information about producing customized eTrust CA-ACF2 reports.

Using Reports for Auditing In all cases, the records included in a given eTrust CA-ACF2 report can be affected by:

■ The report generator JCL, which has parameter fields that let you specify various options and various selection criteria

■ The actual SMF data sets used as input

■ The authorities of the user who ran the report

■ The SMFPRMxx SYS1.PARMLIB controls specified at IPL time. The SMFPRMxx member controls among other things the specific SMF records that are to be written. The SMFPRMxx member must allow the eTrust CA-ACF2 SMF records (default is type=230, this can be changed in the ACFFDR) to be written.

■ Dynamic modification of SMFPRMxx options by operators using the SETSMF command. Using this command, an operator can knowingly or unknowingly turn off all SMF recording or just SMF recording for a specific record type or range of types.

■ Whether your installation has any SMF exits (IEFU83, IEFU83, IEFU85) that can cause any SMF record not to be written.

■ Installation procedures for saving SMF data.


Report Authorization

In reviewing reports, ensure that you include all proper inputs so that SMF records from some time period or for one of the CPUs are not missing. Also, make sure that the selection parameters do not inappropriately exclude important records, such as records from a certain time period or for certain data set names or logonids. You must also remember that various system options and exits can affect the data that is or is not on the reports. Direct part of the eTrust CA-ACF2 audit to review the normal processing of the eTrust CA-ACF2 reports. Consider the following:

■ If they are produced regularly and include all appropriate records

■ If (and by whom) they are reviewed regularly

■ What actions are taken when attempted violations or abuses are identified

The timely and proper use of the eTrust CA-ACF2 reports is an important aspect of internal controls and should be carefully reviewed. The eTrust CA-ACF2 report generators can also be executed at TSO sites through eTrust CA-ACF2-supplied ISPF panels. eTrust CA-ACF2 provides tutorials for these panels (which also include logonid and rule processing and SHOW subcommands).

Report Authorization Program pathing facilities and the RPTSCOPE option of the GSO OPTS records can limit a user’s authority to view and manipulate certain SMF records. Program pathing controls control access to the data based on the program and program library used to access the data. The RPTSCOPE feature limits the amount of SMF data a user can view on a particular report.

You can limit access to SMF data through program pathing controls by specifying the report utility as the value of the PGM parameter of the SMF data set access rule and specifying the library of the report utility as the LIB parameter of this access rule. If a site does not implement these program-pathed access rules to SMF data or does not specify RPTSCOPE, a user can read and manipulate a broader range of SMF data than might be desirable.

The RPTSCOPE option adds scoping capabilities for reports that use SMF records as input. When RPTSCOPE is set, a user can read only those SMF records for which he is authorized. Different processing takes place for different types of SMF records because each record type contains distinct information.

6–8 Auditor Guide

Report Authorization

For example, if a logonid is running the ACFRPTCR report, eTrust CA-ACF2 checks whether the logonid specifies SECURITY or AUDIT. If one is specified, eTrust CA-ACF2 checks the SCPLIST field to see if the logonid is scoped. If it is not scoped, all SMF data is used in the ACFRPTCR report. If SCPLIST points to a scope record in the Infostorage database, the values for the LID and UID fields of the scope record are matched to the corresponding field values in the SMF records. All those SMF records that contain matching values are used as input to the ACFRPTCR report. All other SMF records are ignored. Each report uses different fields for processing.

The following list includes the privileges and restrictions eTrust CA-ACF2 checks for each utility when it creates a report.

ACFRPTCR SECURITY or AUDIT; LID and UID fields in scope record.

ACFRPTDS SECURITY or AUDIT; DSN field in scope record; owned PREFIX.

ACFRPTEL SECURITY or AUDIT; INF field in scope record; INFOLIST for Infostorage (except resource rules); DECOMP for resource rules; %CHANGE for resource rules.

ACFRPTIX SECURITY, ACCOUNT or AUDIT; UID, LID, and DSN fields of scope record; the user’s logonid or PREFIX; DECOMP; %CHANGE; %RCHANGE for data set rules.

ACFRPTJL SECURITY, ACCOUNT or AUDIT; UID or LID fields in scope record.

ACFRPTLL SECURITY, ACCOUNT or AUDIT; UID or LID fields in scope record; user’s logonid.

ACFRPTNV SECURITY or AUDIT; INF field in scope record; INFOLIST.

ACFRPTRL SECURITY or AUDIT; DSN field in scope record; owned PREFIX; DECOMP; %CHANGE; %RCHANGE.

ACFRPTRV SECURITY or AUDIT; INF field in scope record.


Chapter

7 Migrating to Security

Because your data processing site probably had very little data protected when it installed eTrust CA-ACF2 a sudden conversion to total data protection can be disruptive to the continued smooth functioning of your company. Although each site handles this migration differently, most find the process follows these steps:

Steps 1. Put the eTrust CA-ACF2 system into LOG mode. eTrust CA-ACF2 makes all

the decisions it is supposed to make concerning data set access, except that it does not really deny any of them. The eTrust CA-ACF2 reports show the accesses that it would have denied and the security administrator creates access rules that appropriately reduce the number of violations. During this process or shortly before or afterwards, the security administrator should consult with the data owner to determine whether the accesses are legitimate (that is, should be allowed).

2. Put the eTrust CA-ACF2 system into WARN mode. For every data set access that eTrust CA-ACF2 would have prevented, eTrust CA-ACF2 creates a logging report record and displays a message on the terminal or printed in the job log for batch. With the eTrust CA-ACF2 message, a site-supplied message indicating the date when the access is no longer allowed also displays.

3. Finally, put the eTrust CA-ACF2 system into ABORT mode. This is its normal mode of operation, and accesses eTrust CA-ACF2 rules consider invalid are denied.

You can use RULE mode as an aid in the transition to full security by allowing the phasing-in of protection at the rule set level. If an existing rule would prevent access, RULE mode can provide overrides. Contact your security administrator for additional details about migration plans and status at your site.

Migrating to Security 7–1

Appendix

A ACF Command in Batch

TSO Terminal Monitor Program (TMP) At z/OS and OS/390 sites, use of the TSO Terminal Monitor Program (TMP) in batch requires the creation of job control language (JCL) similar to the following example: //TMP EXEC PGM=IKJEFT01,DYNAMNBR=25 //SYSTSPRT DD SYSOUT=A //SYSTSIN DD * ACF . . any ACF subcommands . . END /*

ACFBATCH Utility The eTrust CA-ACF2 utility ACFBATCH can be used to execute the ACF command in the batch environment. A sample of the required JCL is as follows: //ACFJOB EXEC PGM=ACFBATCH //SYSPRINT DD SYSOUT=A //SYSHELP DD DSN=SYS1.HELP,DISP=SHR //SYSIN DD * . . . any ACF subcommands . . . /*

ACF Command in Batch A–1

Appendix

B Sample SHOW Outputs

Additional SHOW subcommands are described and sample output provided in the Administrator Guide. You can issue all SHOW subcommands in batch or through eTrust CA-ACF2-supplied ISPF panels.

Sample SHOW ACTIVE Output Displays the eTrust CA-ACF2 intercepts that have received control (denoted by YES). Also displayed are any local exits specified in the GSO EXITS record. This record is described in the “Maintaining Global System Options Records” chapter in the Administrator Guide. -- eTrust CA-ACF2 INTERCEPTS THAT HAVE RECEIVED CONTROL -- DASD-OPEN(YES) DASD-EOV(NO) VSAM-OPEN(YES) TAPE-OPEN(NO) TAPE-EOV(NO) CATALOG(NO) USER CALL(NO) EXTERNAL CALL(NO) PROGRAM CALL(YES) JOB/STEP TERM(YES) TSO-MVS(YES) CAT-CVOL(NO) NONVSAM-ERASE(YES) VSAM-ERASE(YES) VTAM-OPEN(YES) -- LOCAL EXITS SPECIFIED ON THIS SYSTEM -- DSN PRE-VALIDATE=NONE DSN POST-VALIDATE=NONE DSN VIOLATION=NONE PSEUDO DSN GENERATE=NONE RSRC PRE-VALIDATE=NONE RSRC POST-VALIDATE=NONE STC VALIDATE=NONE SOURCE MODIFICATION=NONE LOGON PRE-VALIDATE=NONE LOGON POST-VALIDATE=NONE PASSWORD EXPIRATION=NONE NEW PSWD VALIDATE=NONE RULE PRE-PROCESS=NONE RULE POST-PROCESS=NONE INFO PRE-PROCESS=NONE INFO POST-PROCESS=NONE SVC INITIALIZATION=NONE TSO LOGON TERM TYPE=NONE TSO LOGON PARM=NONE DDB LID NODE LOC=NONE DDB USER INFO MOD=NONE LID PRE-PROCESS=NONE LID POST-PROCESS=NONE SEV PRE-PROCESS=VACFSEVP (INACTIVE) SEV POST-PROCESS=NONE CPF EXIT=NONE DYNAMIC PASSWORD=NONE HFS SECURITY EXIT=NONE -- ACF2 DDB FACILITY -- DDB = INACTIVE -- ACF2 CACHE FACILITY -- DATABASE CACHE = INACTIVE CACHE SYNCHRONIZER = INACTIVE -- ACF2 CPF FACILITY -- CPF STATUS = INACTIVE

Sample SHOW Outputs B–1

Sample SHOW APPLDEF Output

-- ACF2 SYSPLEX FACILITY -- XES STATUS = INACTIVE XCF STATUS = INACTIVE -- ACF2 LDS FACILITY -- LDS STATUS = ACTIVE -- AUTHENTICATION EXITS ON THIS SYSTEM: LIDFLD / PROCESS PROGRAM / INFOSTG -- NONE

Sample SHOW APPLDEF Output Displays all active site-defined structured infostorage applications. ACF show appldef -- INSTALLATION DEFINED STRUCTURE INFO-STORAGE APPLICATIONS -- CLASS (SHORT / LONG): I / IDENTITY TYPE (SHORT / LONG): AUT / AUTHSUP SELECTION AUTHORIZATION: SECURITY, ACCOUNT, AUDIT, CONSULT, LEADER DEFAULT DIVISION ROUTINE: ACF00DFT ACTIVE DIVISION: AUTHSUP3 ASSOCIATED RSB / RECORD ID: ACF2RSB1 / ******** CLASS (SHORT / LONG): I / IDENTITY TYPE (SHORT / LONG): AUT / AUTHSUP SELECTION AUTHORIZATION: SECURITY, ACCOUNT DEFAULT DIVISION ROUTINE: ACF00DFT ACTIVE DIVISION: AUTHSUP5 ASSOCIATED RSB / RECORD ID: ACF2RSB2 / ******** CLASS (SHORT / LONG): C / CONTROL TYPE (SHORT / LONG): SMS / SMS SELECTION AUTHORIZATION: SECURITY, ACCOUNT ASSOCIATED RSB / RECORD ID: ACFDRSMS / ********

B–2 Auditor Guide

Sample SHOW CLASMAP Output

Sample SHOW CLASMAP Output Displays the internal (eTrust CA-ACF2-defined) and external (site-defined) CLASMAP records. CONTROL show clasmap -- INTERNAL CLASMAP DEFINITIONS -- MUSASS RESOURCE TYPE ENTITY ID CLASS CODE LENGTH PROFINT LOG MIXED ======= ======== === ====== ======= === ===== CICS FILE CFC 8 CICS PROGRAM CPC 8 CICS TRANS CKC 4 CICS TRANDATA CTD 8 CICS TEMPSTRG CTS 8 CICS DL/I CPB 8 - PROGRAM PGM 8 - UNVRPRT UNR 0 - UNVPGM UNP 8 - ACAPPL ACA 0 - ACDIALOG ACD 0 - ACLIST ACL 0 - ACMSG ACM 0 - ACPANEL ACP 0 - ACSQL ACS 0 - VXMBR SAF 39 - WIMS SAF 8 - WRITER SAF 39 -- EXTERNAL CLASMAP DEFINITIONS -- MUSASS RESOURCE TYPE ENTITY ID CLASS CODE LENGTH PROFINT LOG MIXED ======= ======== === ====== ======= === ===== ******* DEVICES DEV 0 ******* FACILITY FAC 0 ******* JESSPOOL SPL 53 YES ******* JWPLX JWP 0 YES YES ******* OPERCMDS OPR 0 CONTROL


Sample SHOW CPF Output

Sample SHOW CPF Output Displays information about the OPTIONS record and the command propagation facility (CPF) network as defined in NODEDEF records. Here is the SHOW CPF display issued from the NYC node: ? sho cpf -- COMMAND PROPAGATION FACILITY -- CURRENT STATUS: INACTIVE CURRENT SYSID: NYC JOURNALLING: YES CURRENT HOME NODE: NYC LOGDAYS: 30 PASSWORD SYNC: YES COMMAND: YES UNDEFINED NODES: NO CMDWAIT: YES DFTCMD: CHI LA NYC TNG1 DFTPSW: CHI LA NYC TNG1 JRNLRECV: NYC.JRNLRECV.CPFJFILE JRNLSEND: NYC.JRNLSEND.CPFJFILE

-- NODE DEFINITIONS -- NODE RECEIVE SEND GATEWAY UNICENTER VM VM VM VM VM VM NAME FROM TO NODE NODE NODE LIDS RULE INFO LACCESS ONE-A-DAY ==== ======== ==== ======= ========= ==== ==== ===== ===== ======== ========= CHI YES YES NO NO NO NO NO NO NO NO LA NO YES NO NO NO NO NO NO NO NO NYC YES YES NO NO NO NO NO NO NO NO TNG1 YES YES NO YES NO NO NO NO NO NO VMSYS1 YES YES NO NO YES YES NO NO YES YES

Sample SHOW DB2 Output Displays information about each DB2 subsystem that has been started since you started eTrust CA-ACF2. This information includes which exits are in use and the mode specified for each type of resource. In this example, you can see that the buffer pool resource (BPL) for the TEST DB2 subsystem is in QUIET mode. See the eTrust CA-ACF2 for DB2 Administrator Guide for more information about these resource types. If you are not using eTrust CA-ACF2 for DB2 or no DB2 subsystems are running, no information is displayed. show db2 PROD EXITS - DB2PRE(EXIT1) DB2POST(EXIT2) PROD MODES - BPL - RULE,ABORT,QUIET DBS - ABORT PLN - LOG STG - QUIET SYS - ABORT TBL - ABORT TSP - LOG TEST EXITS - DB2PRE() DB2POST(EXITS) TEST MODES - BPL - QUIET DBS - LOG PLN - LOG STG - QUIET SYS - ABORT TBL - ABORT TSP - QUIET

B–4 Auditor Guide

Sample SHOW DDSN Output

Sample SHOW DDSN Output Lists the data set names in use for the Rule, Logonid, and Infostorage databases. Also listed are the backup data sets of these databases, if allocated. If a dynamic data set name (DDSN) list was specified or defaulted at eTrust CA-ACF2 startup, any data set names preallocated but different from the name in the DDSN list are flagged with an asterisk and a note. ACF show ddsn -- ACF2 DYNAMIC DATASET NAMES SPECIFIED -- DDSNS PRIMARY DEFAULTED AT STARTUP. DSNS IN USE ARE: RULES= ACFSYS.ALTRULES LOGONIDS= ACFSYS.ALTLIDS INFOSTG= ACFSYS.ALTINFO BACKRULE= NOA NOT ALLOCATED BACKLID= PRE ACFSYS.BKLIDS BACKINFO= NOA NOT ALLOCATED DDSN LISTS DEFINED IN FDR ARE: PRIMARY RULES= ACFSYS.ALTRULES LOGONIDS= ACFSYS.ALTLIDS INFOSTG= ACFSYS.ALTINFO BACKRULE= SYS1.ACF.BKRULES BACKLID= SYS1.ACF.BKLIDS BACKINFO= SYS1.ACF.BKINFO ALT RULES= SYS1.ACF.ALTRULES LOGONIDS= SYS1.ACF.ALTLIDS INFOSTG= SYS1.ACF.ALTINFO BACKRULE= SYS1.ACF.ABKRULES BACKLID= SYS1.ACF.ABKLIDS BACKINFO= SYS1.ACF.ABKINFO


Sample SHOW FIELDS Output

Sample SHOW FIELDS Output Displays all logonid field names that you have the authority to view or modify. If your logonid has any special privileges (SECURITY, ACCOUNT, AUDIT, LEADER, or CONSULT), this display includes the fields you can modify in the logonid records of other users. An asterisk precedes the fields that you can modify, whether in your own logonid record only or in others. show fields -- IDENTIFICATION -- COMPANY IDNUM LEVEL LID *NAME *PASSWORD *PHONE PROJECT SITE UID -- CANCEL/SUSPEND -- *CANCEL CSDATE CSWHO *MON-LOG *MONITOR *SUSPEND *TRACE *TSO-TRC -- PRIVILEGES -- *ACCOUNT *ACTIVE *AUDIT *AUTOALL *AUTODUMP *AUTONOPW *AUTOONLY *BDT *CICS *CONSULT *DG84DIR *DIALBYP *DUMPAUTH *EXPIRE *IMS *JOB *JOBFROM *GRPLOGON *LDEV *LDS *LEADER *LOGSHIFT *MAINT *MUSASS *NO-INH *NO-SMC *NO-STORE *NON-CNCL *NOSPOOL *PGM *PPGM *PROGRAM *READALL *REFRESH *RESTRICT *RULEVLD *SCPLIST *SECURITY *SRF *STC *SUBMIT *SYNCNODE *SYNERR *TAPE-BLP *TAPE-LBL *TSO *USER *VLDVMACT *VM *VMBATCH *VMBATMON *VMSAF *VMXA *VSESRF -- ACCESS -- ACC-CNT ACC-DATE ACC-SRCE ACC-TIME -- PASSWORD -- *MAXDAYS *MINDAYS *PSWD-DAT *PSWD-EXP *PSWD-INV PSWD-SRC PSWD-TIM PSWD-TOD *PSWD-VIO -- TSO -- *ACCTPRIV *ALLCMDS *ATTR2 *CHAR *CMD-LONG *DFT-DEST *DFT-PFX *DFT-SOUT *DFT-SUBC *DFT-SUBH *DFT-SUBM *INTERCOM *JCL *LGN-ACCT *LGN-DEST *LGN-MSG *LGN-PERF *LGN-PROC *LGN-RCVR *LGN-SIZE *LGN-TIME *LGN-UNIT *LINE *MAIL *MODE *MOUNT *MSGID *NOTICES *OPERATOR *PAUSE *PMT-ACCT *PMT-PROC *PROMPT *RECOVER *TSOACCT *TSOCMDS *TSOFSCRN *TSOPERF *TSOPROC *TSORBA *TSORGN *TSOSIZE *TSOTIME *TSOUNIT *VLD-ACCT *VLD-PROC *WTP -- STATISTICS -- *SEC-VIO UPD-TOD -- CICS -- *CICSCL *CICSID *CICSKEY *CICSKEYX *CICSPRI *CICSRSL *IDLE -- IMS -- -- MUSASS -- *MUSDLID *MUSID *MUSOPT *MUSPGM *MUSUPDT -- RESTRICTIONS -- *AUTHSUP3 *AUTHSUP4 *AUTHSUP5 *AUTHSUP6 *AUTHSUP7 *AUTHSUP8 *GROUP *NOTE9 *OID *PREFIX *SHIFT *SOURCE *VMACCT *ZONE -- DFP -- *SMSINFO

B–6 Auditor Guide

Sample SHOW LDS Output

Sample SHOW LDS Output Displays information about the OPTIONS and LDS LDAP records. Note: When issuing the SHOW ALL command, LDAP records do not appear. show lds -- LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL -- CURRENT LDS STATUS: ACTIVE CURRENT LDS JOURNAL STATUS: ACTIVE CURRENT SYSID: CPU1 ACTIVE LDAP RECORD LIST: - LDAP.CPU2 OPTIONS: INSERT NOCHANGE DELETE NOPSWDASIS OBJCLASS: ACF2LID NEXTKEY: CPU2XRF URL: ldap://141.200.199.006:389 USERDSN: acf2lid=%l, host=cpu2, o=cai, c=usa XREF: LID: ATTRIBUTE: NAME Name PASSWORD userPassword PHONE Phone

The SHOW LDS command uses standard eTrust CA-ACF2 masking conventions to specify a range of active LDAP records. The following example shows the results after issuing the SHOW LDS command with a MASKED qualifier value. acf show lds(cpu2-) --LIGHTWEIGHT DIRECTORY ACCESS PROTOCAL— CURRENT LDS STATUS: ACTIVE CURRENT LDS JOURNAL STATUS: ACTIVE CURRENT SYSID: CPU1 ACTIVE LDAP RECORD LIST: - LDAP.CPU2 OPTIONS: INSERT NOCHANGE DELETE NOPSWDASIS OBJCLASS: ACF2LID NEXTKEY: *** NO NEXTKEY DEFINED *** URL: LDAP://141.202.193.2:389 USERDSN: ACF2LID=%L, HOST=CPU2, O=CAI, C=USA XREF: LID: ATTRIBUTE: NAME NAME PASSWORD USERPASSWORD


Sample SHOW MODE Output

The following example shows the results after issuing the SHOW LDS command is displayed when no Control LDS LDAP and Control LDS XREFLDAP records are active and the LDAP facility is not active. acf show lds -- LIGHTWEIGHT DIRECTORY ACCESS PROTOCAL -- CURRENT LDS STATUS: ACTIVE CURRENT LDS JOURNAL STATUS: ACTIVE CURRENT SYSID: CPU1 ACTIVE LDAP RECORD LIST: THERE ARE NO ACTIVE LDAP RECORDS IN THIS SYSTEM

Sample SHOW MODE Output Displays the current setting or mode of the ACF command. It also displays the current targets for ACF subcommands as shown in the following: ACF show mode MODE: ACF SYSID: CPU1 TARGET: CHI NY1 NY2

Sample SHOW NJE Output Displays all NJE records defined to the system and the options specified for each. Providing a node name value limits the display to those NJE records associated with the given node name. Use standard eTrust CA-ACF2 masking conventions to specify a range of node names that you want to display. ACF show nje(chi) -- NJE OPTIONS IN EFFECT -- NODE VALIDATE VALIDATE INHERIT- SEND DEFAULT SYSOUT NAME OR INCOMING OUTGOING ANCE ENCRYPTED LOGONID DEFAULT MASK JOBS JOBS ALLOWED PASSWORD LOGONID (BOTH) (IN) (OUT) (IN) (OUT) (IN) (IN) =================================================================== ******** YES NO YES YES SKKDFT SKKSDFT

B–8 Auditor Guide

Sample SHOW PROGRAMS Output

Sample SHOW PROGRAMS Output Lists the names of programs for which each data set access is logged. ACF show programs -- RESTRICTED PROGRAM NAMES -- DRWD**** FDR*** ICKDSF** IEHD**** IEHINIT* -- MAINTENANCE LOGONIDS/PROGRAMS/LIBRARIES -- MAINTLID MAINTPGM SYS1.LINKLIB MAINTLID MAINTPG1 SYS1.LINKLIB MAINTLID MAINTPG2 SYS1.LINKLIB MAINTLID MAINTPG3 SYS1.LINKLIB MAINTLID MAINTPG4 SYS1.LINKLIB -- NO TAPE BYPASS LABEL PROGRAMS/LIBRARIES – NONE SPECIFIED -- LOGGED PROGRAMS -- AMASPZAP IMASPZAP INCORZAP

If no programs exist under a certain category, SHOW PROGRAMS indicates that no such programs exist. For more information about these program controls, see the descriptions of the PPGM, MAINT, BLPPGM, and LOGPGM records in the “Maintaining Global System Options Records” chapter in the Administrator Guide.

Sample SHOW RESIDENT Output Displays the names of system-resident directories and access rules. ACF show resident -- RESIDENT DIRECTORIES -- CKC, RULES GLOBALLY RESIDENT -- RESIDENT INFOSTORAGE DIRECTORIES -- DPLN, RECORDS LOCALLY RESIDENT DTBL, RECORDS LOCALLY RESIDENT DDBS, RECORDS GLOBALLY RESIDENT DBPL, RECORDS TRANSIENT -- RESIDENT ACCESS RULES -- PAY ABC SYS1


Sample SHOW RSRCTYPE Output

Sample SHOW RSRCTYPE Output Displays the resource types that are defined on your system. ACF show rsrctype -- RESOURCE TYPES DEFINED -- RAB* RALU RCFC RCHG RCKC RCMR RCPC RCTD RCTS RCXD RCXM RDAH RDB2 RDFC RDPN RDSM RDSN RDTB RFAC RIAG RICM RIPS RISF RITR RJOK RJWP RKKK RLBM RLLL RMGM RMTP ROMC ROPR RPDS RPGM RPRO RRCM RRSC RSAF RSAS RSDS RSEG RSFP RSTS RSUR RTER RTGR RTPR RTPV RTP1 RTST RTWC RVLB RVMA RXCD RXDC RXXX RXYZ TOTAL NUMBER OF RESOURCE TYPES DEFINED: 58 -- DB2 RESOURCE TYPES DEFINED -- DBPL DCOL DDBS DPKG DPLN DSTG DSYS DTBL DTSP TOTAL NUMBER OF DB2 RESOURCE TYPES DEFINED: 9 ACF

Sample SHOW RSVWORDS Output Displays the Reserved Word Prefix List. This list defines the words or prefixes that are not allowed in the specification of a password. See the description of the RESWORD record in the “Maintaining Global System Option Records” chapter in the Administrator Guide. show rsvwords -- RESERVED WORD PREFIX LIST – APPL APR ASDF AUG BASIC CADAM DEC DEMO FEB FOCUS GAME IBM JAN JUL JUN LOG MAR MAY NET NEW NOV OCT PASS ROS SEP SIGN SYS TEST TSO VALID VTAM XXX 1234

B–10 Auditor Guide

Sample SHOW SAFDEF Output

Sample SHOW SAFDEF Output Displays the SAFDEF records that are defined on your system. show safdef -- SYSTEM AUTHORIZATION FACILITY DEFINITIONS -- JESPOOLR JOBNAME=******** USERID=******** PROGRAM=HA$PSUBS RB=HA$PSUBS RETCODE=0 SAFDEF=INTERNAL MODE=IGNORE SUBSYS=ACF2 RACROUTE REQUEST=AUTH,REQSTOR=‘RDRSYSDS’,SUBSYS=‘JES2- ‘, RACROCLASS=‘JESSPOOL’ AUTJ2RDR JOBNAME=******** USERID=******** PROGRAM=HA$PSUBS RB=HA$PSABS RETCODE=0 SAFDEF=INTERNAL MODE=IGNORE SUBSYS=MACS RACROUTE REQUEST=AUTH,REQSTOR=‘RDRSYSDS’,SUBSYS=‘JES2- ‘, RACROCLASS=‘JESSPOOL’ J2RDRVYX JOBNAME=******** USERID=******** PROGRAM=HA$PSUBS RB=HA$PSUBS RETCODE=4 SAFDEF=INTERNAL MODE=GLOBAL SUBSYS=ACF2 RACROUTE REQUEST=VERIFYX,REQSTOR=‘RDRVERYX’,SUBSYS=‘JES2- ‘

Sample SHOW STATE Output Displays the eTrust CA-ACF2 system options in effect. ACF show state RUNNING ACF2 REL 6.4 /MVS SP6.0.4; WITH MODE = ABORT USING FDR ASSEMBLY: 14.44 06/23/00 OPTIONS IN EFFECT: TAPE BLP=NOLOG CONTROL=DECENTRALIZED %CHANGE=ALLOWED CPUTIME=LOCAL DATE FORMAT=MM/DD/YY STC DFLT LID=ACFSTCID DEFAULT LID=BATCHDFT JOB CHECK=NO LID WARN DAYS=1 MAX VIO PER JOB=10 STC OPTION=ON TAPE DSN=NO ADS=BYPASS NOSORT=YES NON-VSAM ERASE=NO VSAM ERASE=NO DDB=DISABLED RPTSCOPE=OFF VTAM OPEN=NO DATABASE CACHE=DISABLED RULELONG=DISABLED CPF=ENABLED TEMPDSN=BYPASS DFT PRIM LANG=ENU DFT SECND LANG=ENU CACHE SYNCHRONIZER=DISABLED SYSPLEX=DISABLED SYSPLEX PRIMARY STRUCTURE NAME: N/A SYSPLEX ALTERNATE STRUCTURE NAME: N/A XCF GROUP NAME: TESTXCF TNG MONITOR= OMVS DFT LID=OMVSC OMVS DFT GRP=OMVST XAPPLVLD=NO LDS=ENABLED PASSWORD OPTIONS IN EFFECT: LOGON RETRY COUNT=4 MIN PSWD LENGTH=1 MAX PSWD ATTEMPTS=2 PSWD ALTER=YES PSWD FORCE=YES PSWD HISTORY=NO PSWD-JES=OFF PSWD-LID=NO PSWD NUMERIC=NO PSWD REQUIRED=NO PSWD RESERVE WORD=NO PSWD EXTRACT=NO PSWD WARN DAYS=1 PSWD CMD CHANGE=ALLOW PSWD WARN DAYS=1 PSWD VERIFY=NO REPEAT PAIR CHAR=0 PSWD SPLIT=NO PSWD VOWEL CHAR=ALLOW NEED NUMERIC CHAR=NO NEED ALPHBET CHAR=NO PSWD CHARACTER LIST=NONE


Sample SHOW SYSPLEX Output

UID STRING = COMPANY,SITE,LEVEL,PROJECT,LID,SFPROJ DECOMP AUTHORITY = SECURITY, AUDIT INFO LIST AUTHORITY = SECURITY, AUDIT VOLUME PSEUDO DSN= @VOLSER.VOLUME -- DSNAME PROTECTED VOLUMES -- ****** -- VOLSER PROTECTED VOLUMES -- NONE SPECIFIED -- AUTOMATIC ERASE VOLUMES -- NONE SPECIFIED -- PDS MEMBER-LEVEL PROTECTION: LIBRARY / VOLUME / RESOURCE TYPE –- NONE SPECIFIED

For more information about these options, see the descriptions of the PSWD, OPTS, RESVOLS, RULEOPTS, and SECVOLS records in the “Maintaining Global System Options Records” chapter in the Administrator Guide. Also, see the description of the @UID macro in the “eTrust CA-ACF2 Field Definition Record Generation” appendix in the Getting Started guide.

Sample SHOW SYSPLEX Output Displays information about the current settings for the SYSPLEX feature. It also displays the number of times the eTrust CA-ACF2 has used the XES feature and the number of times messages have been sent or retrieved through XCF. ? SHO SYSPLEX -- SYSPLEX COUPLING FACILITY -- OPTION: SYSPLEX CURRENT XES STATUS: ACTIVE CURRENT XCF STATUS: ACTIVE COUPLING FACILITY DATA: INFOSTORAGE: INACTIVE LOGONIDS: ACTIVE RULES: ACTIVE XCF GROUP NAME: XCFACF MEMBER NAME: ACF2@SYSA PRIMARY STRUCTURE NAME: STRUCT1 ALTERNATE STRUCTURE NAME: N/A CURRENT STRUCTURE SIZE= 512K MAX STRUCTURE SIZE= 3,840K NUMBER OF STRUCTURE ENTRIES= 29 MAX NUMBER OF STRUCTURE ENTRIES= 98 NUMBER OF XES WRITES= 1,844 NUMBER OF XES READS= 3,449 NUMBER OF XES DELETES= 1,203 NUMBER OF XCF MESSAGES SENT= 5 NUMBER OF XCF MESSAGE GETS= 3


Sample SHOW SYSTEMS Output

Sample SHOW SYSTEMS Output Displays various system parameters, such as the eTrust CA-ACF2 SVC numbers and SMF record numbers. ACF show systems -- SYSTEM PARAMETERS IN EFFECT -- SVCS: ALTER SVC=237 VALIDATE SVC=236 SMF RECORD NUMBERS: PASSWORD=220 DATASET VIO=221 LID JOURNAL=222 RULE JOURNAL=223 LID TRACE=224 TSO COMMAND=225 INFO JOURNAL=226 RESOURCE VIO=227 ACF2 COMMON=230 BACKUP: AUTO BACKUP TIME=03.30 CPUID=UCC1 WORK FILE UNIT=VIO PRIMARY SPACE=5 SECONDARY SPACE=5 COMMAND STRING=S REPROALT OTHER: CONSOLE MSGS=ROLL SHR-DASD=SUPPORTED SMF LOGONID STAMP=NO NOTIFY=YES CURRENT SYSID=ABC1 STARTUP SYSID=ABC1 BUILT ACCVT=ABC1

Sample SHOW TNG Output Displays the CA-Common Services nodes on your system. ACF show tng -- TNG NODE DEFINITIONS -- NODE NAME DEBUG IP ADDRESS --------- ----- ---------- New York NO 123.456.789.123 Dallas NO 123.456.789.345 Chicago YES 123.456.789.789


Sample SHOW TSO Output

Sample SHOW TSO Output Displays TSO default options on the system. ACF show tso -- TSO RELATED DEFAULTS ACTIVE -- LOGON ACCOUNT STRING=1 CMD LIST BYPASS CHAR=# CHAR DELETE CHAR=NONE TSO CMD LIST=NONE COMMAND SMF RECORDS=NO LINE DELETE CHAR=NONE LOGON CHECK=NO PERFORMANCE GROUP=NONE TSO LOGON PROC=IKJACCNT QUICK LOGON=YES TSO REGION SIZE=1024 SUBMIT CLASS=NONE SUBMIT HOLD CLASS=NONE SUBMIT MESSAGE CLASS=NONE SESSION TIME=NONE SYSOUT CLASS=A TSO UNITNAME=SYSDA LOGON WAIT TIME=60 FSRETAIN=YES

Sample SHOW UNIXOPT Output The SHOW UNIXOPT command displays UNIX System Services (USS), also known as OpenEdition MVS or OMVS, security-related options in effect as maintained in the UNIXOPTS GSO record. show unixopt -- UNIXOPT OPENEDITION/MVS/UNIX SYSTEM SERVICES (USS) SUMMARY OMVS DEFAULT USER: OMVSC OMVS DEFAULT GROUP: OMVST MAX NUMBER OF OMVS GROUPS: 6 -- AUDIT FLAG STATUS – CHOWN_RESTRICTED: YES DIRACC_ACTIVE: NO DIRSRCH_ACTIVE: NO FSOBJ_ACTIVE: YES IPCOBJ_ACTIVE: YES PROCACT_ACTIVE: YES PROCESS_ACTIVE: YES


Sample SHOW ZEROFLDS Output

Sample SHOW ZEROFLDS Output Displays those fields of the logonid record that cannot be copied by the ACF subcommand INSERT USING (under the LID setting). show zeroflds -- FIELD VALUES WHICH WILL NOT BE COPIED DURING ‘INSERT USING’ PROCESSING -- ACC-CNT ACC-DATE ACC-SRCE ACC-TIME ACCOUNT ACCTPRIV ACF2CICS AUDIT AUTHSUP1 AUTHSUP2 AUTHSUP3 AUTHSUP4 AUTHSUP5 AUTHSUP6 AUTHSUP7 AUTHSUP8 AUTOALL AUTODUMP AUTOONLY BDT CMD-PROP CONSOLE CONSULT DEPT DG84DIR DIALBYP DOCXFER GROUP GRPLOGON HOMENODE IDNUM JOBFROM LEADER LOGSHIFT MAINT MOUNT MUSASS MUSUPDT NAME NO-SMC NON-CNCL NOSPOOL OLDLID OPERATOR PASSWORD PHONE PPGM PRIV-CTL PROJECT PRV-TOD1 PRV-TOD2 PRV-TOD3 PRV-TOD4 PRVPSWD1 PRVPSWD2 PRVPSWD3 PRVPSWD4 PSWD-DAT PSWD-INV PSWD-SRC PSWD-TIM PSWD-TOD PSWD-VIO PSWD-XTR PSWD-XTV READALL REFRESH RSRCVLD RULEVLD SCPLIST SEC-VIO SECURITY SFPROJ SHIFT SRF STARXFER SYNCNODE SYNERR TAPE-BLP TSORBA UPD-TOD VAX VLDVMACT VMACCT VMBATCH VMBATMON VMSAF VSESRF ZONE CONTROL

To alter the fields included on this list, see the description of the @CFDE macro in the “eTrust CA-ACF2 Field Definition Record Generation” appendix in the Getting Started guide.

Note: The actual fields listed and how they are grouped depends on who made the request (the privileges such as SECURITY, AUDIT that the user has), and how each field has been defined at that installation (the ALTER, AUTH, LIST, and GROUP parameters for each field in its ACFFDR @CFDE field description macro). Fields added locally are also displayed, as appropriate.


Appendix

C Rule Writing Examples

Data Set Access Rule Writing Example Many sites make mistakes by writing access rules that are too general. Take the following example of a rule set for the SYS1 data sets: (1) $KEY(SYS1) (2) UADS UID(SYSPRG1) R(A) W(L) A(L) (3) PARMLIB UID(SYSPRG1) R(A) W(L) A(L) (4) PARMLIB UID(SYSPRG*) R(A) (5) MAN* UID(SYSPRG1) R(A) W(L) A(L) (6) MAN* UID(SYSPRG*) R(A) (7) - R(A) E(A)

The site was attempting to:

■ Permit only the lead system programmer (SYSPRG1) to read, write, and allocate the sensitive data sets SYS1.UADS, SYS1.PARMLIB, and SYS1.MANX/MANY

■ Permit only the remaining systems programmers (SYSPRG*) to read SYS1.PARMLIB and SYS1.MANX/MANY, and

■ Permit all other users to read or execute programs out of all the other SYS1 data sets.

This rule, as written, does not provide the level of control desired. This is because line (7) in the rule set says that all access requests not specifically matching an environment described by any prior rule would have the authorizations associated with line (7) apply—that is, grant read and execute authority.

An environment is a description of access conditions as defined by the rule elements DSN, VOL, UID, SOURCE, LIB, PGM, DDN, and UNTIL/FOR/ACTIVE. eTrust CA-ACF2 always checks the environment of the actual access attempt against all elements specified in a given rule, until it finds a set of conditions that completely match. At that point, the authorization cited in the matching rule entry is the one eTrust CA-ACF2 enforces (for example, read/write/allocate/execute only, allow/allow-but-log/prevent). Each access request is ultimately governed by only one rule, the first one that matches the environment.

Rule Writing Examples C–1

Data Set Access Rule Writing Example

In this example rule set, any user is permitted to read SYS1.UADS. This is because accesses by user SYSPRG1 match the environment created by the rule in line (2) and are permitted. Meanwhile, accesses by other users skip over the rule in (2) because the UID string does not match the UID pattern SYSPRG1. They also skip over the entries in lines (3) through (6), because the DSN does not match. Users would ultimately match and be governed by the entry on line (7), which permits any UID to read any SYS1 data set.

If line (7) had not been added to this rule set, then only the users (systems programmers) specified in the line entries (2) through (6) have access authority to any SYS1 data sets. Remember that eTrust CA-ACF2 default protection ensures that any access not specifically permitted by a rule is prevented. But liberal use of the dash (-) general rule entry can inappropriately negate default protection, such as in this example.

The addition of just three more rule entries to the previous example would restrict users other than those authorized in lines (2) through (6) from accessing the cited special data sets. The three additional lines would be: (2a) UADS (4a) PARMLIB (6a) MAN*

Note: Because the eTrust CA-ACF2 defaults are R(P), W(P), A(P), E(P), they do not have to be explicitly entered on these lines. Also, the actual placement of these rule entries in the existing rule record is not important, as eTrust CA-ACF2 resequences all entries as necessary for its checking. The new lines (2a), (4a), and (6a) prevent users not specifically authorized in lines (2) through (6) from accessing SYS1.UADS, SYS1.PARMLIB, or SYS1.MAN* data sets. Line (7), then permits all users read and execute access only to other SYS1 data sets.

Obviously, extreme care must be taken when adding a broad, generalized rule entry such as the one in line (7). One way to avoid trouble is for the rule writer to always enter the corresponding “negative” rule at the same time as the “positive” rule whenever he is trying to limit access to data sets in a rule record with a general access entry like line (7) present (or at the time he is adding the general access entry if there was not one earlier).

For example, as a rule entry like line (2) is added, also add one like line (2a). Of course, as long as you do not give blanket authorizations by writing rule entries like line (7), these additional “negative” rule entries are not necessary (again, eTrust CA-ACF2 “prevent” defaults would remain active). When reviewing existing rules you want to be particularly watchful for the inappropriate use of overly generalized rules.

C–2 Auditor Guide

Resource Rule Writing Example

Resource Rule Writing Example Resource rules are similar to access rules but do not have as many variables. Also, because there are no levels of permission values (that is, READ, WRITE, ALLOC, EXEC), only the specific choices of ALLOW, LOG, or PREVENT are necessary; however, the SERVICE keyword can be added to more specifically limit the access defined by the resource rule. The %CHANGE and $USERDATA fields are still available at the rule set level, and UID, UNTIL/FOR, SOURCE, and DATA are still available at the individual rule entry level. When the keyword VERIFY is used in a resource rule, the user must reverify his identity by entering the correct password before eTrust CA-ACF2 permits the transaction to proceed. One other important difference in resource rules is that masks (resource name patterns) can be used in the $KEY field as long as the related TYPE directory is also built.

The following example shows a number of resource rule sets for type code ITR (IMS transactions). Because masks are used in the $KEY field, a directory must be built by eTrust CA-ACF2 for type code ITR rules. For the example, the following IMS transaction naming conventions are assumed:

■ APIxxx—Accounts Payable Inquiry transactions

■ APUxxx—Accounts Payable Update transactions

■ ARIxxx—Accounts Receivable Inquiry transactions

■ ARUxxx—Accounts Receivable Update transactions

■ ARU123—A particular Accounts Receivable update transaction

■ AxIxxx—Other accounting department inquiries

The following UID naming conventions are assumed:

■ APSxxxxx—Accounts Payable Supervisors

■ APCxxxxx—Accounts Payable Clerks

■ ARSxxxxx—Accounts Receivable Supervisors

■ ARCxxxxx—Accounts Receivable Clerks

■ ACMSTEVE—Accounting Department Manager

■ DBAKAREN—Data Base Administrator

■ SHPxxxxx—Materials Shipping Clerks



And the following source group names are assumed:

■ ACCTSPAY—Accounts Payable Terminal Room

■ ACCTSRCV—Accounts Receivable Terminal Room

■ ACTGDEPT—Combined Group (ACCTSPAY + ACCTSRCV)

■ WAREHSE—Warehouse/Shipping Dock

A possible collection of ITR rule sets for this site might be: (1) $KEY(API***) TYPE(ITR) *ALLOW DBA OR ACCTG DEPT MGR TO CHANGE RULE %CHANGE ACMSTEVE DBAKAREN *ALLOW AP SUPR TO DO AP INQUIRIES ANYWHERE (a) UID(APS) ALLOW *ALLOW AP PERSONNEL TO DO AP INQUIRIES *FROM AP TERMINALS (b) UID(AP) SOURCE(ACCTSPAY) ALLOW (2) $KEY(APU***) TYPE(ITR) *ALLOW ANY ACCTG DEPT MGR TO CHANGE RULE %CHANGE ACM***** *ALLOW AP SUPR TO DO UPDATES ANYWHERE IN *ACCTG DEPT, BUT LOG IF OUTSIDE OF ACCTS PAY *AND VERIFY PASSWORD AND LOG IF OUTSIDE OF ACCTG DEPT (a) UID(APS) SOURCE(ACCTSPAY) ALLOW (b) UID(APS) SOURCE(ACTGDEPT) LOG (c) UID(APS) VERIFY LOG *ALLOW AP PERSONNEL TO DO UPDATES *FROM AP TERMINALS (d) UID(AP) SOURCE(ACCTSPAY) ALLOW (3) $KEY(ARI***) TYPE(ITR) *ALLOW AR SUPR TO DO INQUIRIES ANYWHERE (a) UID(ARS) ALLOW *ALLOW AR PERSONNEL TO DO AR INQUIRIES *FROM AR TERMINALS (b) UID(AR) SOURCE(ACCTSRCV) ALLOW *ALLOW SHIPPING CLERKS TO DO AR INQUIRIES *FROM WAREHOUSE, BUT LOG (c) UID(SHP) SOURCE(WAREHSE) LOG (4) $KEY(ARU123) TYPE(ITR) *ALLOW AR CLERKS TO DO FROM AR *TERMINALS, BUT REVERIFY PASSWORD (a) UID(ARC) SOURCE(ACCTRCV) VERIFY ALLOW *ALLOW AR SUPR TO DO FROM ACCTS RECV TERMINALS (b) UID(ARS) SOURCE(ACCTSRCV) ALLOW *ALLOW AR SUPR TO DO FROM *OTHER ACCTG DEPT TERMINALS, BUT REVERIFY *PASSWORD AND LOG (c) UID(ARS) SOURCE(ACTGDEPT) VERIFY LOG (5) $KEY(ARU***) TYPE(ITR) *ALLOW AR PERSONNEL TO DO FROM AR TERMINALS, *BUT LOG THOSE DONE BY NEW CLERK BETTY *FOR FIRST 60 DAYS (a) UID(ARCBETTY) FOR(60) SOURCE(ACCTSRCV) LOG (b) UID(ARC) SOURCE(ACCTSRCV) ALLOW *ALLOW AR SUPR TO DO FROM ANY ACCTG TERM (c) UID(ARS) SOURCE(ACTGDEPT) ALLOW

C–4 Auditor Guide


(6) $KEY(A*I***) TYPE(ITR) *ALLOW ACCTG DEPT MGR AND SUPRS TO DO *FROM ACCTG DEPT TERMINALS (a) UID(ACM) SOURCE(ACTGDEPT) ALLOW (b) UID(A*S) SOURCE(ACTGDEPT) ALLOW

In the previous examples, the rule sets and the individual rule entries in each set are ordered in the sequence eTrust CA-ACF2 orders them. However, the comment statements are not carried through a compilation and are not stored in the eTrust CA-ACF2 databases. When writing rules, ensure that the checking sequence desired is the one that is used by eTrust CA-ACF2. You can do this by examining output from the decompiler with the DECOMP subcommand.

When patterns are used in the $KEY field, rule sets are ordered by a direct alphanumeric sort on the $KEY values, with an asterisk (*) in any position placed last. For the previous six rule sets, because they all have “A” as their first character, the APxxxx rules are first (API before APU), the AR rules are next (ARI*** then ARU123 before ARU***), and A*I*** is last.

In a resource rule set, the rule entries are sorted by UID first, then SOURCE, then SHIFT, then date (UNTIL/FOR, with the earliest expiration date first).

UID patterns are sorted the same as $KEY patterns, so entry (a) in rule (1) with the more specific UID(APS) sorts before entry (b) with its more general UID(AP). UID(AP) equates to UID(AP******) as eTrust CA-ACF2 automatically pads out the rest of any rule UID value with asterisks. (1) $KEY(API***) TYPE(ITR) *ALLOW DBA OR ACCTG DEPT MGR TO CHANGE RULE %CHANGE ACMSTEVE DBAKAREN *ALLOW AP SUPR TO DO AP INQUIRIES ANYWHERE (a) UID(APS) ALLOW *ALLOW AP PERSONNEL TO DO AP INQUIRIES *FROM AP TERMINALS (b) UID(AP) SOURCE(ACCTSPAY) ALLOW

In rule set (2), entries (a), (b), and (c) have identical UID values, so these lines are sorted by the SOURCE field. No SOURCE is always more general than any specific SOURCE value, so entry (c) is last. SOURCE field values are sorted alphanumerically, so entry (a) with SOURCE(ACCTSPAY) sorts before entry (b) with SOURCE(ACTGDEPT). (2) $KEY(APU***) TYPE(ITR) *ALLOW ANY ACCTG DEPT MGR TO CHANGE RULE %CHANGE ACM***** *ALLOW AP SUPR TO DO UPDATES ANYWHERE IN *ACCTG DEPT, BUT LOG IF OUTSIDE OF ACCTS PAY *AND VERIFY PASSWORD AND LOG IF OUTSIDE OF ACCTG DEPT (a) UID(APS) SOURCE(ACCTSPAY) ALLOW (b) UID(APS) SOURCE(ACTGDEPT) LOG (c) UID(APS) VERIFY LOG *ALLOW AP PERSONNEL TO DO UPDATES *FROM AP TERMINALS (d) UID(AP) SOURCE(ACCTSPAY) ALLOW


General Rule Writing Comments

Take special care when you assign input source names and source group names so that the more specific groupings have “earlier” names than the more general or combined group names. For example, if the larger combined group for the accounting department is named ACCTDPET instead of ACTGDEPT, it always sorts before ACCTSPAY and ACCTSRCV, which are subsets of the larger group.

In rules where both levels of source names are to be used (like in rule set (2) above), the wrong results could occur; if entry (b) had SOURCE(ACCTDEPT), it would sort ahead of entry (a). In that case any use of resource APU*** which should match the (a) entry would first match the (b) entry (allowed but logged) and would never check entry (a). (eTrust CA-ACF2 always applies the permission of the first rule entry that matches the environment of the request and stops checking there.)

Shift names specified in the SHIFT field are sorted the same way as source names in the SOURCE field (alphanumerically) and cannot be a mask.

General Rule Writing Comments The previous comments on the sorting of UID, SOURCE, and date fields apply to access rules and resource rules. The full sequence used in access rules is DSN value first, then VOL, UID, LIB, PGM, DDN, SOURCE, SHIFT, and date (UNTIL/FOR), in that order. Output from the rule decompiler is listed in the eTrust CA-ACF2 checking sequence unless $NOSORT is specified in the rule set.

Whenever you are in doubt as to how a specific rule is interpreted by eTrust CA-ACF2, you can use the ACF TEST subcommand to test different possibilities. You can test a rule before you store a rule change and make it effective. You can also use the TEST subcommand to test an existing rule.

C–6 Auditor Guide

Appendix

D Sample eTrust CA-ACF2 Audit Survey Questions

The following list of survey questions is provided here as a sample of items that an internal EDP auditor might examine during the eTrust CA-ACF2 portion of his audit. It is not intended to be a complete list or to represent the correct approach for any given site. This list is provided here to show examples of how a hypothetical eTrust CA-ACF2 site’s policies might be translated into audit items. The sample assumes that this is a z/OS and OS/390 site with TSO available. If items similar to these were included in a site’s audit plan, the auditor would review each item and conclude whether that activity was satisfactory, unsatisfactory, or in progress, or that the item did not apply at that time. Other tests and audit work papers would also be completed, reviewed, and signed off.

We would like to take this opportunity to thank the General Motors Corporation and their corporate audit staff for their assistance and comments during the preparation of this document.

Before you begin your survey:

1. Obtain a TSO terminal and a logonid with the AUDIT privilege.

2. Determine the names of the eTrust CA-ACF2 system files and obtain read-access to the SYS1 prefix files.

3. Ask for SYSOUT listings of the eTrust CA-ACF2 Field Definition Record (ACFFDR) and TSO command list generations.

Components of eTrust CA-ACF2 1. Determine if each of the VSAM clusters for eTrust CA-ACF2 is uniquely

named and is of adequate size. Use the TSO LISTCAT command to list the data and index components of VSAM clusters SYS1.ACF.RULES, SYS1.ACF.LOGONIDS, and SYS1.ACF.INFOSTG.

2. Repeat the previous test using the three alternate clusters: SYS1.ACF.ALTLIDS, SYS1.ACF.ALTRULES, and SYS1.ACF.ALTINFO.

3. Use the DECOMP command or the ACFRPTXR report to check the rules for the eTrust CA-ACF2 system files. Verify that the rules permit only unscoped security administrators to access the primary eTrust CA-ACF2 files, and that they do not permit write access.

Sample eTrust CA-ACF2 Audit Survey Questions D–1

Other Products

4. Examine the CAI rule set to determine that the eTrust CA-ACF2 distribution libraries can be accessed only by the system programmer assigned to eTrust CA-ACF2 support.

5. Examine the SYS1 rule set to determine if the three non-VSAM eTrust CA-ACF2 backup data sets (SYS1.ACF.BKLIDS, SYS1.ACF.BKRULES, and SYS1.ACF.BKINFO) are accessible only to eTrust CA-ACF2 and the ACFRECVR recovery job (which should be controlled by Operations).

6. Determine that the libraries that contain eTrust CA-ACF2 load modules, such as CAI.CAILIB and CAI.CAILPA, are adequately protected. Write and allocate permission should be logged and restricted to key systems programmers only.

7. Examine the eTrust CA-ACF2 command limiting load modules, such as ACF$CMDO, in CAI.CAILIB. Use AMBLIST or SPF Hex Browse to examine the patch area and verify that no new commands have been added to the list after assembly.

8. Determine that eTrust CA-ACF2 PTFs and other maintenance is performed with Systems Modification Program Extended (SMP/E) and that all eTrust CA-ACF2 maintenance is carefully reviewed.

9. Verify that the eTrust CA-ACF2 distribution and maintenance tapes are designated as critical and are protected with adequate physical security.

Other Products 1. If eTrust CA-ACF2 is being used for TSO command limiting, examine the

$CMDS assembly for the $TSOCMD macro to determine that the appropriate commands are limited.

2. Use the ACF SHOW PROGRAMS subcommand to determine that maintenance programs (that is, those that bypass security checking) are specified as usable only out of a controlled library by a specific logonid.

ACFFDR and GSO Options 1. Examine the eTrust CA-ACF2 Field Definition Record (ACFFDR) and GSO

records. Compare the options selected there with those shown to be in actual use by various ACF commands such as SHOW STATE, SHOW TSO, SHOW ZEROFLDS, SHOW SYSTEMS, and SHOW FIELDS. Note and investigate any discrepancies.

2. Use the SHOW STATE subcommand to verify that started tasks are controlled by eTrust CA-ACF2, that is, STC=ON.

D–2 Auditor Guide

ACFFDR and GSO Options

3. Use the SHOW STATE subcommand to verify that access to tape data sets is controlled by , that is, TAPEDSN and TAPEBLP in the GSO OPTS record.

4. Use the SHOW STATE subcommand to determine that all disk data set names are protected by eTrust CA-ACF2, that is, specified as ******.

5. Use the SHOW ACTIVE subcommand to determine which of the following user exits the unit uses. Request and examine the source code for each. Cross-reference compile data and load module size with CAI.CAILIB contents. Note any discrepancies.

DSNGEN LIDLOC RULEPST

DSNPOST LIDMOD SEVPRE

EXPPXIT LIDPRE SEVPOST

INFOPRE LIDPOST SRCXITT

INFOPST NEWPXIT STCXIT

LGNIXIT PGMOVRD SVCIXIT

LGNPARMS RSCXIT1 VIOEXIT

LGNPXIT RSCXIT2 VLDEXIT

LGNTERM RULEPRE

6. Determine that eTrust CA-ACF2 exit use is well documented as to its purpose and its effect on the system.

7. Use the SHOW ACTIVE subcommand to verify that the eTrust CA-ACF2 -required SMF exit modules receive control. Verify that JOB INIT(YES), PROGRAM CALL(YES), and JOB/STEP TERM(YES) appear.

8. Use the SHOW STATE subcommand to check the appropriate GSO option to determine if passwords are adequately controlled by eTrust CA-ACF2. For example, MINPSWD(5) to enforce that all logonid passwords have a minimum of five characters.

9. Carefully examine the ACFFDR, comparing the @CFDE entries to the eTrust CA-ACF2-supplied defaults. Determine that any local modifications do not materially weaken security or control.

10. Examine @UID in the ACFFDR to determine which fields make up the site’s UID concatenation. Verify that only authorized security or account personnel can change the pertinent fields in the logonid, never by users themselves.


Logonid Records

Logonid Records 1. Use the LIST subcommand or the Selected Logonid List (ACFRPTSL) report

generator to display a sample of logonid records. Verify that the password expiration parameter, MAXDAYS, of the password group is used and is no greater than 30.

2. Use the LIST IF subcommand or the ACFRPTSL report to determine who has the SECURITY or ACCOUNT privilege. These powers should be restricted to two or three persons, or else limited by the person’s scope if the unit uses decentralized administration. Systems programmers should never have attribute.

3. Use the LIST IF subcommand or the ACFRPTSL report to determine which logonids have the NON-CNCL attribute. No more than three or four such logonids should be found, and these should be for emergency use or for special purposes (for example, started task IDs) only. In addition, their usage should be reviewed.

4. Use the LIST IF subcommand or the ACFRPTSL report to determine which logonids have the RESTRICT attribute. Verify that these logonids have SUBAUTH specified, as well as the PGM and LIB parameters, to ensure that their usage is by an APF-authorized program from a controlled library.

5. Use the LIST IF subcommand or the ACFRPTSL report to examine all logonid records to determine that no user has a SYS1 prefix, as this permits complete access to all system files. Similarly, determine that no user has all asterisks specified.

6. Use the LIST IF subcommand or the ACFRPTSL report to examine all logonid records to determine which users have the REFRESH attribute. These users are permitted to dynamically activate GSO options.

7. Use the LIST IF subcommand or the ACFRPTSL report to examine all logonid records to determine which users have the MAINT attribute. These users are permitted to execute any program defined in the GSO MAINT record.

8. Use the LIST IF subcommand or the ACFRPTSL report to determine which logonids are assigned a particular value of a multi-value logonid field.

D–4 Auditor Guide

Rule Records

Rule Records 1. Use the DECOMP subcommand to decompile the SYS1 rule set. Determine

that any %CHANGE or %RCHANGE statements to permit rule modification are appropriate and justified.

2. Determine that System Management Facility (SMF) files (for example, SYS1.MANX and SYS1.MANY) which eTrust CA-ACF2 uses for logging are adequately protected. Write permission should never be given for these SMF files. Allocate permission should be logged and restricted to the systems programmer responsible for SYSGENs.

3. Check the GSO OPTS record NOSORT field. If NOSORT is in effect, verify that all rule sets containing a $NOSORT control statement accurately reflect access permissions. If NONOSORT is in effect, there should not be any $NOSORT entries.

eTrust CA-ACF2 Reports 1. eTrust CA-ACF2 offers a comprehensive set of violation and logging reports.

Determine that security personnel review such reports regularly and actively follow up on potential problems.

2. Examine the cross-reference reports (ACFRPTXR and ACFRPTRX). Determine if eTrust CA-ACF2 rules grant access according to the “need to know” doctrine. Is the authority to change rules adequately controlled?


Index

$ @

$DEXITS console operator command, 2-14 @IMS macro, 2-9

$KEY @UID macro, 4-1 access rule, 4-3 @volser.VOLUME, tape volumes, 2-7 resource rule, 5-2

$MODE, access rule, 4-3

A $NOSORT access rule, 4-3, 4-9 access rule sorting, 2-4, 4-7, 4-9

ABORT mode resource rule, 5-1 definition, 7-1

$OWNER, access rule, 4-4 maximum protection, 2-3

$PREFIX. See also NEXTKEY Access permissions, 4-1 access rule, 4-4

Access rules $RESOWNER, access rule, 4-4 access rule sorting, 4-7

ACF command, 4-7 $TSOCMD macro, D-2 compilation authority, 3-7

$USERDATA control statements, 4-3 access rule, 4-4 decompile or display, 4-9 resource rule, 5-1 definition, 4-3

displaying system-resident, B-8 examples, C-1 general comments, C-6 % keywords, 4-4 logging accesses, 6-1 protecting data sets, 4-1 %CHANGE review process, 4-8 access rule, 3-8, 4-4 reviewing sensitive data sets, 4-8 resource rule, 3-8, 5-2 rule entries, 4-4

%RCHANGE, access rule, 3-9, 4-4 sample rule set, 4-3

ACCOUNT field, logonid record, 3-3, 3-10

Index–1

Account manager, 3-3 ACMCB, changing the address of, 2-16

ACF command ACTIVE rule entry, 4-6 batching, 2-2, A-1 ACUCB, changing the address of, 2-16 displaying CA-ACF2 control options, 2-2 displaying current mode, B-7 Algorithmic methodology, 1-2 SHOW subcommand, displaying control options, 2-2 ALLOCATE access permission, 4-7

ALLOW access privilege, 6-2 ACF TEST subcommand, C-6 ALTER operand, @CFDE macro, 3-5 ACF$CMDO, D-2 Alternate clusters, D-1 ACFBATCH utility, 2-2, A-1 Attributes ACFFDR

ACCOUNT, 3-3 @CFDE macro, B-14 CONSULT, 3-4 @UID macro, 4-1 LEADER, 3-4 defining macros, 2-2 SECURITY, 3-2 defining system options, 2-1 SECURITY and AUDIT, 3-3 reviewing @CFDE settings, 3-4

reviewing settings, D-2 AUDIT field, logonid record, 3-4, 3-10

ACFM transaction, 2-11 Audit trails general information, 6-1 ACFRPTCR report generator, 6-6 sample survey, D-1

ACFRPTDS report generator, 6-4 Auditors

ACFRPTEL report generator, 6-5 ACF command in batch, A-1 CA-ACF2 components, 1-2 ACFRPTIX report generator, 4-9, 6-4 CA-ACF2 reports, 6-3

ACFRPTJL report generator, 6-6 data set access control, 4-1 displaying system options, 2-2 ACFRPTLL report generator, 6-6 logging reports, 6-1 migrating to security, 7-1 ACFRPTNV report generator, 6-5 privileges, 3-4

ACFRPTOM report generator, 6-7 report authorization, 6-8 reports, 6-1 ACFRPTPP report generator, 6-7 resource and program access control, 5-1

ACFRPTPW report generator, 6-5 rule writing examples, C-1 sample survey, D-1 ACFRPTRL report generator, 6-6 scope of CA-ACF2, 2-1

ACFRPTRV report generator, 6-5 system access control, 3-1 user access reports, 6-2 ACFRPTRX report generator, 4-9, 6-5 using reports, 6-7

ACFRPTSL report generator AUTH operand, @CFDE macro, 3-5 and scope records, 3-7

reviewing, 6-6 Authorities, DECOMP, 3-8 special users list, 3-11

AUTODUMP field, logonid record, 3-10 ACFRPTST report generator, 6-6

AUTOERAS, 2-5 ACFRPTXR report generator, 4-9, 6-4, D-1

ACFSUB, 4-10

Index–2 Auditor Guide

B Commands $DEXITS, 2-14

Comments Batch processing in access rules, 4-3 ACF command, A-1 in resource rules, 5-1

ACFBDCMP or DECOMP, 4-9 Components of CA-ACF2, reviewing, D-1 IMS interface, 2-10

CONSULT field, logonid record, 3-4, 3-10 BLPLOG GSO OPTS record, 5-3

Control statements BLPPGM GSO OPTS record, 5-3 $NOSORT, 2-4 Bypass Label Processing (BLP), 5-3 access rules, 4-3 resource rules, 5-1

CPF C displaying network information, B-3 viewing nodes and options, 2-3

CA-ACF2 CICS interface, 2-10

D command limiting load modules, D-2 displaying control options, 2-2 displaying intercepts, B-1

DASD protection, 2-6, 2-7 displaying SVC numbers, B-12 IMS Batch interface, 2-10 DATA rule entry, 4-6 IMS interface, 2-8 records, defining system options, 2-1 Data set SAF interface, 2-12 access control, 4-1 scope of controls, 2-1 access rule examples, C-1

DASD protection, 2-6, 2-7 CAI rule set, D-2 listing names, B-4 logging access to, 6-1 CAI.CAILIB library, D-2 postvalidation exit, 2-13 CAI.CAILPA library, D-2 prevalidation exit, 2-13 pseudo data set name generator exit, 2-15 CANCEL field, logonid record, 3-12 tape protection, 2-7

CENTRAL field, GSO RULEOPTS record, 3-8, 4-9 verifying access to tape, D-3 violation exit routine, 2-13 Centralized administration, 3-6

Database Synchronization Component (DSC), viewing nodes and options, 2-3

CHANGE field, GSO RULEOPTS record, 3-9, 4-9

CICS DB2, displaying subsystem information, B-4 interface, 2-10

logonid record field, 3-12 DDNAME rule entry, 4-6 MODE parameter, 2-12

DDSN list, B-4 parameters, 2-11

Decentralized administration, 3-6 CICSKEY, 2-11

DECOMP command, D-1 CLASMAP records, 2-1

DECOMP field, GSO RULEOPTS record, 3-6, 3-8, 4-9 CMD-PROP field, logonid record, 3-10

Decompile authority, 3-6 CMDREC field, GSO OPTS record, 6-2

Default logonid implementation aids, 3-1 Combined SMF Records, 6-3

Design philosophy of CA-ACF2, 1-1 Command propagation facility. See CPF

Index–3

displaying CA-ACF2 control options, 2-2 Directories, displaying system-resident, B-8 EXITS, 2-13 DRWDASDR utility (IBM), security considerations,

2-6 INFODIR, 5-2 LINKLST, 5-5 list of important, 2-3 DSNGEN field, GSO EXIT record, 2-15 LOGPGM, 5-3

dsnmask, rule entry, 4-5 MAINT, 5-4 OPTS record, 3-10 DSNPOST field, GSO EXITS record, 2-13 PPGM, 5-4

Dump core utility, 2-14 RESDIR, 5-2 reviewing, D-2 DUMPAUTH field, logonid record, 3-10 RULEOPTS, 3-6 setting control boundaries, 2-2

E

H Entry records, displaying and changing, 3-9

Environment Report, 6-5 High-level index, 4-1 EXECUTE access permission, 4-7

Exits I displaying local exits, B-1 use and list of, 2-13

IDLE field, logonid record, 3-12 EXITS record, fields, 2-13

IEHDASDR utility (IBM), security considerations, 2-6, 5-4

Expired password exit, 2-13

EXPPXIT field, GSO EXITS record, 2-13 IMS

External (site-defined) records, displaying, B-2 batch interface, 2-10 field, logonid record, 3-12 External environment, control considerations, 2-16 interface, 2-8 structured infostorage records, 2-9

F INFODIR record, 5-2

INFOLIST field, GSO OPTS record, 3-10

FDRDSF program, 5-4 INFOPRE field, GSO EXITS record, 2-14

Field Definition Record, control boundaries, 2-2 INFOPST field, GSO EXITS record, 2-14

FLAGS parameter, @CFDE macro, 3-5 Information Management System, CA-ACF2 interface, 2-8 FOR rule entry, 4-6 Informational message, displayed at logon, 2-4

Infostorage database G postprocessing exit, 2-14

preprocessing exit, 2-14

Global System Options (GSO). See GSO records Infostorage records displaying and changing, 3-9 GROUP field, logonid record, 3-12 displaying defined structured applications, B-2 structured, IMS and RESOURCE, 2-9 GSO records

displaying and changing, 3-9


Interfaces LIDPOST field, GSO EXITS record, 2-14 CICS, 2-10 LIDPRE field, GSO EXITS record, 2-14 IMS, 2-8 SAF, 2-12 LINKLST GSO record, 5-5

Internal (CA-ACF2-defined) records, displaying, B-2 LIST parameter, @CFDE macro, 3-5

Internal controls, ensuring, 2-16 LIST subcommand displaying profile records, 3-2 ISPF displaying scope records, 3-7 decompiling rule sets, 4-9

displaying CA-ACF2 control options, 2-2 LOG access privilege, 6-2 report generators, 6-8

LOG mode, 7-1 SHOW subcommand, 3-11 Logging

reports, 6-1 J user access, 6-2

Logon parameter exit, 2-14 JES local exits, 2-14 postvalidation exit, 2-14 preprompt exit, 2-14 JESx USER01 exits, 2-14 prevalidation exit, 2-14

JOB field, logonid record, 3-12 terminal exit, 2-14 work area (LWA) processing, 2-14 JOBCOPY, 4-10

Logonid database JOBFROM field, logonid record, 3-10 locator exit, 2-14

Jobs modification exit, 2-15 controlling production, 4-10 postprocessing exit, 2-14 submission of, 4-11 preprocessing exit, 2-14

Logonid record critical fields, 3-10 L defaults, 3-1 defining maintenance, 5-4 displaying field names, B-5 LDS displaying noncopy fields, B-14 displaying, LDAP servers and options, B-6 general information, 3-1

LEADER field, logonid record, 3-4, 3-10 multi-value fields, 4-2 NO-STORE field, 3-9 LGNIXIT field, GSO EXITS record, 2-14 reviewing, D-4

LGNPARMS field, GSO EXITS record, 2-14 SCPLIST field, 3-6 sensitive fields, 3-11 LGNPXIT field, GSO EXITS record, 2-14 special privileges, 3-2 TAPE-BLP and TAPE-LBL, 5-3 LGNTERM field, GSO EXITS record, 2-14 unalterable fields, 3-11

Libraries Logonid search sequence modification exit, 2-14 defining in the system link list, 5-5

defining maintenance, 5-4 LOGPGM GSO record, 5-3 protecting, D-2 LOGSHIFT field, logonid record, 3-10, 6-3 LIBRARY rule entry, 4-6

LIDLOC field, GSO EXITS record, 2-14

LIDMOD field, GSO EXITS record, 2-15

Index–5

M NON-CNCL field, logonid record, 3-10, 5-4

NO-SMC field, logonid record, 3-10

NOSORT field, of GSO OPTS record, 2-4 Macros $TSOCMD, D-2 NO-STORE field, logonid record, 3-9, 3-10 @IMS, 2-9

NOTIFY field, of OPTS record, 2-4 MAINT field, logonid record, 3-10 NOVALIDATE parameter, IMS, 2-9 MAINT GSO record, 5-4

Masking access rule, 4-4, 4-5, C-1 O resource rule, C-3 UID string, 4-2

OpenEdition MVS MAXDAYS field, logonid record, 3-12 displaying options, B-13

Migration to security OPTION MODE, CICS, 2-12 general information, 7-1

modes, 7-1 OPTIONS record, displaying information, B-3 MINDAYS field, logonid record, 3-12 Options, selection, 2-3 MODE parameter OPTS record

CICS, 2-12 BLPPGM field, 5-3 GSO OPTS record, 2-3, 2-9 CMDREC field, 6-2 IMS, 2-10 INFOLIST field, 3-10

MODE field, 2-3 Modes NOSORT field, 2-4 CA-ACF2 system, 2-3, 7-1 NOTIFY field, 2-4 displaying current setting, B-7 STC field, 2-4

MONITOR field, logonid record, 3-12, 6-3 TAPEDSN, 2-7 UADS, 2-5 Multi-value fields, 4-2

Other product interfaces, general information, D-2 MUSASS field, logonid record, 3-10

MUSIDINF field, logonid record, 3-10

P MUSUPDT field, logonid record, 3-10

Parameters N IMS, 2-9

Password NAME field, logonid record, 3-12 expired password exit, 2-13

new password exit, 2-15 NAME parameter, IMS, 2-9 Patterns of character strings, C-4 New password exit, 2-15 PGM or PROGRAM rule entry, 4-6 NEWPXIT field, GSO EXITS record, 2-15 PGMOVRD field, GSO EXITS record, 2-15 NEXTKEY, 4-4, 4-6 Physical security, tapes, D-2 NJE records, displaying, B-7 PPGM field, logonid record, 2-6, 3-10, 5-4 NOCHANGE field, GSO RULEOPTS record, 3-9 PPGM GSO record, 5-4 NODEDEF records, displaying information, B-3


PPGM, restricted programs list, 3-3 Resource prevalidation exit, 2-15

PREFIX field, logonid record, 3-10 Resource rules compilation authority, 3-7 Printing devices, identify special, 2-14 control statements, 5-1 definition, 5-1 PRIV-CTL field, logonid record, 3-10 displaying and changing, 3-9

Privileges examples, C-3 LOGSHIFT, 6-3 format, 5-2 separation of function, 3-2 general comments, C-6 system options, 3-4 logging accesses, 6-1

program controls, 5-3 Production jobs, controlling, 4-10 sample rule set, 5-1

PROFILE keyword, 3-2 sets, 5-2 PROGRAM field, logonid record, 3-10 RESOURCE structured infostorage records, 2-9 Program override exit, 2-15 Resource types, displaying, B-8 Program pathing facility, 5-5 Resources

controlling access to, 5-1 Programs defining system options, 2-2 controlling access to, 5-1 logging access to, 6-1 controls, 5-3

defining maintenance, 5-4 RESTRICT field, logonid record, 3-10 defining restricted, 5-4

Restricted displaying data set access log, B-7 programs, 2-6 logging accesses, 5-3 security administrator, 3-3 using the SHOW PROGRAMS subcommand, D-2

RESVOLS, 2-6 PSBs, 2-10

RPTSCOPE field, GSO OPTS records, 6-8 PSBTYPE, 2-10

RSCXIT1 field, GSO EXITS record, 2-15 Pseudo data set name generator exit, 2-15

RSCXIT2 field, GSO EXITS record, 2-15 PSWD-DAT field, logonid record, 3-12

RSRCVLD field, logonid record, 3-10 PSWD-VIO field, logonid record, 3-12

Rule database access privileges, 3-7

R postprocessing exit, 2-15 preprocessing exit, 2-15

Rule entries READ access permission, 4-7 access rules, 4-3

READALL field, logonid record, 3-4, 3-10 resource rules, 5-1, 5-2

REFRESH field, logonid record, 3-10 RULE mode, 2-3, 4-1, 7-1

Report generators Rule sets authorization, 6-7, 6-8 CAI, D-2 general information, 6-1 changing, 3-7 list of, 6-3 reviewing, D-4 reviewing, 6-1, 6-7, D-5 sample access rule, 4-3

sample resource rule, 5-1 RESDIR record, 5-2 SYS1, D-2

Reserved word prefix list, displaying, B-9

Resource postvalidation exit, 2-15

Index–7

RULEOPTS record SEVPRE field, GSO EXITS record, 2-16 reviewing decompile authority, 3-6 SHIFT field, logonid record, 3-12, 6-3 system options, 4-9

Shift records, displaying and changing, 3-9 RULEPRE field, GSO EXITS record, 2-15 SHIFT rule entry, 4-6 RULEPST field, GSO EXITS record, 2-15 SHOW ACF2 subcommand RULEVLD field, logonid record, 3-10, 4-1 verifying ACFFDR and GSO values, 2-2

SHOW ACTIVE subcommand reviewing exits, 2-13 S sample output, B-1

SHOW APPLDEF sample output, B-2 SAF interface

SHOW CLASMAP subcommand defining system options, 2-1 displaying active mappings, 2-1 description, 2-12 sample output, B-2

SAF RACROUTE, 3-2 SHOW CPF sample output, B-3

SAFDEF records, 2-1, 2-4, 2-12 SHOW DB2 sample output, B-4 displaying, B-10

SHOW DDSN sample output, B-4 SAFELIST, 2-12

SHOW FIELDS sample output, B-5 Scope CA-ACF2 controls, 2-1 SHOW LDS sample output, B-6 report checking, 6-8

SHOW LINKLST subcommand, displaying GSO LINKLST record specifications, 5-5 Scope records

displaying, 3-7 SHOW MODE sample output, B-7 displaying and changing, 3-9

using, 3-6 SHOW NJE sample output, B-7 SCPLIST field, logonid record, 3-6, 3-10 SHOW PROGRAMS subcommand Security administrator displaying logged programs, 5-3

displaying maintenance logonids, programs, and libraries, 5-4

described, 3-2 displaying system options, 2-2

displaying programs and library names, 5-3 Security administrators displaying restricted program names, 5-4

decomp authority, 3-7 sample output, B-7 Security considerations, PPGM, 2-6 SHOW RESIDENT subcommand, B-8 SECURITY field, logonid record, 3-2, 3-10 SHOW RSRCTYPE subcommand, B-8

and rule sets, 3-7 SHOW RSVWORDS subcommand, B-9

Security, migrating to, 7-1 SHOW SAFDEF subcommand

SEC-VIO field, logonid record, 3-12 displaying SAF definitions, 2-4 displaying SAFDEF definitions, 2-1 SECVOLS, 2-6 sample output, B-10

SEGTYPE, 2-10 SHOW STATE subcommand, B-11

Sensitive logonid record fields, 3-12 %CHANGE, 3-8 %RCHANGE, 3-9 Separation of function, privileges, 3-2 DECOMP authorities, 3-8

SERVICE keyword, resource rule, 5-2 displaying rule sets with NOSORT, 2-4 displaying system mode, 2-3 SEVPOST field, GSO EXITS record, 2-16


NOCENTRAL, 3-8 STCXIT field, GSO EXITS record, 2-15 NOCHANGE, 3-9 Structured Infostorage applications, displaying, B-2 validating started tasks, 2-4 verifying ACFFDR and GSO values, 2-2 SUBAUTH field, logonid record, 3-10

SHOW subcommand Supervisor call initialization exit, 2-16 CA-ACF2 boundaries, 2-3

SUSPEND field, logonid record, 3-12 displaying important GSO records, 2-3 sample outputs, B-1 SVC pre-processing, 2-16 verifying values, 2-2

SVCIXIT field, GSO EXITS record, 2-16 SHOW SYSPLEX subcommand, B-12

SYNCH command, 3-3 SHOW SYSTEM subcommand

SYS1 rule set, D-2 displaying last system access message, 2-4 sample output, B-12 SYSPLEX feature, displaying current settings, B-12 verifying ACFFDR and GSO values, 2-2

System access control, 3-1 SHOW TNG subcommand, B-13

System entry validation postprocessing exit, 2-16 SHOW TSO subcommand, B-13

System entry validation preprocessing exit, 2-16 SHOW UNIXOPTS subcommand, B-13

System options SHOW ZEROFLDS subcommand, B-14 displaying, B-11

reviewing for access rules, 4-9 SMF logging data sets, protecting with access rules, 4-8 setting, 3-4

System parameters, displaying, B-12 SMF records, 6-3, B-12 System task control, validation, 2-4 SMP/E, performing maintenance, D-2 System task validation exit, 2-15 SOURCE field, logonid record, 3-12 System-resident directories and access rules, displaying, B-8

Source name modification exit, 2-15

SOURCE rule entry, 4-5

Special CA-ACF2 users T ACCOUNT, 3-3

AUDIT, 3-4 CONSULT, 3-4

TAC type code, 5-2 general information, 3-2 LEADER, 3-4 Tape processing, 2-7 SECURITY, 3-2

TAPEBLP field, GSO OPTS record, D-3 SPF

TAPE-BLP field, logonid record, 3-10, 5-3 decompiling rulesets, 4-9 report generators, 6-8 TAPEDSN field, GSO OPTS record, 2-7, D-3 SHOW subcommand, 3-11

TAPE-LBL field, logonid record, 3-10, 5-3 SRCXIT field, GSO EXITS record, 2-15

Tapes, securing, D-2 Started tasks

Terminal monitor program (TMP), A-1 displaying, 2-4 local exits, 2-15 TNGNODEs, displaying, B-13 verifying CA-ACF2 control, D-2

TRACE field, logonid record, 3-12 STC field, logonid record, 3-10

STC field, OPTS record, 2-4

Index–9


TSO displaying default options, B-13 logging commands or CLISTs, 6-2 Terminal monitor program (TMP) processing, A-1

TSO field, logonid record, 3-12

TSOCMDS field, logonid record, 3-13

TSO-TRC field, logonid record, 3-12, 6-2

Type codes, 5-2

TYPE parameter, IMS, 2-9

U

UADS field, GSO OPTS record, 2-5

UID rule entry, 4-5

UIDSCOPE field, logonid record, 3-10

UNICNTR field, logonid record, 3-10

UNIX System Services displaying options, B-13

UNIXOPTS field, of SHOW subcommand, B-13

Unrestricted account manager, 3-3 security administrator, 3-3

UNTIL rule entry, 4-6

User Attribute Data Set (UADS), bypassing, 2-5

User identification string (UID) examples, 4-1 multi-value logonid fields, 4-2

User Identification String (UID) masks, 4-2

User profile records, 3-2

USERKEY, 2-12

Users logging access, 6-2 special privileges, 3-2, 3-4

USREFLD exit name, 2-14

Utilities ACFBATCH, 2-2, A-1 DRWDASDR, 2-6 dump core, 2-14 IEHDASDR, 2-6

V

VALIDATE parameter, IMS, 2-9

VERIFY keyword, resource rule, 5-3

VIOEXIT field, GSO EXITS record, 2-13

VLDEXIT field, GSO EXITS record field, 2-13

Volume protection, 2-13

VOLUME rule entry, 4-5

VSAM clusters, D-1

W

WARN mode, 7-1

WRITE access permission, 4-7

Z

ZONE field, logonid record, 3-12

Zone records, displaying and changing, 3-9

eTrust™ CA-ACF2® Security for z/OS and OS/390

Documents