What changed in IBM WebSphere Traditional V9.x STIG V2R2V2R2 changes

Discussion

Application management includes the ability to control the number of sessions that utilize an application by all accounts and/or account types. Limiting the number of allowed sessions is helpful in limiting risks related to Denial of Service attacks. Application servers host and expose business logic and application processes. The application server must possess the capability to limit the maximum number of concurrent sessions in a manner that affects the entire application server or on an individual application basis. Although there is some latitude concerning the settings themselves, the settings should follow DoDDoW-recommended values, but the settings should be configurable to allow for future DoDDoW direction. While the DoDDoW will specify recommended values, the values can be adjusted to accommodate the operational requirement of a given system.

V-255818 in V2R2

Title

The WebSphere Application Server management interface must display the Standard Mandatory DoDW Notice and Consent Banner before granting access to the system.

Check text

Point browser to the URL of the WebSphere administration console. If the Standard Mandatory DoDW Notice and Consent Banner is not displayed, this is a finding.

Fix text

Open the file ${WAS_HOME}/properties/login.info. Follow the instructions in the HTML comment section to create the pre-logon banner. Enter the Standard DoDDoW Mandatory Notice and Consent banner into the HTML section. If logged on to the admin console, log out and log back on to validate the changes. Restart the DMGR and all the JVMs.

Discussion

Application servers are required to display the Standard Mandatory DoDDoW Notice and Consent Banner before granting access to the system management interface, providing privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance that states that: (i) users are accessing a U.S. Government information system; (ii) system usage may be monitored, recorded, and subject to audit; (iii) unauthorized use of the system is prohibited and subject to criminal and civil penalties; and (iv) the use of the system indicates consent to monitoring and recording. System use notification messages can be implemented in the form of warning banners displayed when individuals log on to the information system. System use notification is intended only for information system access including an interactive logon interface with a human user, and is not required when an interactive interface does not exist. Use this banner for desktops, laptops, and other devices accommodating banners of 1300 characters. The banner shall be implemented as a click-through banner at logon (to the extent permitted by the operating system), meaning it prevents further activity on the information system unless and until the user executes a positive action to manifest agreement by clicking on a box indicating "OK". "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."

V-255838 in V2R2

Title

The WebSphere Application Server management interface must retain the Standard Mandatory DoDDoW Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access.

Check text

Point browser to the URL of the WebSphere administration console. If the Standard Mandatory DoDDoW Notice and Consent Banner is not retained until the user acknowledges the usage conditions, this is a finding.

Fix text

Open the file ${WAS_HOME}/properties/login.info. Follow the instructions in the HTML comment section to create the pre-logon banner. Enter the Standard DoDDoW Mandatory Notice and Consent banner into the HTML section. If logged on to the admin console, log out and log back on to validate the changes. Restart the DMGR and all the JVMs.

V-255839 in V2R2

Discussion

Application servers provide a myriad of differing processes, features, and functionalities. Some of these processes may be deemed to be unnecessary or too unsecure to run on a production DoDDoW system. Application servers must provide the capability to disable or deactivate functionality and services that are deemed to be non-essential to the server mission or can adversely impact server performance, for example, disabling dynamic JSP reloading on production application servers as a best practice.

V-255861 in V2R2

Discussion

Some networking protocols may not meet organizational security requirements to protect data and components. Application servers natively host a number of various features, such as management interfaces, httpd servers, and message queues. These features all run on TCPIP ports. This creates the potential that the vendor may choose to utilize port numbers or network services that have been deemed unusable by the organization. The application server must have the capability to both reconfigure and disable the assigned ports without adversely impacting application server operation capabilities. For a list of approved ports and protocols, reference the DoDDoW ports and protocols website at https://powhatan.iiie.disa.mil/ports/cal.html.

V-255862 in V2R2

Title

The WebSphere Application Server must use signer for DoDW-issued certificates.

Check text

Navigate to Security >> SSl certificate and key management >> SSL Configurations >> CellDefaultSSLSettings >> KeyStores and certificates. Click on cell default trust store. Click on "Signer Certificates". If no DoDDoW root or intermediate certificates are present, this is a finding.

Discussion

The cornerstone of PKI is the private key used to encrypt or digitally sign information. The key by itself is a cryptographic value that does not contain specific user information, but the key can be mapped to a user. Without mapping the certificate used to authenticate to the user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis. Application servers must provide the capability to utilize and meet requirements of the DoDDoW Enterprise PKI infrastructure for application authentication.

V-255874 in V2R2

Title

The WebSphere Application Server must use DoDW-approved Signer Certificates.

Check text

From administrative console, navigate to Security >> SSL Certificates and Key Management >> KeyStores and Certificates. For each keystore, click on "Signer Certificates". If any of the certificates are not issued by an approved DoDDoW CA, this is a finding.

Fix text

Utilize DoDDoW certificates that have been issued by a DoDDoW PKI CA. To replace a non-DoDDoW PKI-established certificate: From the administrative console, navigate to Security >> SSL Certificates and Key Management >> KeyStores and Certificates. For each keystore that requires the change: Import a new certificate by clicking "Import". Click "keystore" file. Enter the location of the new certificate. Specify the type of keystore and keystore password. Specify alias information. Click "Apply". After the certificate is imported, click on "Replace" to replace the original certificate with the new certificate.

Discussion

Class 3 PKI certificates are used for servers and software signing rather than for identifying individuals. Class 4 certificates are used for business-to-business transactions. Utilizing unapproved certificates not issued or approved by DoDDoW or CNS creates an integrity risk. The application server must utilize approved DoDDoW or CNS Class 3 or Class 4 certificates for software signing and business-to-business transactions.

V-255877 in V2R2

Title

The WebSphere Application Server DoDW root CAs must be in the trust store.

Check text

Review System Security Plan documentation for location of the trust store used to store the signers of the administrators certificates. By default this is "cellDefaultTrustStore". Navigate to Security >> SSL certificate and key management >> Keystore and certificates. Click on the trust store used to store the signers of the administrators' certificates (root CA). (The default is cellDefaultTrustStore). Click on "Signer Certificates". If there are no DoDDoW signer certificates, this is a finding.

V-255879 in V2R2

Title

The WebSphere Application Server personal certificates in all keystores must be issued by an approved DoDW CA.

Check text

Review System Security Plan documentation for a list of DoDDoW-approved CAs. From administrative console, navigate to Security >> SSL Certificates and Key Management >> KeyStores and Certificates. For each keystore, click on "Personal Certificates". If any of the certificates are not issued by an approved DoDDoW CA, this is a finding.

Fix text

Utilize DoDDoW certificates that have been issued by an approved DoDDoW PKI CA. To replace a non-DoDDoW PKI-established certificate: From the administrative console, navigate to Security >> SSL Certificates and Key Management >> KeyStores and Certificates. For each keystores that requires the change: Import a new certificate by clicking "Import". Click "keystore" file. Enter the location of the new certificate. Specify the type of keystore and keystore password. Specify alias information. Click "Apply". After the certificate is imported, click on "Replace" to replace the original certificate with the new certificate.

Discussion

Untrusted Certificate Authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DoDDoW systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DoDDoW-approved CA, trust of this CA has not been established. The DoDDoW will only accept PKI certificates obtained from a DoDDoW-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of SSL/TLS certificates. The application server must only allow the use of DoDDoW PKI-established certificate authorities for verification.

V-255880 in V2R2

Check text

Review System Security Plan documentation. Identify the application load requirements defined by system owner. Regular application user session timeout values are defined at the DoDDoW level at 20 minutes. An ISSO risk acceptance is required to deviate from that value. If session timeout values are not set to "20" and an ISSO risk acceptance is provided, this is not a finding. From the admin console, navigate to Servers >> all servers >> [web application server] >> Session management. For every [web application server], verify maximum in-memory session count. Verify "allow overflow" and "session timeout" are set according to application load requirements. If they are not set according to application load requirements, this is a finding.

V-255886 in V2R2

Discussion

Export grade encryption suites are not strong and do not meet DoDDoW requirements. The encryption for the session becomes easy for the attacker to break. Do not use export grade encryption. Information on disabling export ciphers can be found in the Knowledge Center aton thisIBM's link: http://wwwwebsite.ibm.com/support/knowledgecenter/SS7K4U_8.5.5/com.ibm.websphere.ihs.doc/ihs/rihs_ciphspec.html

V-255888 in V2R2

Check text

Note: If FIPS 140-2 is configured in WBSP-AS-001290, this is not applicable. This is allowed until 21 September 2026. If FIPS 140-2 is still in use after this date, this is a finding. From administrative console, click Security >> SSL certificate and key management >> Manage FIPS. If "Enable FIPS 140-3" is not selected, this is a finding.

Fix text

Implementation for Cell Profile (Network Deployment): 1. Back up the existing configuration: backupConfig.sh &ltbackup_directory> 2. Stop all servers except the deployment manager: - Stop all node agents and application servers. - Keep only the deployment manager running. 3. Enable FIPS 140-3.: Option A - Using Administrative Console: 1. Click Security >>» SSL certificate and key management >>» Manage FIPS. 2. Select "Enable FIPS 140-3". 3. Click "Apply". Option B - Using Admin Command: AdminTask.enableFips('[-enableFips true -fipsLevel FIPS140-3 ]') 1. Stop the deployment manager. 2. Restart the deployment manager. 3. Synchronize nodes. On each node, run: syncNode.sh &ltdmgr_host> &ltdmgr_port> 4. Start node agents and servers Implementation for Standalone Profile: 1. Back up the existing configuration: backupConfig.sh &ltbackup_directory> 2. Enable FIPS 140-3. Option A - Using Administrative Console: 1. Click Security >>» SSL certificate and key management >>» Manage FIPS. 2. Select "Enable FIPS 140-3". 3. Click "Apply". Option B - Using Admin Command: AdminTask.enableFips('[-enableFips true -fipsLevel FIPS140-3 ]') For both methods, restart the application server.

Discussion

Encryption is only as good as the encryption modules in use. Unapproved cryptographic module algorithms cannot be verified and cannot be relied upon to provide confidentiality or integrity, and DODDoW data may be compromised due to weak algorithms. The use of TLS provides confidentiality of data in transit between the application server and client. FIPS 140-3-approved TLS versions include TLS V1.0 or greater. TLS must be enabled and non-FIPS-approved SSL versions must be disabled. NIST SP 800-52 specifies the preferred configurations for government systems.

V-283677 in V2R2