V7R2 changes
zOS WebSphere Application Server for TSS STIG V7R2 (2025-10-01) replaced V7R1 (2025-01-30): 5 checks updated. It has 5 checks, against 5 in V7R1.
V7R2 checklistV7R1 checklist Compare V7R1 and V7R2 in STIG Compare
- 0 added
- 0 removed
- 5 updated
Updated fields: Check text 5Fix text 5Discussion 4
Updated in V7R2 (5)
V-225618CAT IIMVS data sets for the WebSphere Application Server are not protected in accordance with the proper security requirements.Check text, Fix text
Check text
a) Refer to the following reports produced by the Data Set and Resource Data Collection:
- SENSITVE.RPT(HTTPRPT).
- SENSITVE.RPT(WASRPT).
b)If Ensure the following data set controls are in effect for WAS:, this is not a finding.
___ The ACP data set rules restrict UPDATEWRITE and/or ALTERgreater access to HTTP product data sets (i.e., SYS1.IMW.AIMW** and SYS1.IMW.SIMW**) is restricted to systems programming personnel.
NOTENote: If the HTTP server is not used with WAS, this check can be ignored.
___ The ACP data set rules restrict UPDATEWRITE and/or ALTERgreater access to WAS product data sets and associated product data sets are restricted to systems programming personnel.
SYS*.EJS.V3500108.** (WebSphere 3.5)
SYS*.WAS.V401.** (WebSphere 4.0.1)
SYS*.OE.** (Java)
SYS*.JAVA** (Java)
SYS*.DB2.V710107.** (DB2)
SYS*.GLD.** (LDAP)
SYS1.LE.** (Language Environment)
c) If all of the items in (b) are true, there is no finding.
d) If any item in (b) is untrue, this is a finding.
Fix text
The ISSO will ensure that WebSphere server data sets restrict UPDATE and/or ALTER access to systems programming personnel.
Ensure the following data set controls are in effect for WAS:
1) UPDATE and ALTER access to HTTP product data sets (i.e., SYS1.IMW.AIMW** and SYS1.IMW.SIMW**) are restricted to systems programming personnel.
NOTENote: If the HTTP server is not used with WAS, this check can be ignored.
2) UPDATE and ALTER access to WAS product data sets and associated product data sets are restricted to systems programming personnel.
SYS*.EJS.V3500108.** (WebSphere 3.5)
SYS*.WAS.V401.** (WebSphere 4.0.1)
SYS*.OE.** (Java)
SYS*.JAVA** (Java)
SYS*.DB2.V710107.** (DB2)
SYS*.GLD.** (LDAP)
SYS1.LE.** (Language Environment)
V-225619CAT IIHFS objects for the WebSphere Application Server are not protected in accordance with the proper security requirements.Check text, Fix text, Discussion
Check text
a) Refer to the following reports produced by the UNIXz/OS System Services Data Collection:
- USSCMDS.RPT(IHSHFSOB).
- USSCMDS.RPT(WASHFSOB).
For each IBM HTTP server, supply the following information: (PDS member name - IHSACCTS)
- Web server ID defined to the ACP.
- Web server administration group defined to the ACP.
- Web server standard HFS directory.
b) The following notes apply to the requirements specified in the HFS Permission Bits table in the z/OS STIG Addendum:. If the following guidance is true, this is not a finding.
- If an owner field indicates UID(0) user, any system ID with a UID(0) specification is acceptable.
- Where an owner field indicates websrv1, the ID of the web server is intended.
- Where a group field indicates webadmg1, the ID of a local web server administration group is intended. IMWEB is not a valid local group.
- The site is free to set the permission and audit bit settings to be more restrictive than the documented values.
The following represents a hierarchy for permission bits from least restrictive to most restrictive:
7 rwx (least restrictive)
6 rw-
3 -wx
2 -w-
5 r-x
4 r--
1 --x
0 --- (most restrictive)
The possible audit bits settings are as follows:
f log for failed access attempts
a log for failed and successful access
- no auditing
c) If all of the items in (b) are true, there is NO FINDING.
d) If any item in (b) is untrue, this is a FINDING.
Fix text
Review the UNIX permission bits, user audit bits, and ownership settings on the HFS directories and files for the products required to support the WAS environment.
Ensure the HFS permission bits, user audit bits, owner, and group for each directory and file match the specified settings listed in the HFS Permissions Bits table located in the zOS STIG Addendum.
Discussion
HFS directories and files provide the configuration, operational, and executable properties of the WebSphere Application Server (WAS) environment. Many of these objects are responsible for the security implementation of WAS. Failure to properly protect these directories and files may lead to unauthorized access. This exposure could potentially compromise the integrity and availability of system services, applications, and customer data.
V-225620CAT IIThe CBIND Resource(s) for the WebSphere Application Server is(are) not protected in accordance with security requirements.Check text, Fix text, Discussion
Check text
a) Refer to the following reports produced by the TSS Data Collection and Data Set and Resource Data Collection:
- TSSCMDS.RPT(WHOOCBIN).
- TSSCMDS.RPT(WHOHCBIN).
- SENSITVE.RPT(WHOHCBIN).
b) EnsureIf the following items are in effect for CBIND resource protection:, this is not a finding.
1) The CB. resource is owned appropriately in the BIND resource class.
2) Access to the CB.BIND.server_name and CB.server_name resources is restricted to WAS server (STC) ACIDs and systems management ACIDs (e.g., WebSphere administrator ID).
c) If all items in (b) are true, there is NO FINDING.
d) If any item in (b) is untrue, this is a FINDING.
Fix text
Ensure the following items are in effect for CBIND resource protection:
1) The CB. resource is owned appropriately in the BIND resource class.
For Example:
TSS ADD(cbowner) CBIND(CB)
2) Access to the CB.BIND.server_name and CB.server_name resources is restricted to WAS server (STC) ACIDs and systems management ACIDs (e.g., WebSphere administrator ID).
For Example:
The WebSphere administrator ID needs readREAD authorityaccess to the CB.BBOASR1 and CB.BIND.BBOASR1 servers:
TSS PERMIT(was_admin_acid) CBIND(CB.BBOASR1) ACCESS(READ)
TSS PERMIT(was_admin_acid) CBIND(CB.BIND.BBOASR1) ACCESS(READ)
NOTENote: When adding a new server, all systems management userids (e.g., WebSphere administrator ID) must be authorized to have readREAD access to the CB.server_name and CB.BIND.server_name resources.
Discussion
SAF resources provide the ability to control access to functions and services of the WebSphere Application Server (WAS) environment. Many of these resources provide operational and administrative support for WAS. Failure to properly protect these resources may lead to unauthorized access. This exposure could compromise the integrity and availability of application services and customer data.
V-225621CAT IVendor-supplied user accounts for the WebSphere Application Server must be defined to the ACP.Check text, Fix text, Discussion
Check text
a) Refer to the following reportreports produced by the ACP Data Collection:
ACF2
- ACF2CMDS.RPT(LOGONIDS).
RACF
- RACFCMDS.RPT(LISTUSER) .
TSS
- TSSCMDS.RPT(@ACIDS).
Automated Analysis requires Additional Analysis.
Refer to the following report produced by the z/OS Data Collection:
- PDI(ZWAS0040).
b) If the CBADMIN user account is not defined to the ACP, therethis is NOnot FINDINGa finding.
c) If the CBADMIN user account is defined to ACP and the password has NOT been changed from the vendor default of CBADMIN, this is a FINDINGfinding with a severity code of CATCategory I.
d) If the CBADMIN user account is defined to the ACP and the password has been changed from the vendor default of CBADMIN, this is a FINDINGfinding with a severity code of
CAT Category II.
Fix text
The IASSO will ensure that the CBADMIN user account is removed or not defined to the ACP.
Discussion
Vendor-supplied user accounts are defined to the ACP with factory-set passwords during the installation of the WebSphere Application Server (WAS). These user accounts are common to all WAS environments and have access to restricted resources and functions. Failure to delete vendor-supplied user accounts from the ACP may lead to unauthorized access. This exposure could compromise the integrity and availability of system services, applications, and customer data.
V-225622CAT IIThe WebSphere Application Server plug-in is not specified in accordance with the proper security requirements.Check text, Fix text, Discussion
Check text
a) Refer to the following report produced by the UNIXz/OS System Services Data Collection:
- USSCMDS.RPT(AHTTPD).
Collect the following information for each IBM HTTP server:
- The JCL procedure library and member name used to start each IBM HTTP server. DOC(IHSPROCS).
-
For each IBM HTTP server, supply the following information:
- Web server ID defined to the ACP.
- Web server administration group defined to the ACP.
- Web server standard HFS directory.
b) Review the HTTP server JCL procedure to determine the httpd.conf file to review.
c) Ensure that all WAS-related directives are configured using the ServerInit, Service, and ServerTerm statements as outlined below.
The following path entries were added to the /etc/httpd.conf file for WebSphere 3.5:
ServerInit /usr/lpp/WebSphere/AppServer/bin/was350plugin.so:init_exit /usr/lpp/WebSphere/etc/WebSphere/AppServer/properties/was.conf
Service /webapp/examples/* /usr/lpp/WebSphere/AppServer/bin/was350plugin.so:service_exit
Service /*.jhtml /usr/lpp/WebSphere/AppServer/bin/was350plugin.so:service_exit
Service /*.shtml /usr/lpp/WebSphere/AppServer/bin/was350plugin.so:service_exit
Service /servlet/* /usr/lpp/WebSphere/AppServer/bin/was350plugin.so:service_exit
Service /*.jsp /usr/lpp/WebSphere/AppServer/bin/was350plugin.so:service_exit
ServerTerm /usr/lpp/WebSphere/AppServer/bin/was350plugin.so:term_exit
The following path entries are added to the /etc/httpd.conf file for WebSphere 4.0.1:
ServerInit - /usr/lpp/WebSphere401/WebServerPlugIn/bin/was400plugin.so:init_exit
Service - /usr/lpp/WebSphere401/WebServerPlugIn/bin/was400plugin.so:service_exit
ServerTerm - /usr/lpp/WebSphere401/WebServerPlugIn/bin/was400plugin.so:term_exit
NOTENote: The /etc/WebSphere clause for ServerInit matches the directory name above where the site customization was.conf file was established.
Specific items to review include proper path, was.conf, and plug-in settings.
d) If all WAS-related directives are configured properly, therethis is NO FINDING.
e) If any WAS-related directive is not configured properly, this is a FINDINGfinding.
Fix text
The IAOISSO will ensure that the WebSphere Application Server directives in the httpd.conf file are configured as outlined below.
Ensure that all WAS-related directives are configured using the ServerInit, Service, and ServerTerm statements as outlined below.
The following path entries were added to the /etc/httpd.conf file for WebSphere 3.5:
ServerInit /usr/lpp/WebSphere/AppServer/bin/was350plugin.so:init_exit /usr/lpp/WebSphere/etc/WebSphere/AppServer/properties/was.conf
Service /webapp/examples/* /usr/lpp/WebSphere/AppServer/bin/was350plugin.so:service_exit
Service /*.jhtml /usr/lpp/WebSphere/AppServer/bin/was350plugin.so:service_exit
Service /*.shtml /usr/lpp/WebSphere/AppServer/bin/was350plugin.so:service_exit
Service /servlet/* /usr/lpp/WebSphere/AppServer/bin/was350plugin.so:service_exit
Service /*.jsp /usr/lpp/WebSphere/AppServer/bin/was350plugin.so:service_exit ServerTerm /usr/lpp/WebSphere/AppServer/bin/was350plugin.so:term_exit
The following path entries are added to the /etc/httpd.conf file for WebSphere 4.0.1:
ServerInit -/usr/lpp/WebSphere401/WebServerPlugIn/bin/was400plugin.so:init_exit
Service - /usr/lpp/WebSphere401/WebServerPlugIn/bin/was400plugin.so:service_exit
ServerTerm - /usr/lpp/WebSphere401/WebServerPlugIn/bin/was400plugin.so:term_exit
NOTENote: The /etc/WebSphere clause for ServerInit matches the directory name above where the site customization was.conf file was established. Specific items to review include proper path, was.conf, and plug-in settings.
Discussion
Requests processed by the WebSphere Application Server (WAS) are dependent on directives configured in the HTTP server httpd.conf file. These directives specify critical files containing the WAS plug-in and WAS configuration. These files provide the operational and security characteristics of WAS. Failure to properly configure WAS-related directives could lead to undesirable operations and degraded security. This exposure may compromise the availability and integrity of applications and customer data.
How these changes are found
Checks are matched across the two releases by V-number. A check counts as updated when DISA gave it a new rule revision (the r number in its SV-…_rule id) and its title, severity, check text, fix text, discussion, CCIs or other fields changed — the same comparison STIG Compare makes. Added checks are new V-numbers; removed checks are V-numbers V7R2 no longer has.
Comparing other releases, or this one against an older release? Pick any two in STIG Compare.