Performance Test supports security packages that use the SAF interface including RACF, ACF2, and Top Secret. This section explains how to setup security rules to prevent unauthorized access to data sets that contain sensitive information and unauthorized use of Performance Test functions.

Secure Performance Test data sets to prevent unauthorized access to sensitive information. For example, capture repository data sets can contain user sign-on events. Secure these data sets to prevent unauthorized personnel from accessing user IDs or passwords.

Securing data sets not only requires granting authority to your users, but to the Performance Test features that read from and write to the secured data sets.

This section describes the type of authority required for the various Performance Test data sets.

Grant authority to the Performance Test libraries

All Performance Test users and the Global Recording started task must have authority to READ the product libraries.

Grant authority to the Global Recording request file

The Global Recording request file is used to maintain Global Recording request information. All Performance Test users who need access to the Global Recording feature must have authority to UPDATE the Global Recording request file. This includes Performance Test users who execute the Global Record Batch Interface for any function and users who access the Review Repository feature. The Global Recording started task and the 3270/APPC script creation procedure requires this authority as well. The default name of this procedure is HSSCREAT.

Grant authority for Global Recording repository data sets

The Global Recording feature captures system activity, including sign-on transactions. It stores the information in data sets called repositories. Secure these data sets to prevent unauthorized access to the sensitive information they may contain, such as user IDs and passwords.

Users specify the repository data set name when they create a Global Recording request. They can use wildcard characters to segment a repository, resulting in a series of data sets. To support segmented repositories and to provide flexibility with repository naming, establish one or more generic repository data set rules, then grant Global Recording users ALTER authority against those rules.

Also, grant the:

• Global Recording started task authority to ALTER repository data sets so that it can create the repository and write the recorded activity.
• 3270 and APPC script creation procedure, HSSCREAT, authority to READ the repository data sets. This applies if you are installing Performance Test for VTAM or the APPC testing features in Performance Test for Mainframe Servers.

After you have implemented data set security, make sure that the Performance Test Global Recording security checking parameters are set accordingly. These parameters control the authority checking performed by Performance Test when a user creates, updates, or restarts a Global Recording request. By default, no authority checking is done by Performance Test. If you are installing:

• Performance Test for VTAM, set GLOBAL_RECORD_LU2_SECURITY to ALL, REPOS, or SCRIPT.
• The APPC testing features in Performance Test for Mainframe Servers, set GLOBAL_RECORD_LU6_SECURITY to ALL, REPOS, or SCRIPT.
• The TCP/IP testing features in Performance Test for Mainframe Servers, set GLOBAL_RECORD_TCP_SECURITY to ALL or REPOS.
• Performance Test  for WebSphere MQ, set GLOBAL_RECORD_MQ_SECURITY to ALL or REPOS.

ALL causes Performance Test to check the user’s authority for all of the data ets specified in the Global Recording request. REPOS causes Performance Test to check the user’s authority for the repository data set specified in the request. SCRIPT causes Performance Test to check the user’s authority for the script and detail data sets. NONE disables authority validation.

The Global Recording checking parameters reside in the PARMLIB member HSCM. Access these parameters by editing the PARMLIB member.

Grant authority for Archive Repository and Registry data sets

The Archive Recording feature captures system activity, including sign-on transactions. It stores the information in data sets called repositories. Secure these data sets to prevent unauthorized access to the sensitive information they may contain, such as user IDs and passwords.

Users specify the repository registry data set name when they create an Archive Recording request. Repository data sets are built from the repository registry data set name. (For example: <registry name>.#*). This creates a series of data sets.

To support segmented repositories and to provide flexibility with repository naming, establish one or more generic repository data set rules, then grant Archive Recording users ALTER authority against those rules.

Also, grant the:

• Archive Recording started task authority to ALTER repository data sets so that it can create the repository and write the recorded activity.
• Registry procedure, HSRGSTRY, authority to READ the repository data sets and authority to ALTER and create the repository registry.

After you have implemented data set security, make sure that the Performance Test Archive Recording security parameters are set accordingly. These parameters control the authority checking performed by Performance Test when a user creates, updates, or restarts an Archive Recording request. By default, no authority checking is done by Performance Test. If you are installing Performance Test for VTAM, set GLOBAL_RECORD_LU2_SECURITY to ALL, REPOS, or SCRIPT.

• ALL causes Performance Test to check the user’s authority for all of the data sets specified in the Archive Recording request.
• REPOS causes Performance Test to check the user’s authority for the repository data set specified in the request.
• SCRIPT causes Performance Test to check the user’s authority for the script and detail data sets.
• NONE disables authority validation.

Access these parameters by editing the PARMLIB member.

Grant authority for Script, Detail, and Log data sets

Script and detail data sets are generated from the repository data sets. They too can contain sensitive information, such as user IDs and passwords.

Log data sets contain information pertaining to the sessions captured in a 3270 and APPC Global Recording request. Although they do not contain sensitive information, Performance Test checks the user’s authorization to these data sets if they specify a data set that does not exist or the Global Recording security parameters, described in the previous section, are set to ALL or SCRIPT.

Protect the information contained in the scripts and detail data sets and provide authority to create or write to the log data sets in the same way as the repository data sets. That is, create generic data set rules and grant ALTER authority against those rules to the appropriate personnel. Also, if you are using Performance Test for VTAM or the APPC testing features in Performance Test for Mainframe Servers, grant authority to UPDATE these data sets to the script creation procedure HSSCREAT.

Performance Test provides a utility that produces a list of all PTFs applied to your installation. If a user calls BMC Customer Support with a technical issue, Customer Support may request a copy of this information to aid with diagnosing the issue. Users must have READ access to the SMP/E data sets to use this utility.

If you elected not to install the Customer Solutions Diagnostic, skip this step. If you wish to enable this feature after installation, simply grant READ access to the SMP/E data sets. The Guided Configuration sets the parameters required to enable this feature when the SMP/E environment is built.

Grant authority to the Site Profile data set

The Site Profile data set is used to store User Profile members. A rule should be created that allows regular users to browse the data set (provide READ access) and only give programs the ability to change the data set (provide UPDATE access).

The default name of this data set is hlq.SITE.FILE (where hlq is the high level qualifier for the site profile that was specified during product installation). The site profile data set name is specified in the HSCM PARMLIB member.

1. Create a RACF Rule for the SITE.FILE data set with a UACC (Universal ACCess) authority of READ.
2. Change the Conditional Access portion of the new RACF Rule to allow the following ISPF and Performance Test programs to have UPDATE access to the SITE.FILE data set:
   • ISFPARMS — SDSF exit program
   • HSPROF — Performance Test program
   • CALLPRF — Performance Test program
   • ISSETTER — Performance Test program
   • ISGETTER — Performance Test program
   • IKJEES75 — TSO I/O program
   • ISPQRY — ISPF query program.
3. If your site uses the PDSMAN utility (Partitioned Dataset Management System), then the following programs also need to have UPDATE access to the SITE.FILE data set:
   • EZYISPF
   • EZYIIF
   • ETRMLDEF
   • ETRMIMNU.
4. The Load Libraries that contain the programs listed above must be under Program Control in RACF. Without this condition, the conditional portion of the RACF rule will not be executed, and Update Authority will not be granted to the specified program names.

Custom sign-on security

If your site uses Performance Test for VTAM or Performance Test for Mainframe Servers to record and playback 3270 scripts, consider enabling custom sign-on security in addition to implementing data set security.

Any 3270 script can contain sign-on events. To prevent a user from accessing the system with another user’s ID and password, enable custom sign-on security. When enabled, Performance Test compares the current sign-on of the user playing a script to the sign-on in the 3270 script and allows playback to continue only if they match.

To enable custom sign-on security, update the HSCM PARMLIB member. In HSCM, you must change parameter ENABLE_CUSTOM_SIGNON_SECURITY to YES, identify your logon screens to Performance Test, and code custom sign-on table entries (also within the HSCM PARMLIB member). Each sign-on table entry, SIGNON_ENTRY through END, identifies the row, column, and length of the userID field along with a character string unique to the sign-on screen. Code as many entries as needed to identify all of your logon screens.

Enabling Repository encryption

Global Recording and Archive Recording can encrypt the data written to the repository data sets. The ENCRYPT_VTAM, ENCRYPT_TCP, and ENCRYPT_MQ parameters enable repository encryption. Access these parameters by editing the PARMLIB member.

Enable function-access security

Three parameters control function-access security: SECURITY_CLASS_NAME, SECURITY_CLASS_ENTITY, and SECURITY_VOLUME. These parameters reside in the PARMLIB member HSCM.

If you selected the External Security Interface option, you are prompted for these values. To enable function-access security after installation:

1. Change these parameter values by editing the PARMLIB member.
2. Generate the manual task lists described in Manual Task Lists, and complete the security tasks.

SECURITY_CLASS_NAME

SECURITY_CLASS_NAME defines the security, or resource, class name. The default value of this parameter is NOSECURITY.

To enable function-access security, provide a resource class name on this parameter. The class name can be one to eight alphanumeric characters and enclosed in single quotation marks. For a list of resource classes, such as DATASET or FACILITY, refer to IBM’s RACF Macros and Interfaces.

Specify a unique class name if you are installing:

• Performance Test for Mainframe Servers APPC testing features and need to secure TP names that exceed eight characters. If DATASET is specified, Performance Test uses only the first eight bytes of the TP name for security checks.
• Performance Test for WebSphere MQ. If DATASET is specified, Performance Test uses APPCTP for queue manager and queue name security checks. This means you must assign the queue manager and queue name rules to APPCTP, while all other rules must be assigned to DATASET.

SECURITY_CLASS_ENTITY

SECURITY_CLASS_ENTITY defines the security entity name. The default value is HIPER. This parameter’s value can be one to eight alphanumeric characters and enclosed in single quotation marks.

This is the high-level qualifier for the resource names that Performance Test checks. For example, if a user attempts to access the Domain Traveler function, and you have accepted the default value of HIPER, Performance Test checks HIPER.FN.TESTING.

SECURITY_VOLUME

SECURITY_VOLUME is the volume ID that Performance Test specifies on the call to the security package when the class name is set to DATASET. If the class name is not DATASET, Performance Test does not use this parameter. The default value is HIPERX. This parameter’s value can be one to six alphanumeric characters and enclosed in single quotation marks.

Determine security requirements

Determine security requirements before implementing security rules. To do this, determine:

• Which product features are installed
• Who needs access to the functions within each product feature
• The applications (lunames), MQ queue manager and queue names, and the client and server IP addresses and ports that should be available to each function and user.

Review the Object/Function column in Performance Test Function Security Matrix to see the objects and functions that you can secure for each product feature. Identify all of the objects and functions you need to secure, then determine who needs access to those objects and functions.

Define profiles to your security package

A Performance Test resource is the object or function that can be secured. For example, for Performance Test for VTAM’s Domain Traveler feature, you can secure:

• The Domain Traveler feature
• The applications accessed with the Domain Traveler
• The applications accessed by the play command in Domain Traveler
• The applications accessed by the record command in Domain Traveler
• The TRACE function used in Domain Traveler.

Each of these objects or functions is a resource. When a user attempts to access a resource, Performance Test issues a RACROUTE call to the security package to determine if the user has permission to use that resource. Define your security profiles based on the Performance Test resources.

Performance Test determines which resource to check based on the value of the security entity name parameter and the product feature and function that the user is attempting to access. Following the previous example, if you set the security entity name parameter to ‘QAC’, Performance Test checks QAC.TP.luname.

Performance Test Resource name format

The format of a resource name is identifier.type.name, where:

• identifier is the entity name specified on the SECURITY_CLASS_ENTITY parameter. The default value is HIPER. Enable Function-Access Security describes this parameter and explains how to access it for each method of installation.
• type is the type of resource being secured. Performance Test Resource Types for Security Resource Definitions shows all of the available types.
• name is the name of the resource being secured. Depending on the specified type, the name can be a user ID, the LU name of an application, an MQ queue manager and queue name, an IP address and port number, or a Performance Test product function. Performance Test Function Names for Security Resource Definitions shows a list of the Performance Test product function names.

The Function Security Matrix shows the objects or functions that can be secured for each product feature. It indicates the resource that Performance Test checks and the type of authority that a user requires for the given resource. Use the table to determine your security requirements and to quickly identify the resource names required for building your security profiles.

Performance Test Function Security Matrix

Set up HCI security

If you are running HCI as a started task, the user ID associated with this task must have READ authority to the Performance Test data sets.

To use HCI with TCP/IP, Open Edition MVS segment, access also needs to be defined.