Using STIG Articles

Includes mainframe security standard review and implementation guidelines for the latest release of CA SYSVIEW Performance Management.
When applied to CA SYSVIEW, the security standards decrease the risk of unauthorized disclosure of sensitive information. We developed our vendor Security Technical Implementation Guides (STIGs) to enhance the confidentiality, integrity, and availability of customers using our mainframe products.
Implementation Responsibility
Before you implement these standards within your production environment, especially within large user populations, we recommend that you evaluate the specified standards in a local, representative test environment. The extensive variety of environments makes it impossible to test these standards for all potential mainframe environments.
Broadcom accepts no liability for the consequences of applying specific configuration settings that are made based on the security standard. For some production environments, failure to test before implementation may lead to a loss of required functionality.
Evaluating the risks and benefits of a system’s circumstances and requirements is the system owner’s responsibility. The evaluated risks resulting from not applying specified configuration settings must be approved by the responsible authorizing official within respective organizations. Furthermore, Broadcom implies no warranty that the application of all specified configurations results in a system that is 100 percent secure. We provide these security standards as guidelines. Ensure that all applicable security guidance is applied at the device-hardening level and the architectural level because some settings may not be configurable in all environments. This STIG is limited to the specific CA SYSVIEW solution and assumes that you have fully and properly implemented all security controls within RACF.
Severity Definitions
These definitions are a measure of vulnerabilities that are used to assess a facility or system security posture. Each STIG ID in this document is assigned one of the following values:
  • Severity 1: High
    Any vulnerability, the exploitation of which directly and immediately result in loss of confidentiality, availability, or integrity.
  • Severity 2: Medium
    Any vulnerability, the exploitation of which has a potential to result in loss of confidentiality, availability, or integrity.
  • Severity 3: Low
    Any vulnerability, the existence of which degrades measures to protect against loss of confidentiality, availability, or integrity.
Depending upon the specific details within the access granted, aggregated risks may exist. The resulting risks could increase the risk severity from one level to another.
User Roles and Least Privilege Access
The following list details typical mainframe infrastructure roles at the z/OS system level regardless if 0 to 500 applications are running. These roles correspond to the roles allowed to have specific access levels within the STIG. Your organization, least privilege, and separation of role requirements determine who is assigned a role by user ID. We recommend that you build a formalized document that defines all roles, duties, responsibilities, and specific access allowed and approved for each of your organization's mainframe infrastructure roles.
  • z/OS Application Scheduler/Production Team (DCSPTEAM)
  • z/OS Application Security Team (DSECTEAM)
  • z/OS Auditors (AUDITORS)
  • z/OS CICS System Programmer (CICSSYSP)
  • z/OS Communications System Programmer (COMMSYSP)
  • z/OS Database System Programmer (DBASYSP)
  • z/OS DB2 System Programmer (DB2SYSP)
  • z/OS IDMS System Programmer (IDMSSYSP)
  • z/OS IMS System Programmer (IMSSYSP)
  • z/OS Operations (ZOSOPER1)
  • z/OS Storage Administrator System Programmer (DASDSYSP)
  • z/OS System-Level Product Schedulers/Support Team (PCSPTEAM)
  • z/OS System/LPAR Level Mainframe Security Team (ZSECTEAM)
  • z/OS System Programmer (ZOSSYSP1)
  • z/OS SYSVIEW Trusted Started Tasks Users (SYSVSTC)
  • z/OS Websphere MQ System Programmer (WMQSYSP)
Access is granted only based on valid requirements to product resources as documented by roles that individuals are assigned. Ensure that the least privilege access is granted, allowing individuals to perform the documented functions within the assigned role.