ca top secret r16 supplemental administrative guidance … · ca top secret r16 supplemental...

CA Top Secret r16

Supplemental Administrative Guidance for

Common Criteria

Version: 1.0

July 7, 2017

Prepared for:

CA Technologies

3333 Warrenville Road

Suite 800

Lisle, IL 60532

All Rights Reserved

Prepared by:

Cyber Assurance Testing Laboratory

304 Sentinel Drive

Annapolis Junction, MD 20701

Supplemental Administrative Guidance for Common Criteria CA Top Secret r16

1 | P a g e

Table of Contents

1 Intended Audience ................................................................................................................................ 2

2 Terminology .......................................................................................................................................... 2

3 References ............................................................................................................................................. 2

4 Evaluated Configuration of the TOE .................................................................................................... 3

4.1 TOE Components .......................................................................................................................... 3

4.2 Supporting Environmental Components ....................................................................................... 5

4.3 Assumptions .................................................................................................................................. 6

5 Secure Installation and Configuration ................................................................................................... 8

5.1 Installing Top Secret ..................................................................................................................... 8

5.2 Setting up Advanced Authentication Mainframe ........................................................................ 11

5.3 LDAP Configuration ................................................................................................................... 11

5.4 Login Banner Configuration ....................................................................................................... 11

5.5 Audit Storage Configuration ....................................................................................................... 12

5.6 Configuration of Secure Remote Communications .................................................................... 12

Configuring ICSF ................................................................................................................ 12

Configuring System SSL .................................................................................................... 12

Configuring OpenSSH ........................................................................................................ 12

Configuring CA Common Services .................................................................................... 13

Establishing CPF Communications..................................................................................... 14

5.7 Secure Usage Guidelines ............................................................................................................ 15

6 Administration by Security Function .................................................................................................. 19

6.1 Enterprise Security Management ................................................................................................ 19

6.2 Security Audit ............................................................................................................................. 22

6.3 Communications ......................................................................................................................... 26

6.4 User Data Protection ................................................................................................................... 26

6.5 Identification and Authentication ................................................................................................ 29


2 | P a g e

6.6 Security Management ................................................................................................................. 30

6.7 Protection of the TSF .................................................................................................................. 35

6.8 Resource Utilization .................................................................................................................... 36

6.9 TOE Access ................................................................................................................................ 36

6.10 Trusted Path/Channels ................................................................................................................ 37

7 Operational Modes .............................................................................................................................. 37

8 Additional Support .............................................................................................................................. 38

1 Intended Audience

This document is intended for administrators responsible for installing, configuring, and/or operating CA

Top Secret r16. Guidance provided in this document allows the reader to deploy the product in an

environment that is consistent with the configuration that was evaluated as part of the product’s Common

Criteria (CC) testing process. It also provides the reader with instructions on how to exercise the security

functions that were claimed as part of the CC evaluation.

The reader is expected to be familiar with the Security Target for CA Top Secret r16 and the general CC

terminology that is referenced in it. This document references the Security Functional Requirements

(SFRs) that are defined in the Security Target document and provides instructions for how to perform the

security functions that are defined by these SFRs.

The reader is also expected to have general familiarity with mainframe operation and CA Top Secret. CA

Top Secret provides a large number of security functions for mainframe systems. Many of these functions

are outside the scope of the claimed Protection Profiles for this evaluation and were therefore not claimed

in the Security Target or tested as part of this evaluation. The vendor documentation that is relevant to the

tested security functionality is cited in this document under each tested security function.

2 Terminology

In reviewing this document, the reader should be aware of the following terms:

SFR: stands for Security Functional Requirement. An SFR is a security capability that was tested as part

of the CC process.

TOE: stands for Target of Evaluation. This refers to the aspects of CA Top Secret r16 that contain the

security functions that were tested as part of the CC evaluation process.

3 References

New for CA Top Secret r16, all documentation can be found in a single location at

https://docops.ca.com/ca-top-secret-for-z-os/16-0/en. This replaces the individual documentation that was

https://docops.ca.com/ca-top-secret-for-z-os/16-0/en


3 | P a g e

available in previous versions of the product. The Security Target (referenced throughout this document

as [ST]) was created in support of the Top Secret r16 CC evaluation.

Note that the product documentation includes comprehensive information about CA Top Secret which

includes features that have not been tested as part of the Common Criteria evaluation. The supplemental

guidance documentation references the sections of the web guidance that are applicable to the evaluation.

Note that referenced sections may also contain information that is not relevant to the evaluation. It is

therefore recommended that the CA Top Secret r16 Security Target [ST] be referenced in order to clearly

identify the specific functions that were tested as part of the evaluation.

4 Evaluated Configuration of the TOE

This section lists the components that have been included in the TOE’s evaluated configuration, whether

they are part of the TOE itself, environmental components that support the security behavior of the TOE,

or non-interfering environmental components that were present during testing but are not associated with

any security claims:

4.1 TOE Components Component Definition

Audit/Tracking File The Audit/Tracking File records security-related events such as security violations

and resource access.

Command Line

Interface (CLI) The CLI provides a mechanism to configure the TOE.

Command Processor

A TOE subsystem that is responsible for receiving administrative commands from

different external interfaces and parsing them into a standardized format that the TSF

will interpret.

Command

Propagation Facility

(CPF)

The CPF provides a single-point management capability that allows CA Top Secret

commands issued on one system to be propagated to distributed systems or to

different logical partitions (LPARs) of the same system.

Parameter File

The parameter file contains all control options that are customizable by an

administrator. It is invoked during startup but can be maintained dynamically via the

TSS MODIFY command.

Security File

The security file contains all security records for users and resources and is used to

define each user’s access permissions. When a user logs on to the system, their

secrec is built from data in the security file that applies to them.

Sign-on Process The sign-on process intercepts authentication requests made to the mainframe

system which allows the TSF to determine whether the requests are valid.

System Authorization

Facility (SAF) Router

The IBM System Authorization Facility (SAF) provides a system wide interface to

CA Top Secret. The key component that SAF uses is the CA SAF Router (A

component of CA Top Secret). All RACROUTE calls are processed through the CA

SAF router to CA Top Secret. CA Top Secret processes all SAF calls by default.

This enables CA Top Secret to manage all of the unique processing needed to

provide full security coverage for the z/OS platform.

Table 1- TOE Components

The claimed Protection Profiles define a very specific set of activities that must be adjudicated by a host-

based access control product. In its evaluated configuration, CA Top Secret was tested to demonstrate that


4 | P a g e

its access control and policy enforcement mechanisms can be used to control access to the specific

subjects, objects, operations, and attributes that are defined in the Protection Profiles. CA Top Secret

provides a large amount of additional functionality that can be used to control user activity on a

mainframe system above and beyond what was described in the claimed Protection Profiles. The

following table describes the object/rule types or rule attributes that are used to demonstrate conformance

to the functionality defined in the claimed Protection Profiles:

Object/Rule Type Summary

ACID

Accessor ID. In the context of an object, can refer to user ACIDs,

profile ACIDs, control ACIDs, or organizational ACIDs. Top Secret has

the ability to grant one ACID the authority to submit a job on behalf of

a second ACID, inheriting the permissions of that ACID when doing so.

APPLID Application name. The access control SFP can be used to restrict system

entry to authorized applications.

DATASET Defines one or more filesystem objects.

FACILITY

In Top Secret, the term FACILITY is analogous to application name.

Users can be allowed or denied system entry based on the application

they are using to request access to the system.

IBMFAC

Short for IBM Facility. Represents native z/OS callable services such as

RAUDITX, SERVER, and RDCEKEY that are used to interact with

system facilities such as SMF. Note that the term ‘facility’ is used

differently between Top Secret and z/OS.

JESJOBS

Job Entry Subsystem (JES) is an interface to z/OS that receives jobs,

schedules them for processing, and controls their output. Top Secret can

restrict the ability of users to submit jobs on the system.

LCF

Limited Command Facility (LCF) provides the ability to define either a

whitelist or blacklist for mainframe system commands to apply to a

particular user.

OPERCMDS Defines one or more operator commands, or the ability to manipulate

system configuration.

PROGRAM Defines one or more programs that access control restrictions can be

placed upon.

RESOURCE General term for rules that control access to system objects other than

datasets.

SOURCE Defines unallowable source of origin for a particular ACID’s attempts

to access the system.

TERMINAL Defines allowable source of origin for a particular ACID’s attempts to

access the system.

Table 2 - Applicable Object and Rule Types for ESM Host-Based Access Control

The table below shows the subject-object-operation pairings defined in the Standard Protection Profile for

Enterprise Security Management Access Control with mappings to the table above. This shows the

specific subset of Top Secret’s functionality that was tested as part of the Common Criteria evaluation of

the product.


5 | P a g e

Subject Object Operation Command Type

Mainframe

User or

Started

Task

Processes

Execute

DATASET

JESJOBS

LCF

RESOURCE (PROGRAM)

RESOURCE (ACID)

VOLUME

Delete DATASET

VOLUME

Terminate RESOURCE (OPERCMDS)

Change Permissions

DATASET

RESOURCE (PROGRAM)

VOLUME

Files

Create

DATASET

VOLUME

Read

Modify

Delete

Change Permissions

Host Configuration

Read DATASET

LCF

RESOURCE (OPERCMDS)

RESOURCE (IBMFAC)

VOLUME

Modify

Delete

Authentication Function Login

ACID

FACILITY

SOURCE

TERMINAL

Table 3 - Command Types for Enforcing Host-Based Access Control

For more information on the specific functional capabilities of Top Secret that were tested as part of the

evaluation, reference the Security Target.

4.2 Supporting Environmental Components Component Definition

CA LDAP Server

In the Operational Environment, an LDAP directory is used to provide a centralized

definition for user identities. CA LDAP Server is a z/OS application that is used to

translate LDAP communications from an LDAP directory into commands that will

synchronize the TOE’s users with those defined in LDAP.

Chorus Software

Manager (CSM)

CA Chorus Software Manager is a utility that simplifies the acquisition and

maintenance of mainframe software. In the evaluated configuration, CSM will be

used to install the TOE.

Common Services

CA Common Services is a set of common components used by a number of CA’s

mainframe products. It supports the TOE specifically by providing TCP/IP

communications services that are used to support remote communications.

Integrated

Cryptographic

IBM ICSF is the default cryptographic engine provided by z/OS. It supports the TOE

by providing services that allow for remote TCP/IP communications to be encrypted

using FIPS-validated cryptography.


6 | P a g e

Services Facility

(ICSF)

RSA Agent A z/OS application that brokers authentication attempts that use RSA SecurID token

authentication.

RSA Authentication

Manager

A service that resides within the organization that maintains a repository of RSA

SecurID tokens and can determine if authentication attempts using RSA SecurID are

valid.

System Management

Facility (SMF)

SMF is a component of IBM z/OS that provides a standardized logging format for

z/OS programs. The TOE’s audit data is transmitted to the Operational Environment

as SMF logs.

Terminal

The terminal is a remote interface used to administer the TOE or operate the

mainframe system. A mainframe operator will use a TN3270e class terminal

emulator in order to interact with the mainframe using the terminal.

z/OS IBM z/OS is the mainframe operating system on which CA Top Secret is installed.

Table 4 - Supporting Environment Components

4.3 Assumptions

In order to ensure the product is capable of meeting its security requirements when deployed in its

evaluated configuration, the following conditions must be satisfied by the organization, as defined in the

claimed Protection Profiles:

Trusted installation and administration: CA Top Secret provides the ability to limit the

security functionality that is available to system administrators. However, it is still necessary to

have a trusted administrator responsible for the initial administration and configuration of the

product, including initial delegation of administrative privileges.

Use of z/OS cryptography: CA Top Secret does not provide its own cryptographic capabilities.

If the secure remote communications prescribed by the ST are to be implemented (TLS for

remote CPF commands and SSH for remote administration), the administrator must ensure that

the IBM Integrated Cryptographic Services Facility (ICSF) is deployed and configured in a FIPS-

compliant mode of operation. Instructions for this are not provided by CA.

Connectivity to remote ESM products: CA Top Secret provides both access control and policy

management capabilities. However, an instance of Top Secret can have its access control

functionality be configured by a remote instance of the product which effectively decouples these

two capabilities. If Top Secret is deployed in a distributed environment where it is necessary to

enforce uniform access control policies across remote nodes, it is assumed that CPF will be used

from a central point to administer multiple instances of Top Secret.

System time: Top Secret relies on system time data in order to enforce access control policy rules

that are time-based, current password violation count for user lockout (which is reset daily), and

accurate audit data. It is assumed that the z/OS system clock is accurate in order to provide this

data to Top Secret.

User identification: Top Secret maintains user and administrator data for mainframe users in its

Security File. However, there is no direct interface from the mainframe to Top Secret; all identity

data must be supplied to Top Secret through z/OS. Therefore, z/OS is assumed to provide

accurate user identity data to Top Secret so that access control policies can be enforced against

the correct users.


7 | P a g e

Additionally, it is expected that the organization have the following policies implemented for their site in

order to maintain security:

All computer systems that require authorization to use and/or contain sensitive data, including the

mainframe systems, should display an acceptable use warning banner to users and administrators

prior to allowing access to the system.

Administrators of Top Secret are expected to be diligent in ensuring that access control policy

rules are periodically reviewed to ensure that they are still necessary so that principles of least

privilege are maintained.


8 | P a g e

5 Secure Installation and Configuration

5.1 Installing Top Secret

In the evaluated configuration, CA Chorus Software Manager (CSM) is used to acquire and install Top

Secret. More information about the use of CSM can be found at https://docops.ca.com/ca-chorus-

software-manager/6-1/en. In particular, the “Acquiring Products” and “Installing Products” sections of the

guidance are relevant to the acquisition and installation of products using CSM.

In order to install the CA Top Secret on any of its supported platforms, follow the applicable instructions

described in the web guidance under Installing > Install Your Product Using CA CSM.

The installation procedures assume that CSM is already installed and deployed for the customer site, the

product has been purchased and added to the CSM library, and the target system does not already have

Top Secret installed on it. Note that new products and maintenance releases are automatically

downloaded by CSM as PAX files and verified internally before they are executed. In order to ensure that

you are downloading an authentic copy of the product prior to installation, ensure that the product is

acquired by downloading the software from www.ca.com/support using CSM.

Below is a summary of the steps that are followed to perform the installation.

1. From the CSM Products screen

Select the CA drop down and select CA Top Secret for z/OS – MVS

Click on the 16.0 drop-down and click on the “0000” selection

2. The Base Installation Package screen is presented:

Select the ACTIONS button to the right of the Top Secret Prod Tape selection

From the drop-down menu, select the INSTALL option

3. The Base Installation Introduction screen is presented:

Scroll down and click on the “I accept the terms of the License Agreement” radio button, and

click on the NEXT button

4. The Installation Type Selection screen is presented:

Select the “CA Top Secret Base Only Install” option, and click on the NEXT button

5. The Prerequisites screen is presented:

There are no prerequisites for the install of Top Secret; click on the NEXT button

6. The SMP/E Environment Selection screen is presented:

Select the “Create a NEW SMP/E Environment” option, and click on the NEXT button

7. The SMP/E Environment Setup screen is presented:

Fill in the SMP/E environment settings:

Environment Name (example: TSS QA TEST INSTALL)

Dataset Name (DSN) Prefix (example: STRTH01.R16.TEST)

Under the SMP/E Datasets Allocation Parameters section (half-way down):

Set the High-Level Qualifier (HLQ) to the same as the DSN Prefix specified above

(example: STRTH01.R16.TEST)

Set DSN Type to “PDS

https://docops.ca.com/ca-chorus-software-manager/6-1/en

https://docops.ca.com/ca-chorus-software-manager/6-1/en

http://www.ca.com/support


9 | P a g e

If System Managed Storage (SMS) will manage the SMP/E datasets:

Select “SMS Parameters”

Set Storage Class to “TSO “

If System Managed Storage (SMS) will NOT manage the SMP/E datasets:

Select “Data Set Parameters”

Set the VOLSER, Unit, and Catalog parameters as appropriate

Click on the NEXT button

8. The SMP/E Environment Parameters screen is presented:

Verify that the information is correct for the install, and click on the NEXT button

9. The Target Zone Selection screen is presented:

Click on the “Create a New Target Zone” button, and click on the NEXT button

10. The Target Zone Setup screen is presented:

Verify that all data is correct for the install, and click on the NEXT button

11. The Target Zone Parameters screen is presented:


12. The Distribution Zone Selection screen is presented:

Click on the “Create a New Distribution Zone” button, and click the NEXT button

13. The Distribution Zone Setup screen is presented:


14. The Distribution Zone Parameters screen is presented:

Verify that all data is correct for the install, and click on the NEXT button.

15. The Summary screen is presented:

Verify that all data is correct for the install, and click on the INSTALL button

CSM will now begin the install process

When the install is complete, a pop-up screen will be presented showing the final status; it should

show “100%”, and may indicate the install “Succeeded with warnings”

16. To review the output of each step:

Click on the SHOW RESULTS button in the pop-up

A screen will be presented, showing each of the installation task steps

Click on the desired task to review the output of that step

17. The base SMP/E install is now complete. The window returns to the main CSM screen:

From this screen click on the SMP/E ENVIRONMENTS tab

18. In the CSM SMP/E ENVIRONMENTS tab:

Scroll down the left hand side under “Available Products” to find the install just completed

Click on the new install

The displayed screen shows the installed SME/E environment, and the various actions that can be

performed in and for it


10 | P a g e

19. From installed SME/E environment screen all published Top Secret maintenance should be

installed so that the Top Secret libraries will have the most up to date maintenance. Click on the

MAINTENANCE button and CSM will go out to CSO and bring back all published maintenance

to be installed. This screen will show the status of all APARs that have been published. Since

this was a base install, there are numerous published APARs that need to be applied. Since most

clients already have Top Secret installed, published APARs that clients will have to applied will

be a very small subset compared to a new base install. After all maintenance has been installed,

the rest of the install is done outside of CSM. JCL needed to finish the install can be found in the

CAKOJCL0 dataset that was created during the SMP/e install.

There are two ways to install APARs onto the base install. You can install individual APARs by clicking

on the ACTION button and select the appropriate action such as RECEIVE when the status of the APAR

is NOT RECEIVED. You would than follow the same procedure to apply and accept APARs.

You can click on the SELECT box which will check off all APARs shown on the current page and then

click on the RECEIVE button. This will receive a group of APARs at one time. You can than follow the

same procedure to apply and accept a group of APARs at one time.

The SITE ENCRYPTION KEY must be installed into the Top Secret CAKOLINK dataset. This is done

by executing job TSSKEY found in the CAKOJCL0 dataset. This job installs APAR CRYPTKY to the

CA TOP Secret CAKOLINK dataset. The following items must be modified prior to submitting this job:

Change GLOBALHLQ.GLOBAL.CSI to the SMP/E CSI dataset name for your site.

Change ????,????,????,???? to the security file encryption key value for your site.

The key must be a 16 hex digit string.

Change the SMP/E zone names to the correct names for your environment.

Do NOT skip ACCEPT the APAR step. Otherwise your encryption key will remain in your

SMPPTS and this would cause security exposure.

The Top Secret security file and backup file along with all other Top Secret files must be formatted

outside of CSM. The JCL to do so is found in the CAKOJCL0 dataset created during the install.

VSAMDEF3 is used to ALLOCATE VSAM SECFILE EXTENSION. These datasets are used in

TSSMAINS, so this must be run first.

VSAMDEF6 is used to ALLOCATE VSAM SECFILE EXTENSION BACKUP.

These datasets are used in TSSMAINB, so this must be run first.

TSSMAINS is used to format the Top Secret Security file.

TSSMAINB is used to format the Top Secret Backup file.

TSSMAINA is used to format the Top Secret Audit Tracking files.

TSSMAINR is used to format the Top Secret Recovery file.

TSSMAINC is used to format the Top Secret CPF Recovery file.

When TSSMAINS is run to format a new security file, the only ACID on the file will be the MSCA

ACID. This ACID is specified as one of the keywords for TSSMAINS. When the Top Secret address

space is started using a new security file, the MSCA acid must be defined in IBM’s SYS1.UADS dataset

in order for the MSCA to logon to TSO. The MSCA, when created, has all Top Secret admin authorities

and scope over all ACID types, but as no access to any resources. Once the MSCA has logged on, the


11 | P a g e

MSCA can add TSO segment data to himself so that the Top Secret database can be used in place of

IBM’s SYS1.UADS dataset. To show that only the MSCA ACID type is present on the new file, issue

command TSS LIST(ACIDS) DATA(ALL) and only data concerning the MSCA will be displayed.

5.2 Setting up Advanced Authentication Mainframe

If the use of RSA SecurID token authentication for the mainframe is desired, the Advanced

Authentication Mainframe capability must be installed by following the steps listed in “Installing and

Configuring Advanced Authentication Mainframe” in the web guidance.

5.3 LDAP Configuration

Top Secret can be deployed in an enterprise environment where an LDAP directory exists as a centralized

mechanism for user identity management. In such an environment, Top Secret’s Security File is still used

in the same manner as if an LDAP directory was not present. However, the LDAP directory contents can

be synchronized with the user ACIDs defined in the Top Secret Security File through the configuration of

CA LDAP Server on the mainframe system that is protected by Top Secret. CA LDAP Server can receive

LDAP commands and execute them as equivalent administrative commands on Top Secret.

CA LDAP Server is a distinct product from Top Secret so detailed instructions for its installation and

configuration are not included here. However, you can reference the guidance for CA System z Security

Communication Servers (DSI, LDAP, PAM), which can be found at https://docops.ca.com/ca-system-z-

security-communication-servers/15-1/en.

Below is an outline of the steps needed to install and configure the CA LDAP Server product.

1. Using CSM, select the PRODUCT, CA Top Secret – MVS 16.0

2. Find the Base Install Package for “CA LDAP Server Release 15.1 0000” under “15.0 0000” and

select the Install Action.

3. Read the “Product README instructions for this installation” for any product specific install

details.

4. Proceed with the normal CSM install of an SMP/E maintained product.

5. APPLY and ACCEPT all published maintenance. 6. Now that CA LDAP Server is installed, you need to perform the following configuration:

a. Modify and run the sample job to define the LDAP STC user id

b. Modify the LDAP STC proc, if needed, that will be used to start the CA LDAP Server as

a STC

c. Modify the CA LDAP Server configuration file, slapd.conf, to load and enable the CA

Top Secret interface

Using the available automation package, config to autostart the STC after TCPIP is started and stop it

before TCPIP is shut down.

5.4 Login Banner Configuration

Since Top Secret is administered through TSO, it does not present a separate interface to the user from

what the mainframe system itself already presents. Therefore, if site security policy dictates the need to

configure a warning banner that advises users on secure usage of the system prior to logon, it is necessary

to customize the TSO logon pre-display exit (IKJEFLN1). Instructions for doing this can be found in the

documentation for IBM z/OS TSO/E Customization (SA32-0976-00) in the IBM documentation library.

https://docops.ca.com/ca-system-z-security-communication-servers/15-1/en

https://docops.ca.com/ca-system-z-security-communication-servers/15-1/en


12 | P a g e

The desired banner text can be displayed in the “First message” and/or “Second message” configuration

parameter. Note that the logon panel must be configured to have the first and/or second message area be

present in order for the custom text to be displayed.

5.5 Audit Storage Configuration

CA Technologies suggests the site use IBM best practices when setting up and backing up SYSLOG and

SMF data. The SYSLOG and SMF records will include system data unrelated to Top Secret so any offsite

storage, aggregation, and/or review of SYSLOG and SMF data is expected to be performed as part of

existing data retention and review policies. In order to minimize the risk of data loss, ensure that

sufficient storage space is allocated for log data.

5.6 Configuration of Secure Remote Communications

Configuring ICSF

In the evaluated configuration for Top Secret, the ICSF component of z/OS must be installed and properly

configured. ICSF provides most of the underlying cryptographic services that are used to facilitated

trusted remote communications.

Installation of ICSF can be performed in accordance with the “Cryptographic Services Integrated

Cryptographic Service Facility System Programmer’s Guide” which can be found on IBM’s support site.

In general, ICSF can be installed and configured as required by the site, with one exception. During

installation of ICSF, it is necessary to specify the FIPSMODE(YES) in the installation options data set.

See Chapter 2 of the ICSF System Programmer’s Guide for more information about installing and

initializing ICSF which includes the installation options that can be specified.

Configuring System SSL

IBM System SSL is the cryptographic implementation that is used by z/OS to encrypt TLS

communications, which in Top Secret’s evaluated configuration is used to secure CPF messages

transmitted between remote nodes.

Note that in z/OS 2.1, System SSL must be configured to interface with ICSF because ICSF is responsible

for performing random number generation and key exchange (Diffie-Hellman) services. If migrating to

z/OS 2.1, ensure that the steps detailed by “System SSL: Ensure ICSF is available when running System

SSL in FIPS 140-2 mode” in the IBM z/OS Migration Guide (GA32-0889-04).

Configuring OpenSSH

OpenSSH is provided by IBM as part of IBM Ported Tools for z/OS. It is used to allow the mainframe

system to act as an inbound SSH server so that remote administrative commands issued to the system (to

Top Secret or otherwise) can be secured using SSH. In the evaluated configuration for Top Secret,

OpenSSH must be configured to invoke ICSF to perform the cryptographic functions that are used to set

up the SSH connection.

Initial setup of OpenSSH is performed by following the procedures detailed in the “IBM Ported Tools for

z/OS: OpenSSH User’s Guide”. Once OpenSSH has been set up on the system, the following additional

steps must be followed in order to ensure that ICSF is being used in the proper manner:


13 | P a g e

Ensure that the sshd user on the system has READ access to the CSFIQA, CSF1HMG,

CSFOWH, CSF1TRC, CSF1TRD, CSFRNG, CSF1GAV, CSF1GKP, CSF1DVK, CSF1SKE,

and CSF1SKD profiles in the SAF CSFSERV general resource class.

In the OpenSSH server configuration file zos_sshd_config, apply the following configuration

settings:

o FIPSMODE = yes

o CiphersSource = ICSF

o MACsSource = ICSF

o KexAlgorithmsSource = ICSF

In sshd_config, set protocol keyword to 2 (to use SSHv2)

Configuring CA Common Services

In the evaluated configuration, CA Common Services is used to facilitate remote TCP/IP communications

for remote management and distributed administration.

CA Common Services is a distinct product from Top Secret so detailed instructions for its installation and

configuration are not here. However, you can reference the CA web guidance at https://docops.ca.com/ca-

common-services-for-z-os/14-1/en for information on how to set up and configure CA Common Services.

The “Common Communications Interface (CAICCI)” section of this guidance describes the CAICCI

component, which provides the communications interface to/from the mainframe system in detail. In

general, setup options can be chosen for the needs of the site, but in the evaluated configuration of Top

Secret, it is necessary to configure strong cryptography. In order to ensure that CA Common Services is

configured to use the correct cryptographic functions, ensure the following values are present in the

PARM field of the CCISSL and CCISSLGW configuration files:

PROT=TLS – forbids the use of SSL 3.0

CIPHERS=2F35 or 352F – allows only 128-bit AES with SHA-1 and 256-bit AES with SHA-1

ciphersuites (the two options indicate which cipher is higher on the priority list with 2F

representing 128-bit)

The following is CA Common Services configuration information to configure Top Secret /CPF. The

HOME node names in Top Secret /CPF corresponds to the SYSID in the CCS CCI definitions. Remote IP

addresses are supplied in the NODE and CONNECT definitions and the equivalent info for the HOME

node is in the PROTOCOL statement. In the example configuration information below, the CPF

connection between SYSA and SYSB is TCP/IP and the connection between SYSA and SYSC is VTAM.

CCI definitions for SYSA (highlighted statements are where SYSA/SYSB have been defined):

*

* CA EVENT NOTIFICATION/CCI PARAMETER FILE

*

*

* CA-ENF/CCI CONTROL OPTIONS

*

*

https://docops.ca.com/ca-common-services-for-z-os/14-1/en



14 | P a g e

SYSID(SYSA)

CCI(LINT)

SYSPLEX(CCIONE)

PROTOCOL(LU0,SYSAENF,1,SYSA,,)

PROTOCOL(TCPSSLGW,7000,1,SYSA)

NODE(LU0,SYSCENF,3,SYSC,,)

NODE(TCPSSLGW,141.202.999.41,3,SYSB,,)

CONNECT(SYSC)

CONNECT(SYSB)

LOGGER(245,243,120,Y)

CCI definitions for SYSB (highlighted statements are where SYSA/SYSB have been defined):

*

* CA EVENT NOTIFICATION/CCI PARAMETER FILE

*

*

* CA-ENF/CCI CONTROL OPTIONS

*

*

SYSID(SYSB)

CCI(LINT)

SYSPLEX(CCIONE)

PROTOCOL(LU0,SYSBENF,1,SYSB,,)

PROTOCOL(TCPSSLGW,7000,1,SYSB)

NODE(LU0,SYSCENF,3,SYSC,,)

NODE(TCPSSLGW,141.202.999.40,3,SYSA,,)

CONNECT(SYSC)

CONNECT(SYSA)

LOGGER(245,243,120,Y)

Establishing CPF Communications

In Top Secret’s evaluated configuration, the Command Propagation Facility (CPF) is used to transmit

administrative commands issued on one system to one or more remote nodes at the administrator’s

choosing. Once Top Secret is installed, CPF can be configured through the NDT record.


15 | P a g e

The Top Secret NDT record holds the options for CPF configuration such as CPFSYSID and CPFNODE

and the sub options for each of these.

CPFSYSID defines the Local node which would correspond to the SYSID as defined in the CCI PARMS.

Sub option such as CPFTARGET(*) would direct all Top Secret commands be propagated to all known

CPFNODE definitions on the local node.

CPFNODE defines all Remote CPF node definitions to the Local Node.

Sub option such as RECEIVE(ALL) specifies whether the local node can receive commands from the

remote node.

Additional instructions to configure and enable CPF communications are listed in the “Command

Propagation Facility” section of the web guidance, in the Using section.

5.7 Secure Usage Guidelines

The following section provides general guidelines for the secure usage of Top Secret in its evaluated

configuration once the installation and initial configuration has been completed. Some of this information

is related specifically to the administration of the TOE by specific security functions in the sections below

but all secure guidelines have been collected here as a summary.

The evaluated configuration does not include the following optional third-party components:

o EUA – Extended User Authentication (EUA) can make a requirement for some users to

be processed for additional authentication beyond the normal CA Top Secret User ID and

password validation, and enables other users to sign on without further user

authentication. Including this functionality requires a third party product, and additional

software that is plugged into a CA Top Secret optional component for use with Tokens /

Common Access Cards.

o Compliance Manager Integration – Compliance Manager allows Administrators to

collect, and report on security relevant activity, and generate alerts requiring action when

possible compliance violations occur. It has no security impact on the TOE and is not

included in the evaluated configuration of the TOE.

o CA Top Secret Option for DB2 UDB – CA Top Secret Option for DB2 UDB is outside

the scope of the evaluated configuration because it is used to provide fine-grained access

controls to database environments. In the evaluated configuration, the scope of the TOE

is limited to the access control functionality that mandated by the AC PP for host-based

access control, which does not include databases.

o DFSMS – DFSMS is an IBM designation for the DF/HSM, DFDSS, DFSORT,

DFRMM, and RACF products when used in a DFSMS system. It is not a necessary

component for CA Top Secret because the TOE contains its own security file to perform

the same functionality.


16 | P a g e

The tested environment did not include any of these components and their security impacts were

not considered. They should be used at your own risk.

The evaluated configuration specifically excludes the following capabilities:

o Group Logon Parameter – CA Top Secret only validates the use of the GROUP logon

parameter if the user specifies a group that is not the default specified in his user ACID.

This functionality is not commonly used for the current functions of the product and is

only supported for backward compatibility. The functionality provided by this is not

used for object access by the TOE.

o UADS or No UADS (User Attribute Data Set) – An obsolete feature that is not part of

the evaluated configuration. The advantages of bypassing UADS are faster logon

processing and eliminating the need to maintain both UADS and the security file.

o SYSPLEX – The coupling facility is a feature of z/OS that allows systems in a sysplex

environment to communicate and share data with each other. In the evaluated

configuration, CPF will be used to communicate with external systems.

o Non-FAIL Mode of operation – Top Secret provides a configurable security mode

option that affects the global enforcement of access control policy rules. As part of a

typical rollout process, administrators will typically escalate the security mode over a

period of time once they are certain the access control rules that are being put in place

will not adversely affect the behavior of the mainframe system. The TOE is not

considered to be in its evaluated configuration until it has been set into FAIL mode,

which is the only mode that will block access attempts that are not permitted by policy.

The use of these functions were either not tested or are known to put the product into an insecure

state. Therefore, the use of these functions is not supported operationally. More information about

the modes of operation is found in section 7 below.

Even while Top Secret is operating in FAIL mode, it will not control access to a resource unless

that resource is ‘known’ by Top Secret. If it is necessary to ensure that all objects on the system

are known by Top Secret and therefore protected on a deny-by-default basis, it is necessary to

define a set of permissions to the ALL record for a given resource type.

The following control options may adversely affect the ability of Top Secret to enforce the

functionality that is specified in the Security Target and should only be configured if there is an

overriding site-specific need that supersedes security concerns:

o BYPASS – allows the MSCA to request emergency bypass checking for an ACID.

o DOWN – allows BATCH, TSO, and other facilities to bypass access control policy

enforcement if Top Secret is unavailable. The default setting of

DOWN(BW,SB,TW,OW) is recommended.

o DUMP – dumps Top Secret memory space which may result in the disclosure of security-

relevant data

o FACILITY – the MODE sub-option allows Top Secret to be taken out of FAIL mode for

activities performed using the specified facility which is prohibited as stated above, the


17 | P a g e

LOCKTIME sub-option disables authentication failure handling on the specified facility

if set to 0, and NOAUDIT sub-option deactivates auditing for the facility

o HPBPW – allows Top Secret to honor an expired password for batch job submissions that

may have occurred while the password is still valid (it is recommended to use the JES

Early Verify feature of z/OS in order to validate the password at the time the job is

submitted rather than executed)

o JES(NOVERIFY) – deactivates JES Early Verify and requires username/password data

to be included on the job card

o LOG(NONE) – disables all logging for Top Secret

o MODE – can be used to globally set Top Secret’s operating mode to something other

than FAIL

o PTHRESH – used to specify the maximum number of failed password or password

phrase attempts that would trigger a lockout, setting this value to 0 would disable

authentication failure handling

For more information about the security impact of these control options, refer to “Understanding

Potential Misuse of CA Top Secret” in the Auditing section of the web guidance as well as the

control options definitions in “Specifying Control Options to Modify Your Security

Environment” in the Using section.

It is recommended that the PROMPT sub-option be set for the TSO facility (“TSS

MODIFY(FACILITY(TSO=PROMPT)”) to discourage users from entering their password data

in clear text at the TSO logon prompt.

Following install, it is the job of the MSCA to start owning and permitting resources that are

needed. The MSCA is the only ACID type that can create an SCA ACID type. The MSCA ACID

should create an SCA ACID type with all TSS admin authority to do the day to day

administration work. Since the MSCA is the only administrative account with unlimited

authority, its use should be limited to situations that an SCA ACID is not capable of resolving so

that the principle of least privilege is maintained.

Top Secret provides a configurable strength of secrets policy for user passwords and password

phrases. If the environment is configured such that the Top Secret security file is being populated

via an external LDAP server, the administrator must take care to ensure that Top Secret’s

password policy is not more restrictive than the policy that is enforced through LDAP

administration. An excessively restrictive password policy may prevent user changes from being

propagated to Top Secret.

By default, CPF journaling is not enabled. It is possible to audit the results of CPF activities by

reviewing the SMF/SYSLOG data on the target systems. However, if it is desired to review the

actual CPF transactions, it is necessary to enable CPF journaling. The instructions for enabling

CPF journaling are listed in the “CPF Journal Files” section of the web guidance under Using >

Command Propagation Facility.


18 | P a g e

The Top Secret security file supports both passwords and password phrases for user ACIDs. The

credential that is required to access the system is dependent on the configuration of the

application that is being used. If TSO is configured to accept passwords, then Top Secret will

evaluate the password credential that is supplied by the user.

If Top Secret is configured to receive user modifications through LDAP via, CA LDAP Server,

the LDAP server will interact with Top Secret to propagate user changes via the R_ADMIN

callable service. It is important to ensure that the proper facility permissions are given to allow

R_ADMIN to act as a sufficiently privileged control ACID on the system in order for it to be able

to modify the security file.

Customers must take care to ensure that any external components that interface indirectly with

Top Secret (such as an enterprise identity and credential management product that is used to

synchronize Top Secret’s security file with an organizational LDAP repository) are using a least

privilege model in order to minimize the number of potential administrators that have the ability

to manipulate user ACID data.

Top Secret provides many ways to override access control policies as written, either to

automatically grant or automatically deny access to a requested object on the system. In the

evaluated configuration, only the following bypass methods are supported:

o Use of the NORESCHK, NOVOLCHK, NODSNCHK, NOSUBCHK, and NOLCFCHK

user attributes to bypass DATASET, VOLUME, JESJOBS, and LCF rule checking for

specified ACIDs.

o Use of the SUSPEND attribute to block an otherwise authorized ACID from gaining

system entry.

Any other settings or options that can be used to bypass defined access control policy rules should

not be used unless you willingly accept the risk of deviating from the product’s evaluated

configuration.

It is possible for job cards to contain user credential data. While this data is not stored by Top

Secret, careless handling of credential data may allow an unauthorized user to gain access to an

account that they are not intended to use. Password data should not be displayed on system

objects unless absolutely necessary, such as in the case of surrogate job submission. In these

cases, administrators should take great care to ensure that unauthorized users cannot view any

password data that is contained on the job card.

In general, Top Secret contains a large number of features and options that are outside of the

scope of the claimed Protection Profiles and were considered to be non-interfering components

for the purpose of the Common Criteria evaluation. No security claim is made on these functions

but there is nothing explicitly preventing their use. Consult the Bookshelf for detailed

descriptions of these features as needed and verify that they do not conflict with any of the

security functions described in this supplemental guidance.

Top Secret is expected to be operated in an enterprise environment where the Command

Propagation Facility (CPF) is used to administer multiple systems or LPARs. All administrative

guidance for managing user ACIDs and access control policy rules can be followed in a CPF

environment. Refer to the “Command Propagation Facility” section of the web guidance under


19 | P a g e

Using for more information about CPF and the syntax used to execute commands that are

targeted to remote nodes.

There are many options to control what system activities are or are not audited by Top Secret. By

default, all rule violations are audited. The LOG(NONE) sub-option of the FACILITY control

option can be used to override this for any given facility but this is not permitted in the evaluated

configuration. Administrators can optionally specify the permitted access attempts that are

audited by adding ACTION(AUDIT) to PERMIT rules on a per-rule basis.

6 Administration by Security Function

This section provides instructions and documentation for how to administer all of the SFRs that were

claimed by the TOE as part of its Common Criteria evaluation. The following documentation defines the

claimed SFRs:

Standard Protection Profile for Enterprise Security Management Access Control, version 2.1 [AC]

Standard Protection Profile for Enterprise Security Management Policy Management, version 2.1

[PM]

This documentation includes an overview of the level of detail at which each SFR should be discussed in

the TOE’s operational guidance. Note that in the following sections, SFRs labeled with [AC] were

originally defined in the Access Control Protection Profile, those labeled with [PM] were originally

defined in the Policy Management Protection Profile, and [AC+PM] indicates those SFRs that are defined

in both Protection Profiles.

6.1 Enterprise Security Management

[PM]ESM_ACD.1 – Access Control Policy Definition:

In the evaluated configuration, CA Top Secret was tested interactively using mainframe’s command-line

interface (CLI) and submitted batch jobs. The documentation on how to manage access control policies

for Top Secret using each of these interfaces can be found at the following locations:

- CLI: commands to configure Top Secret all begin with TSS. The “Creating and Setting Up

Users” section of the web guidance provides instructions for how to manage users and groups.

The “Setting up Resource Definitions and Ownership” section provides instructions for how to

define ownership for objects on the system to define them as protected resources. The

“Controlling Access” section provides instructions on how to restrict system entry, which is

synonymous with devising an access control policy for the underlying system’s authentication

function. Finally, the “Protecting Resources” section describes how to write access control rules

to assign various users and groups the ability to interact with protected resources. Examples and

syntax of the relevant TSS commands for these activities are distributed throughout the

referenced sections.

- Batch: collections of CLI commands can be issued using batch jobs. These jobs can be submitted

using JES2 as with any other set of mainframe commands. The only special guidance for issuing

batch commands is that when entering keywords, it is necessary to follow the last keyword on a


20 | P a g e

continuing line with a blank and a dash. The next keyword can then be entered on the next input

line.

All of the types of access control rules that can be written for Top Secret are summarized in the

“Controlling Access” and “Protecting Resources” sections of the web guidance under Using. A summary

of all command functions that are available in Top Secret is provided along with example syntax in the

“Keywords” section of the web guidance, which is under Using > Issuing Commands to Communicate

Administrative Requirements. In the evaluated configuration, the Top Secret product includes both access

control functionality and the ability to manage access control functionality, so there are no potential

compatibility concerns with a third-party product being used to configure the TOE’s access control

functionality.

Each individual system or LPAR that runs an instance of Top Secret is limited to having a single access

control policy enforced on it. Therefore, a given access control policy can be identified by the SYSID of

the system or LPAR on which that instance of Top Secret is running. There are no unique identifiers for

the individual rules within the policy.

[PM]ESM_ACT.1 – Access Control Policy Transmission:

As stated in [PM]ESM_ACD.1 above, access control policies can be created or updated using individual

TSS commands or collections of them issued as batch jobs. By default, the access control policy is

applied to the same system or LPAR on which the commands were issued. However, it is possible to

simultaneously configure remote nodes through the use of the Command Propagation Facility (CPF). CPF

is described in the “Command Propagation Facility” section of the web guidance.

In general, when a command is issued via CPF, Top Secret immediately attempts to propagate the

command to the remote nodes that CPF is configured for. A CPF command can be sent synchronously or

asynchronously using the CPFWAIT(YES) (synchronous) or CPFWAIT(NO) (asynchronous) parameter,

with asynchronous being the default behavior if not explicitly specified. When sent synchronously, if the

command fails to propagate to any of the target systems, the sending node will be non-interactive until the

command has successfully propagated to all target nodes. This ensures that all nodes are synchronized

before further commands are issued. When sent asynchronously, the command will be executed on all

target systems that it is able to. If there are any systems that it cannot be executed on, the command will

be queued by CPF and will attempt to retransmit the command to the target(s) every minute until it

succeeds. This occurs in the background so an administrator can continue to interact with Top Secret

while this occurs.

If desired, CPF commands can be configured to be executed on a periodic basis via batch jobs that can be

scheduled at intervals of the administrator’s choosing. The scheduling and execution of these batch jobs is

a native function of z/OS and is not handled by Top Secret.

[PM]ESM_ATD.2 – Subject Attribute Definition:

Top Secret defines subject attributes in records known as accessor IDs, or ACIDs. There are several types

of ACIDs, each of which are applicable to subject attribute definition, as follows:

Organizational ACID: defines organizational units that can be designated as having ownership of

system resources. Organizational ACIDs are strictly hierarchical, with departments at the bottom


21 | P a g e

level, divisions above that, and zones at the top. This allows for a pre-defined hierarchical

grouping of resource ownership.

Profile ACID: functions similar a group and can be granted permissions to a resource so that any

user ACID that is assigned the profile ACID can inherit those permissions.

User ACID: contains attribute data for an individual user account. A user ACID must belong to a

department-level ACID but is not required to be assigned to any profile ACIDs.

Control ACID: similar to a user ACID except that the control ACID grants some degree of

authority to administer Top Secret, depending on the ACID type and its configuration.

All of these types of ACIDs along with syntax for creating and modifying them are described in detail in

the “Creating and Setting Up Users” section of the web guidance and the explicit parameters associated

with each command is provided in the “Command Functions” section of the web guidance under Using >

Issuing Commands to Communicate Administrative Requirements. In particular, the TSS CREATE, TSS

ADDTO, TSS REMOVE, and TSS DELETE commands are used to create ACIDs, delete ACIDs, and

add and remove attributes to/from them. TSS MOVE is used to reassign an ACID to a different

organizational segment or promote the ACID to an SCA. TSS RENAME is used to change the user

ACID’s own name attribute. The TSS ADMIN and TSS DEADMIN commands are used to grant and

revoke administrative authorities.

The “Keywords” section of the web guidance lists all possible attributes that can be assigned to ACIDs.

There are several attributes that are relevant to the claimed Protection Profiles. They are as follows:

AUDIT: ACIDs with the AUDIT attribute set have all actions audited, regardless of the audit

settings for rules pertaining to those actions.

SUSPEND: ACIDs with the SUSPEND attribute set are not authorized to log in to the system.

FACILITY: governs which facilities (e.g. TSO) an ACID is authorized to use to access the

system. More information about this attribute can be found under “Restrict Access by Facility” in

the “Controlling Access” section of the web guidance.

Resource checking bypass attributes (NORESCHK, NODSNCHK, NOVOLCHK, NOSUBCHK,

NOLCFCHK): allow ACIDs to override resource, data set, volume, job submission, and limited

command facility checking rules accordingly. Specific information regarding these attributes is

described in “Bypass Resource Checking” in the “Protecting Resources” section of the web

guidance.

In general, resource checking bypass gives a user ACID a great deal of access to the mainframe so its use

is not recommended unless there is a specific operational need for it.

[PM]ESM_EAU.2 – Reliance on Enterprise Authentication:

Top Secret does not provide a logon mechanism independent of what is facilitated by z/OS. In other

words, an interactive user that wishes to administer Top Secret must log in to the mainframe system using

the interface of their choosing (TSO, VTAM, batch, etc.) prior to issuing any administrative commands

for Top Secret. However, since both the user data on the mainframe and the ability to use the

authentication function is administered by Top Secret, Top Secret is responsible for determining if an

authentication attempt should be permitted.

In the evaluated configuration, administrator and user authentication was performed using password and

password phrase authentication. Authentication credentials will be supplied either at system entry (initial


22 | P a g e

logon) or in a job that one user account can execute on behalf of another. The “Managing Passwords and

Password Phrases” section of the web guidance provides information on how to configure account

passwords and password phrases.

[AC+PM]ESM_EID.2 – Reliance on Enterprise Identification:

There is no specific operational guidance prescribed by the claimed PPs for this SFR.

6.2 Security Audit

[PM+AC]FAU_GEN.1 – Audit Data Generation:

Top Secret logs all activities related to its configuration and use to SYSLOG and/or SMF on the local

operating system. Specifically, SYSLOG records user authentication events, startup messages, and

modification of control options (i.e. TSF configuration that is issued using ‘F TSS’ commands). SMF logs

rule checking but also records configuration activities as well.

SYSLOG messages are generated in a format that is consistent with IBM’s specification of the file format

as demonstrated in the following example:

M 8000000 SYSL 13237 14:00:20.23 STC04428 00000090 IEF403I FTPD –...

| | | | | | | | |

| First | | Time | User exit | |

| 28 | | | flags | Message text

| routing | Julian | |

| codes | date | |

| | Console name, Message ID

| System name jobid, or

| multi-line ID

Record type

and Request type

(originally published at http://www-

01.ibm.com/support/knowledgecenter/SS9M7K_1.1.0/com.ibm.zoslasyslog.doc_110/topics/zla_syslog_c

onfiguration.html)

The following is a sample set of SYSLOG output from Top Secret showing an invalid authentication

attempt to a system due to an invalid password. Note that the date, time, subject, event, and outcome are

all included in the audit records. The Julian date is parsed as YYDDD which means that the Julian date of

17150 in the example below is the 150th day of 2017, or May 30th.

N 0080000 XE14 17150 10:17:59.05 00000090 TSS7100E 009

J=QAENT01 A=QAENT01 T=A01TD002 F=TSO - INCORRECT PASSWORD

The following example shows a SYSLOG record of Top Secret’s startup, which is synonymous with the

start of the auditing function since Top Secret’s auditing cannot be enabled or disabled separately from

the product:

N 4040000 XE14 17150 09:20:10.16 00000090 *TSS2000I CA TOP

SECRET MSTR INITIALIZATION IN PROGRESS

N 4040000 XE14 17150 09:20:10.16 00000090 *TSS2001I CA TOP

SECRET MSTR INITIALIZATION COMPLETE

http://www-01.ibm.com/support/knowledgecenter/SS9M7K_1.1.0/com.ibm.zoslasyslog.doc_110/topics/zla_syslog_configuration.html




23 | P a g e

N 8000000 XE14 17150 09:20:10.36 00000090 TSS2069I Subsystem

TSS is Active

The following example shows a SYSLOG record of administratively configuring Top Secret. Note that

this command was issued via CPF so additional logs showing the establishment of CPF communications

have been included.

N 40A0000 XE36 17152 13:38:33.68 STC00142 00000090 TSS9849I CPF

Processing Activated

N 0020000 XE36 17152 13:38:33.68 STC00142 00000090 TSS9810I

COMMUNICATIONS ESTABLISHED WITH NODE XE18

N 0020000 XE36 17152 13:38:33.68 STC00142 00000090 TSS9810I

COMMUNICATIONS ESTABLISHED WITH NODE XE14

NC0000000 XE36 17152 13:42:55.78 CPFUSR2 00000290 F TSS,PTHRESH(111)

N 0000000 XE36 17152 13:42:55.79 STC00142 00000090 TSS9070I OKAY

The console/jobid values differ because ‘CPFUSR2’ is the ACID used to execute the operator command

whereas STC00142 is the started task associated with CPF.

SMF records generated by Top Secret are formatted as Type 80 records. The formatting of this record

type is described under “SMF Type 80 Record Layout” in the web guidance under Reporting > TSSUTIL

Utility. Top Secret provides several reporting utilities as mechanisms to parse SMF audit data, such as

TSSUTIL and TSSAUDIT. Listed below are the types of auditable events that are logged to SMF along

with representative examples of the audit data.

TSSUTIL – shows access attempts made to datasets and resources protected by Top Secret:

DATE TIME SYSID ACCESSOR JOBNAME FACILITY MODE VC PROGRAM R-ACCESS A-ACCESS

SRC/DRC SEC JOBID TERMINAL

06/01/17 11:33:54 XE36 CPFUSR2 CPFUSR2 TSO FAIL 01 ISPTASK READ

*08*-65 OPN T000136 A01TD002

RESOURCE TYPE & NAME : DATASET SYS1.PARMLIB

MVXE36

05/30/17 09:48:12 XE36 STRTE01 STRTE01 TSO FAIL IKJEFT09

OK+A LCF T000049 A01TD001

RESOURCE TYPE & NAME : PROGRAM EXEC

The DATE, TIME, ACCESSOR, RESOURCE TYPE & NAME, R-ACCESS, and SRC/DRC

fields demonstrate the date, time, subject, object, operation, and result of each access attempt. The

various fields in the output are listed and described in more detail under “TSSUTIL Report

Description” in the web guidance under Reporting > TSSUTIL Utility.

TSSAUDIT – shows execution of administrative ‘TSS’ commands which may result in creating

or modifying elements of the Top Secret Security File, which includes its access control policy

rules and its ACIDs:

CHANGER DATE TIME SYSID TYPE COMMAND/IMAGE

KORDI01 02/14/14 10:23:46 XE14 CMND TSS CREATE(TEDMON) DEPT(QADEPT1) TYPE(USER) NAME('TED MON')

KORDI01 02/14/14 10:24:42 XE14 CMND TSS ADD(MASTER) DSN(PAY)


24 | P a g e

KORDI01 02/14/14 10:25:12 XE14 CMND TSS PER(TEDMON) DSN(PAY.MSTR) LIB(SYS1.UTY) PRI(PAY60)

Information about the various fields shown here is provided in the “Sample TSSAUDIT Listing

of Changes” section in the web guidance under Reporting > TSSAUDIT Utility.

Top Secret can also be configured to use the Audit/Tracking File instead of (or in addition to) SMF for

the log data that is recorded by SMF. The content and formatting of the data in the Audit/Tracking file is

identical to the data that is written to SMF. In the evaluated configuration, SMF is expected to be used so

that environmental audit data can be transferred to a remote storage location where it can be aggregated

with other SMF data to provide auditors the ability to view logs for multiple systems and applications as a

whole.

In addition to this, Top Secret can record inbound/outbound CPF requests and the responses to them in

datasets that are marked as CPF journal files. CPF uses one journal file for each remote node defined to it

through the CPFNODES control option, plus one journal file for all incoming traffic. The node-specific

journal files have a DDname equal to the node name, and the DDname for incoming traffic is

RECVCMDS. It is recommended that these DDnames not be defined in the CA Top Secret JCL stream.

If a given DDname is missing, CPF dynamically allocates the journal file. If dynamic allocation fails,

CPF continues the operation but does not perform the journaling for the associated node.

CPF journal entries are formatted in the manner specified in the example below:

17151 104017 TO: XE14 ID: 000000023 ISSUED BY: STRTE01

17151 104017 TSS PER(CPFUSR2) DSN(SYS1.PROCLIB) ACCESS(READ) TARGET(=,XE14)

WAIT(Y)

17151 104018 FR: XE14 ID: 000000023

17151 104018 TSS0300I PERMIT FUNCTION SUCCESSFUL

The first two fields represent Julian date and time of the event (HHMMSS), followed by command that

was transmitted. The TARGET field identifies the SYSID of the recipient. The recipient then sends a

response if the command is executed. If the command is not executed an error such as ‘TSS9816I

REMOTE MACHINE NOT ACCEPTING COMMANDS FROM THIS NODE’ is returned.

Information about auditing, the types of events that are audited, methods of reviewing the audit data, and

recommended best practices for audit behavior are discussed in the following documentation references in

the web guidance:

The “Auditing” section

The “Reporting” section

“Logging System Events and Violations” under the “Using” section

Note again that these general documentation references may discuss product functionality that is

outside the scope of the Security Target. Reference the Security Target and section 4.1 of this

document for information about the functions that were tested as part of the evaluation.

[AC]FAU_SEL.1 – Selective Audit:

By default, all activities that are recorded to SYSLOG are logged by Top Secret, no configuration is

required in order to allow this behavior, and there is no method of disabling this. Similarly, all access

control rules that are logged to SMF (and/or the Audit/Tracking File) will be logged by default while Top


25 | P a g e

Secret is running in FAIL mode if their application results in an access attempt being denied. If it is

desired to log authorized accesses, there are two ways that this can be configured:

- Include the ACTION(AUDIT) parameter in the TSS PERMIT statement defining the rule for

which auditing is desired

- Apply the AUDIT attribute to the ACID(s) that are to be monitored

In the web guidance, the sections “Logging the System Events and Violations,” “ACTION

Keyword—Assign Actions,” and “Auditing” specify how ACTION(AUDIT) can be used.

Administrators with the MISC9 authority are able to apply the AUDIT attribute to ACIDs. See

“Creating Security Administrators” in the web guidance and section 6.6 of this document for more

information about administrative authorities.

[PM]FAU_SEL_EXT.1 – External Selective Audit:

Because Top Secret provides access control and policy management capabilities in a single product, the

function for the access control capability receiving instructions on what auditing to perform and the

function for the policy management capability directing the access control capability on what auditing to

perform are identical, so this functionality is discussed in the preceding section.

[AC]FAU_STG.1 – Protected Audit Trail Storage (Local Storage):

Audit data that is generated by Top Secret is written to SYSLOG and SMF on the local system, both of

which are components of z/OS that process audit data for various system components. Therefore, any

transmission of audit data from these facilities on the local system to a remote server or other repository is

at the discretion of the system administrator and is not mediated by Top Secret. Note however that since

the SYSLOG and SMF data reside as data sets on the local system, Top Secret can be used to protect this

data from unauthorized access while it resides locally.

Similarly, Top Secret can write audit data to its own Audit/Tracking File instead of or in addition to SMF.

This file is part of Top Secret but still exists as a data set object on the z/OS system. Therefore, any

backup or transfer of this data is also the responsibility of Top Secret’s operational environment.

However, access to the Audit/Tracking File is protected by Top Secret as part of its default self-protection

access control policy.

[AC+PM]FAU_STG_EXT.1 – External Audit Trail Storage:

Top Secret transmits all audit data outside its boundary to the SYSLOG and SMF audit storage on the

local system. Remote backup/storage of this data is the responsibility of the system administrator and is

facilitated by z/OS in general and is not a specific function that is provided by Top Secret.

In a CPF environment, CPF journal entries will be written to datasets on the systems where the CPF

commands were sent/received. However, this data is used primarily for debugging of connection issues or

other errors that may cause CPF commands to fail to propagate. In practice, SYSLOG and SMF data can

be aggregated in a single location and activity across multiple systems can be tracked through the fact that

the audit data includes the SYSID where it was generated and the use of CPF requires an administrator to

have a uniform user ACID on multiple systems.


26 | P a g e

In all cases, the act of audit data being transmitted from within the TOE boundary to the audit storage that

is used by the system on which the TOE is deployed is an example of inter-process communication that is

contained to that system so the communications channel is assumed to be secure.

6.3 Communications

[AC]FCO_NRR.2 – Enforced Proof of Receipt:

Top Secret provides the ability to administer remote systems or LPARs through the use of the Command

Propagation Facility (CPF). CPF is described in detail in the “Command Propagation Facility” of the web

guidance. In the evaluated configuration, CPF journaling will be enabled so that there is a record of the

success or failure of CPF commands (i.e. whether or not they were successfully received and processed

by the target node(s)). Additionally, the activities will be logged on the target node(s) as configuration

changes if the CPF commands are received. The instructions for enabling CPF journaling and sample

formatting of the CPF journal entries is listed in the “Command Propagation Facility” section of the web

guidance under “CPF Journal Files”.

6.4 User Data Protection

[AC]FDP_ACC.1(1) – Access Control Policy:

The claimed Protection Profiles do not require any discussion of this SFR in the operational guidance.

This SFR defines the access control SFP, which has its behavior described under [AC]FDP_ACF.1(1)

below.

[AC]FDP_ACC.1(2) – Access Control Policy:

The claimed Protection Profiles do not require any discussion of this SFR in the operational guidance.

This SFR defines the self-protection access control SFP, which has its behavior described under

[AC]FDP_ACF.1(2) below.

[AC]FDP_ACF.1(1) – Access Control Functions:

Top Secret receives policy data locally via CLI commands and/or batch jobs. If configured to receive

policy data remotely, the CPF commands are received and parsed and processed as if they were CLI

commands. There are two types of rules that are enforced by Top Secret: rules governing system entry,

which are described in the “Controlling Access” section of the web guidance, and rules that control the

level of access that users can have over objects on the system, or resources. Resource rules are described

in the web guidance under “Protecting Resources”. In addition to these references, the syntax for defining

rules along with the parameters and allowable values is described in the “Keywords” section of the web

guidance.

When a user attempts to log in to the system, the DAYS, TIMES, FOR, UNTIL, CALENDAR, and

TIMEREC parameters can be used to govern whether or not the login attempt is authorized based on time.

The user must also be using an application (facility) that Top Secret authorizes them to use. Regardless of

rules authorizing a user’s access to the system, they are prevented from logging in if the SUSPEND

attribute is set on their ACID.

Top Secret operates in a deny-by-default posture for resources that are designated as protected, with the

exception of administrative commands. Administrative commands are authorized unless a Limited


27 | P a g e

Command Facility (LCF) rule prohibits their execution. This does not guarantee that the command will

execute successfully because the user may not have authority to modify a resource that is affected by the

command; LCF is used to prohibit users from executing all commands of a certain type.

A protected resource is an object that has at least one resource rule that applies to it. A resource that is not

protected does not have any access control rules applied to it, and access to the resource is allowed by

default. If a resource rule identifies the object with a wildcard, any matching object would be considered a

protected resource. Therefore, it is important to define a base set of resource rules that protect a broad set

of objects on the system so that an appropriate level of access control is enforced on the system. For

example, the existence of a dataset rule restricting access to all datasets with the high level qualifier

ABC.* will mean that a newly created dataset ABC.XYZ is automatically designated as a protected

resource even though there is no rule that controls access to it specifically. The process for defining

objects on the system as protected resources, including establishing a default level of protection, is

described in the “Setting up Resource Definitions and Ownership” section of the web guidance.

Resources can be owned by either user ACIDs or organizational ACIDs. If a user ACID owns a resource,

that user has unrestricted access to the resource. If an organizational ACID owns a resource, user ACIDs

that do not belong to the same organizational hierarchy as the owner cannot have any access granted to

that resource, regardless of what rules are defined. All resources have owners, with the exception of

commands. To assign an owner to a resource, the command ‘TSS ADDTO(<owner>) <resource

type>(<resource name>)’ is used.

In general, when a resource rule allows a user to perform a given operation, the user is only granted

permissions to perform that specific option. However, there are two instances where granting one type of

access implicitly grants additional access, as follows:

If an ACID is granted write access to a resource, both read and fetch access are implicitly

granted.

If an ACID is granted create access to a resource, read access is implicitly granted.

Top Secret applies a rule processing engine in order to determine the best fit rule to apply to a user

request in the event of potentially contradictory rules (such as one that grants write access and another

that only grants read access). The rule processing engine is described below.

When checking for authorizations, those that apply to the user ACID are checked first, followed by the

assigned profile ACIDs, followed by the ALL record. The profile ACIDs associated with a user have their

precedence defined in a strict order. When configuring the user ACID, the administrator can specify the

order in which the profile ACIDs should apply. Depending on how Top Secret is configured, the selection

algorithm may return the first match or it may return the best match. The AUTH control option

determines how the record ordering is applied, as described below:

OVERRIDE (default setting): The TOE checks each ACID record one by one. As soon as a

PERMIT rule is found, it is evaluated against the request and a decision is returned.

MERGE/ALLOVER (or simply MERGE): The TOE checks the user ACID record along with

every applicable profile ACID record and returns a decision based on the best match. If no

PERMIT rule is found in any profile ACID record, it checks the ALL record.


28 | P a g e

MERGE/ALLMERGE: The TOE checks the user ACID record. If no PERMIT rule is found, it

merges every profile ACID record along with the ALL record and returns a decision based on the

best match.

For example, if a user wishes to update a dataset that their user ACID only has READ access to, but they

are assigned a profile ACID that gives them UPDATE access to the same dataset, a setting of

OVERRIDE would prohibit this since the rule selection algorithm returns the privilege level of READ. If

the same request was made with the MERGE control option applied, the request would be authorized

because both the user and profile authorizations are checked before returning a decision. Similarly, if the

ALL record defines a privilege level of UPDATE for a dataset and a user’s profile ACIDs only give the

user READ access, a setting of MERGE will cause the update attempt to be rejected while a setting of

MERGE/ALLMERGE would incorporate the ALL record before making an access control decision and

would authorize the requested update as a result. The AUTH control option is specified by issuing the

command ‘F TSS,AUTH(<desired setting>)’.

Object name: The Top Secret security validation algorithm processes object names in order from most

specific to least specific. For example, a specific dataset name is considered to be the most specific type

of dataset object (e.g. “EXAMPLE.DATASET”), followed by a dataset name that uses masking

characters (e.g. “EXAMPLE.DATA*”), followed by the high level qualifier used to identify the dataset

(e.g. “EXAMPLE”). Note that if the ownership of an object is defined by its exact name, masking

characters cannot be used in access rules that apply to it. More information about masking and the syntax

used to represent various masking types is described in the “Masking” section of the web guidance under

Using > Setting up Resource Definitions and Ownership.

Source of origin restriction: If an ACID has a valid SOURCE entry defined and a PERMIT rule defines

a different TERMINAL that the ACID is authorized to use that is not present in the SOURCE entry, the

SOURCE entry takes priority and the access will be rejected.

Auditing: If any applicable rule has the ACTION(AUDIT) attribute set, the access will be audited,

regardless of whether any other applicable rules have this attribute set.

Order of operations: If two rules with the same level of specificity apply to an operation, the more

permissive rule takes precedence unless the rule evaluates to ACCESS(NONE) or ACTION(DENY)

ACIDs can also be assigned bypass attributes to grant unconditional access to different types of objects on

the system, listed below. Bypass attributes are not recommended for normal operation and should

primarily be used for troubleshooting purposes.

NORESCHK – bypass all rules EXCEPT for DATASET and VOLUME.

NOVOLCHK – bypasses all rules of type VOLUME. Does not bypass DATASET rules unless

NODSNCHK is also applied.

NODSNCHK – bypasses all rules of type DATASET.

NOSUBCHK – bypasses all rules of type JESJOBS.

NOLCFCHK – bypasses all rules of type LCF.

These attributes are assigned to ACIDs using the standard administrative commands for ACID

modification.

[AC]FDP_ACF.1(2) – Access Control Functions:


29 | P a g e

By default, Top Secret enforces self-protection to ensure that an untrusted user cannot terminate,

reconfigure, or bypass it. As stated above, all system objects that are affected by resource rules are

considered to be protected resources and access controls operate on a deny-by-default basis. Out of the

box, Top Secret defines resource rules on its own components that only allow the MSCA administrator to

access them. All other access is forbidden. Since the MSCA is the same account that is established by

default when Top Secret is first deployed, it is assumed to belong to a trusted administrator. The

components that are automatically protected are as follows:

Security File (both primary and backup)

Audit File

Recovery File

All FACILITY entries (required for logon)

All datasets that comprise Top Secret

All administrative ‘TSS’ commands

Top Secret protects against tampering by performing a periodic integrity check of its own components.

Data used to make access control decisions is stored in Key 3 which minimizes the risk of overwrite. For

more information about Top Secret’s tamper protection refer to the “Tampering” section in

“Understanding Potential Misuse of CA Top Secret” in the web guidance.

6.5 Identification and Authentication

[PM]FIA_AFL.1 – Authentication Failure Handling:

The ability to lock out user accounts due to an excessive number of authentication failures is defined in

the PTHRESH control option. The total number of authentication failures for both passwords and

password phrases are stored cumulatively and the offending user ACID is locked out once the PTHRESH

value is reached. As stated in the “Specifying Control Options to Modify Your Security Environment”

section of the web guidance, the default PTHRESH value is 4 but it can be set to any value between 1 and

254. When the user ACID is locked out in this manner, the SUSPEND attribute is set. The only way to

allow the user ACID to regain access to the system is for an authorized administrator to change the user’s

password or password phrase, or to manually remove the SUSPEND attribute from the user ACID.

By default, the MSCA account cannot be suspended due to authentication failure. This is to prevent a

malicious user from causing a denial of service of the system by rendering all user accounts inaccessible

for an indefinite period of time. In order to override this default setting, the MSUSPEND control option

can be set to YES.

[PM]FIA_USB.1 – User-Subject Binding

Top Secret associates users with mainframe subjects through the use of the user ACID. The user ACID

user name, assigned profile ACIDs (group memberships), any administrative role, assigned department,

and any other special attributes that affect the user’s ability to perform actions on the system such as the

AUDIT or SUSPEND attribute. Information about user ACIDs and the associated attributes is provided in

the “Creating and Setting Up Users” section of the web guidance. When a user logs in to the system, their

ACID and all rules that apply to them are compiled into a security record, or secrec. This associates the

mainframe user with the attributes that govern their ability to interact with the system and the resources

that reside on it.


30 | P a g e

Additionally, Top Secret has the ability to allow an external LDAP server to synchronize its contents with

Top Secret’s security database so that Top Secret can exist in an enterprise environment where user

identities are centrally defined. In the evaluated configuration, CA LDAP Server is used as a repository

for user data that is capable of translating LDAP protocol activities into equivalent Top Secret commands.

CA LDAP Server then interfaces with the mainframe through the use of the R_ADMIN callable service

(provided by IBM as part of z/OS) and Top Secret processes the commands accordingly.

6.6 Security Management

[PM]FMT_MOF.1 – Management of Functions Behavior:

By default, Top Secret comes with one initial administrative role, known as the MSCA. The MSCA role

has full control over the system and is used to perform the initial setup of organizational ACIDs and

administrative roles, which are also known as control ACIDs. All control ACIDs are based on scope, as

follows:

SCA: has scope over all zones

LSCA: has scope over one or more zones

ZCA: has scope over one zone

VCA: has scope over one division

DCA: has scope over one department

A control ACID has scope over its assigned organizational ACID(s) as well as any organizational ACIDs

that are hierarchically beneath them. For example, a ZCA has scope over all divisions and departments

within their assigned zone. When a user is created, it is created with either a user ACID or a control

ACID. Users ACIDs and scoped control ACIDs can be promoted to or demoted from SCA using the TSS

MOVE command.

By default, each type of control ACID has certain privileges to perform management functions, as

follows:

SCA: can perform any function except creating MSCAs or SCAs

LSCA: can perform any function that SCA can perform, but only within the zone(s) that they

have scope over.

ZCA: can manage user ACIDs, control ACIDs, and access rules for subjects and objects within

their assigned zone.

VCA: can manage user ACIDs, control ACIDs, and access rules for subjects and objects within

their assigned division.

DCA: can manage user ACIDs, control ACIDs, and access rules for subjects and objects within

their assigned department.

Individual control ACIDs can also be granted privileges that are typically only available to SCAs if

desired. Within the control ACID’s assigned scope, ability to perform administrative activities above and

beyond what is available by default is derived from privileges, which are grouped into fixed collections

called administrative authorities. An administrative authority can be granted to a control ACID in its

entirety, or single privileges within the administrative authority can be granted individually if more

granular permissions are desired. The administrative authorities and the privileges that they contain are

described in the “Assign Administrative Authority” section of the web guidance. Note that regardless of


31 | P a g e

an administrator’s privileges, they cannot grant privileges that they do not have, and they cannot modify

any user or control ACIDs that are hierarchically above their scope of control. Even if an LSCA is

granted scope over every zone defined by Top Secret, they are still considered to be hierarchically below

an SCA, and an SCA is considered to be hierarchically below the MSCA.

[AC]FMT_MOF.1(1) – Management of Functions Behavior:

For local administration, there is no association that needs to be made between Top Secret’s policy

management and access control capabilities since they are provided as part of the same product.

[AC]FMT_MOF.1(2) provides information on what needs to be set up in order to use CPF.

Instructions for administering specific TOE functions can be found in the following sections of this

guidance:

Audited events: [AC]FAU_SEL.1

Repository for remote audit storage: [AC]FAU_STG_EXT.1

Access Control SFP: [AC]FDP_ACC.1(1)

Policy being implemented by the TSF: [AC]FDP_ACF.1

Access Control SFP behavior to enforce in the event of communications outage: [AC]FPT_FLS_EXT.1

[AC]FMT_MOF.1(2) – Management of Functions Behavior:

In order for a system to accept CPF commands from a remote node, the environmental CA Common

Services component must be present on the system. CA Common Services is responsible for handling

secure communications channels between remote nodes (including how the individual nodes trust one

another). The system from which CPF commands originate must be configured to specify the nodes that

the CPF commands will be transmitted to, and the recipients of these commands must identify the origin

point. This is done through configuration of the Node Descriptor Table (NDT) on the sender and any

recipients.

When Top Secret receives a CPF command from a remote node, the identity of the system is verified

before the CPF command is applied; any sort of validation of the system’s identity is handled by CA

Common Services so the asserted identity is assumed to be valid by Top Secret once the CPF command is

received.

[PM]FMT_MOF_EXT.1 – External Management of Functions Behavior:

Instructions for using Top Secret to establish CPF communications are provided in the “Command

Propagation Facility” section of the web guidance. Configuration of the environmental CA Common

Services component to define the trust relationship between distributed nodes as a prerequisite for doing

this is described in the CA Common Services web guidance (https://docops.ca.com/ca-common-services-

for-z-os/14-1/en).

When using CPF, keep in mind that the administrator issuing the CPF commands must have appropriate

permissions on each of the remote nodes in order for the commands to be executed; appropriate

permissions on the originating node is not sufficient to allow the administrator to configure remote nodes.

[AC]FMT_MSA.1 – Management of Security Attributes:




32 | P a g e

The security-relevant attributes of Top Secret’s access control capability are the individual policy rules

that are used to govern access to objects on the mainframe system that are protected by Top Secret as well

as access to the system itself. The “Controlling Access” and “Protecting Resources” sections of the web

guidance are sufficient to describe the procedures for how to administer these policy rules. The “Creating

and Setting Up Users” section defines the ability to grant administrative capabilities to users by assigning

their user ACID to a control ACID, and “Creating Security Administrators” defines the various types of

control ACIDs, their scope, and how to grant administrative privileges to them.

[AC]FMT_MSA.3 – Static Attribute Initialization:

In the evaluated configuration, Top Secret must be configured into FAIL mode in order to enforce the

defined access control policy rules. This is performed by issuing the command ‘F TSS,MODE(FAIL)’ .

Top Secret provides several other modes that allow the product to operate in a more permissive security

posture, but these are not part of the evaluated configuration and should not be used in an operational

context. Refer to section 7 of this document or the “Assigning Security Modes” section of the web

guidance under Using for more information about these modes.

[PM]FMT_MSA_EXT.5 – Consistent Security Attributes:

When a user first logs in to a system protected by Top Secret, Top Secret will evaluate all rules that apply

to them in order to define a single set of all of their authorizations which is then built into their secrec. In

the process of building the secrec, Top Secret will automatically apply its rule processing engine to

resolve the best fit for all cases where rules may potentially contradict one another. The rule processing

engine is described in section 6.4 above, under [AC]FDP_ACF.1(1).

[AC+PM]FMT_SMF.1 – Specification of Management Functions:

The management functions for Top Secret that are relevant to satisfying the requirements of the claimed

Protection Profiles are discussed throughout this document. The following table summarizes the

management functions and provides a high-level reference to how they are performed and where in the

product documentation a description of the function can be found.


33 | P a g e

SFR Management Activity Managed By References in Web Guidance

[PM]ESM_ACD.1 Creation of policies Resource rules,

controlling system entry

Controlling Access, Protecting

Resources

[PM]ESM_ACT.1 Transmission of

policies CPF

Command Propagation

Facility

[PM]ESM_ATD.2 Association of

attributes with subjects User ACIDs Creating and Setting Up Users

[PM]ESM_EAU.2

Management of

authentication data for

both interactive users

and authorized IT

entities (if managed by

the TSF)

User ACIDs Creating and Setting Up Users

[AC+PM]ESM_EID.2

Management of

authentication data for

both interactive users

and authorized IT

entities (if managed by

the TSF)


[PM]FAU_SEL_EXT.1

Configuration of

auditable events for

defined external

entities

Resource rules,


Creating and Setting Up

Users, Controlling Access,

Protecting Resources

[PM]FAU_STG_EXT.1

Configuration of

external audit storage

location

Audit data is stored in the

Operational environment

on the local OS and the

offloading of this data is

not the responsibility of

the TSF.

This function is vacuously

satisfied because the relevant

assignment in the Security

Target is completed with only

one activity which the TSF

enforces by default.

[PM]FIA_AFL.1

Configuration of

authentication failure

threshold value

Control options

(PTHRESH)

Managing Passwords and

Password Phrases

Configuration of

actions to take when

threshold is reached

When the threshold is

reached, the ACID is

automatically locked until

manually reset

This function is vacuously

satisfied because the relevant

assignment in the Security

Target is completed with only

one activity which the TSF

enforces by default.

Execution of

restoration to normal

state following

threshold action (if

applicable)


[PM]FIA_USB.1

Definition of subject

security attributes,

modification of subject

security attributes



34 | P a g e

[PM]FMT_MOF_EXT.1

Configuration of the

behavior of other ESM

products

Resource rules,


Controlling Access, Protecting

Resources

[PM]FMT_MSA_EXT.5

Configuration of what

policy inconsistencies

the TSF shall identify

and how the TSF shall

respond if any

inconsistencies are

detected (if applicable)

Control options (MERGE,

OVERRIDE,

MERGE/ALLMERGE)

Managing Passwords and

Password Phrases

[PM]FMT_SMR.1

Management of the

users that belong to a

particular role


[PM]FTA_TAB.1 Maintenance of the

banner

The Operational

Environment is

responsible for displaying

the banner, which is

considered to be

appropriate as per NIAP

TD0055

The Operational Environment

is responsible for displaying

the banner, which is

considered to be appropriate

as per NIAP TD0055

[AC+PM]FTP_ITC.1

Configuration of

actions that require

trusted channel (if

applicable)

CPF (note that the TOE

will always use the

trusted channel for CPF

communications if the

Operational Environment

is configured to facilitate

this but CPF

configuration allows an

administrator to specify

the remote endpoints for

this channel)

Command Propagation

Facility

[PM]FTP_TRP.1

Configuration of

actions that require

trusted path (if

applicable)

The TOE will always use

the trusted path for

remote administration if

the Operational

Environment is

configured to facilitate

this

The TOE will always use the

trusted path for remote

administration if the

Operational Environment is

configured to facilitate this

Table 5 – Top Secret Management Function References

[AC+PM]FMT_SMR.1 – Security Management Roles:

The “Creating Security Administrators” section of the web guidance describes the MSCA, SCA, LSCA,

ZCA, VCA, and DCA administrative roles, how to define their scope, and how to assign administrative

privileges to these roles. “Creating and Setting Up Users” describes user ACIDs, which includes how to

associate a user with a defined administrative role. Since each organizational ACID can potentially have

its own administrator, multiple instances of LSCAs, ZCAs, VCAs, and DCAs can be defined.

Administrators with these roles will then perform management functions that apply to their assigned


35 | P a g e

zones, divisions, or departments. For example, a ZCA is typically used to manage user ACIDs and access

control rules for subjects and objects within their assigned zone.

When Top Secret is first installed, the individual performing the installation is assigned the initial user

ACID which is associated with the MSCA control ACID (role). There can be only one MSCA. The

MSCA can then define one or more user ACIDs that are assigned the SCA control ACID. The MSCA and

SCA are considered to be super users of Top Secret. From there, zones, divisions, and departments can be

defined along with the control ACIDs to have scope over them. The control ACIDs can then be assigned

differing administrative authorities depending on their intended usage. Note that an administrator cannot

grant privileges that they do not have themselves. Once the initial assignment of SCAs has been

performed, the MSCA should not typically be used.

When CPF is used, an administrator is effectively “logging in” to a remote node in order to manage it.

This means that the administrator must have a control ACID that has sufficient scope and privileges to

perform the requested operation. The secrec that is built on the local system does not affect privileges

when using CPF, except that the administrator must be assigned a sufficiently privileged control ACID to

access CPF in the first place.

6.7 Protection of the TSF

[AC+PM]FPT_APW_EXT.1 – Protection of Stored Credentials:

There is no specific operational guidance prescribed by the claimed PPs for this SFR. Note however that

Top Secret is not responsible for credential data that may be visible due to the presence of the //*

PASSWORD field on a job card. In order to minimize the risk of disclosure of authentication data, it is

recommended that the use of this is avoided whenever possible and in cases where it must be used (such

as a job that is submitted under a surrogate ACID), the administrator will ensure that the job card cannot

be read by any user other than those that are authorized to know the credentials for that ACID. Top Secret

will not output password data in the joblog but additional precautions are recommended.

[AC]FPT_FLS_EXT.1 – Failure of Communications:

Top Secret can be run as a self-contained product on a single instance of z/OS on a mainframe or a single

instance of Top Secret can be used to administer multiple instances of the product deployed on distinct

systems/LPARs using CPF. CPF takes commands that are issued on one node and replicates them across

multiple nodes as if they were entered directly on each individual system/LPAR. Each instance of Top

Secret maintains its own security database which contains all configuration and ruleset information for the

product. Therefore, if CPF is used, a remote node does not require a persistent connection to the source of

its configuration because its Top Secret behavior is defined by its local database which is updated by CPF

commands.

As described in [PM]ESM_ACT.1 above, there are multiple ways in which CPF can behave if one of the

target nodes cannot be reached by the originating system. This determines whether the originating system

halts further processing until all remote nodes have received the CPF command or queues the unreceived

commands and allows them to be processed independently of the other nodes.

[AC]FPT_RPL.1 – Replay Detection:


36 | P a g e

Top Secret relies on the CA Common Services environmental component to establish TCP/IP

communications between remote nodes and to secure them using TLS. The ability of Top Secret to make

use of these services when transmitting CPF commands protects data in transit from unauthorized

modification or disclosure, which mitigates the threat of a replay attack.

[AC+PM]FPT_SKP_EXT.1 – Protection of Secret Key Parameters:

There is no specific operational guidance prescribed by the claimed PPs for this SFR.

6.8 Resource Utilization

[AC]FRU_FLT.1 – Degraded Fault Tolerance:

In a CPF environment, there are two configurable options for how a remote node can be synchronized

with other CPF nodes in the case of a communications outage, as follows:

- Synchronous: if any target CPF node is unavailable, the command will not finish processing (and

further issuing of commands is not possible) until all nodes successfully receive the command so

that all nodes remain synchronized.

- Asynchronous: if any target CPF node is unavailable, the command will be processed by the

available nodes and queued for the unavailable node. CPF will attempt to retransmit the

command every 60 seconds until it succeeds.

These options are configurable using the CPFWAIT control option, which is described in “CPF-Related

Control Options” in the web guidance under Using > Command Propagation Facility as well as in the

description of the CPFWAIT control option in “Specifying Control Options to Modify Your Security

Environment.” Unless otherwise specified, Top Secret will transmit CPF commands synchronously.

6.9 TOE Access

[AC+PM]FTA_TSE.1 – TOE Session Establishment:

Top Secret has the ability to deny session establishment to both users and administrators by applying

access control rules to the mainframe’s authentication function. In the evaluated configuration, access to

the system can be granted or denied based on several factors, which are listed below along with references

to how they are configured:

- PERMIT rules: Top Secret can use command functions in TSS PERMIT rules to control system

entry in the evaluated configuration. These rules can be used to grant access to the system and can

be conditionally applied during different time intervals. The following command functions are

applicable to this, all of which are described in the web guidance under “Keywords”:

o ACID – allows a user ACID to access the system as an alternate ACID by permitting the

submission of jobs under the second ACID.

o FACILITY – allows a user ACID to access the system using one or more authorized

facilities (applications).

o FOR – specifies a number days for which the PERMIT rule is valid.

o TIMEREC – a TIMEREC (time record) specifies multiple time ranges in a calendar day,

which can be applied to a PERMIT rule to have it apply during those ranges.


37 | P a g e

o TIMES – defines a single range of hours within a calendar day that the PERMIT rule

applies.

- Source of origin restriction: A user can have allowed sources of origin defined in the user ACID.

This indicates the terminals that the user can access and supersedes any authorizations granted by

PERMIT rules.

- Suspend status: As described in [PM]FIA_AFL.1 above, a user ACID can be suspended if it has

reached the configured authentication failure threshold (PTHRESH).

Note that even if Top Secret is deployed in an enterprise environment where CA LDAP Server is being

used to synchronize its Security File with the LDAP server, Top Secret retains sole authority over

controlling access to the mainframe’s authentication function. The mainframe does not make any external

calls to use the LDAP directory as an authentication server.

6.10 Trusted Path/Channels

[AC+PM]FTP_ITC.1 – Inter-TSF Trusted Communication:

Top Secret relies on CA Common Services to provide TCP/IP communications between remote nodes.

CA Common Services in turn relies on the Integrated Cryptographic Services Facility (ICSF) component

of z/OS to provide cryptographic services in support of TLS communications. When CPF is used to

transmit commands between distributed nodes, CA Common Services will transmit the CPF commands

using a TLS trusted channel. Section 5.5.4 of this document provides information on how CA Common

Services must be configured in the operational environment in order to facilitate this behavior.

When administering Top Secret against the access control functionality of the local system, configuration

occurs entirely within the local system so these communications are assumed to be secure.

[PM]FTP_TRP.1 – Trusted Path:

Similar to above, remote administration of Top Secret requires an administrator to establish a remote

connection to the mainframe system. In the evaluated configuration, Top Secret will rely on CA Common

Services to facilitate an SSH connection so that remote administrative commands are not subjected to

modification or disclosure.

7 Operational Modes

CA Top Secret provides four modes of operation, described below:

DORMANT – Does not enforce any access control functionality except for validation of correct

password or password phrases when a control ACID attempts to log on to the system.

WARN – Evaluates activity against applicable access control rules but does not prevent access in

the event that the requested action is not allowed by policy. Instead, users will simply be notified

that they have performed an action that is not authorized.

IMPL – Enforces access control policy rules against defined users but will not control access

attempts for undefined users.

FAIL – Enforces access control policy rules against all subjects, objects, and operations as

specified by policy and blocks unauthorized access attempts.


38 | P a g e

By default, Top Secret is deployed in FAIL mode. In the evaluated configuration, this is the only mode

that is supported. The other modes are intended to be used primarily for initial deployment of Top Secret,

testing proposed changes to the system’s security posture, or troubleshooting potential flaws in the

implementation of policy rules. To change the operational mode, issue the ‘F TSS MODE(<desired

mode>)’ as MSCA or SCA.

8 Additional Support

CA provides technical support for its products if needed. Customers can visit https://support.ca.com in

order to view product documentation, receive guidance on how to apply patches, and open support tickets.

CA support can also be reached by calling 1-800-225-5224.

https://support.ca.com/

ca top secret r16 supplemental administrative guidance … · ca top secret r16 supplemental...

Documents