ca top secret r16 supplemental administrative guidance … · ca top secret r16 supplemental...
TRANSCRIPT
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
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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.
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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.
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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.
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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.
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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:
Verify that all data is correct for the install, and click on the NEXT button
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:
Verify that all data is correct for the install, and click on the NEXT button
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
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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.
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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:
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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
*
*
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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.
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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.
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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.
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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)
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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.
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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.
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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:
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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.
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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:
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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.
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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)
User ACIDs Creating and Setting Up Users
[PM]FAU_SEL_EXT.1
Configuration of
auditable events for
defined external
entities
Resource rules,
controlling system entry
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)
User ACIDs Creating and Setting Up Users
[PM]FIA_USB.1
Definition of subject
security attributes,
modification of subject
security attributes
User ACIDs Creating and Setting Up Users
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
34 | P a g e
[PM]FMT_MOF_EXT.1
Configuration of the
behavior of other ESM
products
Resource rules,
controlling system entry
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
User ACIDs Creating and Setting Up Users
[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
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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:
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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.
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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.
Supplemental Administrative Guidance for Common Criteria CA Top Secret r16
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.