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.
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.
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
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.
CA ACF2 for z/OSand assumes that you have fully and properly implemented all security controls within respective external security manager.
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- HighAny vulnerability, the exploitation of which directly and immediately result in loss of confidentiality, availability, or integrity.
- Severity 2 - MediumAny vulnerability, the exploitation of which has a potential to result in loss of confidentiality, availability, or integrity.
- Severity 3 - LowAny vulnerability, the existence of which degrades measures to protect against loss of confidentiality, availability, or integrity.
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)