Using STIG Articles

Includes mainframe security standard review and implementation guidelines.
When applied to
CA ACF2 for z/OS
, the security standards decrease the risk of unauthorized disclosure of sensitive information. We developed the Security Technical Implementation Guides (STIGs) to enhance the confidentiality, integrity, and availability of customers using our mainframe products.
Implementation Responsibility
Before you implement these settings in a production environment, especially within large user populations, we recommend that you evaluate the specified configuration settings in a local, representative test environment.  The extensive variety of environments makes it impossible to test these configuration settings for all potential software configurations.
Broadcom accepts no liability for the consequences of applying specific configuration settings made on the basis of 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. Each STIG is limited to the specific
CA ACF2 for z/OS
and assumes that you have fully and properly implemented all security controls within respective external security manager.
Severity Definitions
These definitions are a measure of vulnerabilities used to assess a facility or system security posture. Each STIG 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 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 role.
  • z/OS Application Scheduler/Production Team (DCSPTEAM)
  • z/OS Application Security Team (DSECTEAM)
  • 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 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)
Access is granted only based upon valid requirements to product resources as documented by roles that individuals are assigned.