What changed in IBM WebSphere Liberty Server STIG V2R5V2R5 changes

Discussion

Application management includes the ability to control the number of sessions that use 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. The System Security Plan should be reviewed and the maximum number of concurrent sessions allowable and defined within that plan should be used in the httpSession element. For example, if the maximum number of concurrent sessions is defined in the System Security Plan as 5000, then the httpSession element in ${server.config.dir}/server.xml should be configured as: &lthttpSession maxInMemorySessionCount="5000" allowOverflow="false" /> For http session security settings to apply, the security feature (appSecurity-2.0) must be defined in order to configure a user registry for the servlet to authenticate against. The servlet feature (servlet-3.1) must be defined in order to use a web application, and the ldap feature (ldapRegistry-3.0) must be defined in order to configure an enterprise-level user registry for authentication of the servlet users.

V-250322 in V2R5

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 use 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-250332 in V2R5

Title

The WebSphere Liberty Server must use DoDW-issued/signed certificates.

Check text

As a privileged user with access to the ${server.config.dir}/server.xml file; search for SSLDefault in order to identify the default SSL configuration. grep -i ssldefault server.xml Identify the default ssl configuration by examining the sslRef flag. SAMPLE: &ltsslDefault sslRef="DefaultTLSSettings" /> Review the default ssl configuration to identify the default truststore. SAMPLE: &ltssl id="DefaultTLSSettings" keyStoreRef="defaultKeyStore" /> &ltkeyStore id="LDAPTrustStore" location="${server.config.dir}/liberty.ks" type="JKS" password="xxxxxxx" /> Use the java keytool or ikeyman utilities to open and examine the certificates stored in the truststore. If the certificates are self signed or not signed by a DoDDoW approved certificate authority (CA), this is a finding.

Fix text

Do not use self-signed certificates in a production environment. Only import certificates signed by an authorized DoDDoW CA or authorized for DoDDoW use. Obtain the signer certificate either as a Base 64-encoded ASCII file or as binary DER data. Using the JDK’s ikeyman or keytool utility, open the default trusted keystore specified in the ${server.config.dir}/server.xml. Click on signer certificates and import the file that contains the DoDDoW signed certificate.

V-250338 in V2R5

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.

V-250347 in V2R5

Check text

Note:From If FIPS 140-2 is configured in IBMW-LS-000520, 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. There are two ways to meet this requirement using FIPS 140-3. Only one method is required. If IBM JDK 8 version 8.0.8.30 or later is installed and configured to run with WebSphere Liberty version 25.0.0.3 or later, proceed with method (I). If IBM Semeru Runtimes version 11.0.29, 17.0.17, 21.0.9, 25.0.1 or higher is installed and configured with WebSphere Liberty version 25.0.0.12 or later, proceed with method (II). Method (I) IBM JDK 8 (version 8.0.8.30 or later) with WebSphere Liberty (version 25.0.0.3 or later): 1. Review the ${server.config.dir}/jvm.optionsadministrative file. Verify FIPS 140-3 is in use by checking the following lines: -Xenablefips140-3 -Dcom.ibm.jsse2.usefipsprovider=true -Dcom.ibm.jsse2.usefipsProviderName=IBMJCEPlusFIPS If the properties are not set as shown in the ${server.config.dir}/jvm.options fileconsole, thisclick isSecurity a finding. 2. Verify TLS protocol is set to TLS 1.2 or TLS 1.3 in the ${server.config.dir}/server.xml file. &ltssl id="defaultSSLConfig" sslProtocol="TLSv1.2" /> or &ltssl id="defaultSSLConfig" sslProtocol="TLSv1.3" /> If TLSSSL 1.2certificate or TLS 1.3 is not configured, this is a finding. 3. Verify LTPA keys are FIPS 140-3 compliant. Verify the ltpa.keys file was generated after FIPS 140-3 was enabled or verify LTPA keys were created using the securityUtility createLTPAKeys command with FIPS 140-3 enabled. Default location: ${server.output.dir}/resources/security/ltpa.keys If LTPA keys were created before FIPS 140-3 was enabled and havekey notmanagement been regenerated, this is a finding. Method (II) IBM Semeru Runtimes with WebSphere Liberty (FIPS 140-3): 1. Verify FIPS 140-3 is configured by checking for the existence of the FIPS 140-3 profile file in one of the following locations: - Installation level: &ltLiberty install location>/wlp/etc/FIPS140-3-Liberty-Application.properties - Server level: &ltserver root>/resources/security/FIPS140-3-Liberty-Application.properties - ClientManage level: &ltclient root>/resources/security/FIPS140-3-Liberty-ApplicationFIPS.properties If the"Enable FIPS 140-3 profile file does not exist, this is a finding. 2. Review the FIPS 140-3 profile file and verify it contains the appropriate security provider configurations. The file should contain entries similar to: RestrictedSecurity.OpenJCEPlusFIPS.FIPS140-3-Liberty-Application.jce.provider.1 = com.ibm.crypto.plus. If the profile file does not contain valid provider configurations, this is a finding. 3. Verify TLS protocol is set to TLS 1.2 or TLS 1.3 in the ${server.config.dir}/server.xml file. &ltssl id="defaultSSLConfig" sslProtocol="TLSv1.2" /> or &ltssl id="defaultSSLConfig" sslProtocol="TLSv1.3" /> If TLS 1.2 or TLS 1.3 is not configuredselected, this is a finding. 4. Verify LTPA keys are FIPS 140-3 compliant. Verify the ltpa.keys file was generated after FIPS 140-3 was enabled. If an ltpa.keys.nofips backup file exists, verify new FIPS 140-3 compliant keys were generated. Default location: ${server.output.dir}/resources/security/ltpa.keys If LTPA keys were created before FIPS 140-3 was enabled and have not been regenerated, this is a finding. 5. SAML Configuration (FIPS 140-3 specific): If SAML is used, verify that only FIPS 140-3 approved signature algorithms are configured in the ${server.config.dir}/server.xml file: Approved algorithms: SHA256, SHA384, SHA512, ECDSAwithSHA256, ECDSAwithSHA384, ECDSAwithSHA512 Example: &ltsamlWebSso20 id="defaultSP" signatureMethodAlgorithm="SHA256" /> If SHA1 or other nonapproved algorithms are configured, this is a finding.

Fix text

ThereImplementation arefor twoCell waysProfile to(Network meet this requirement using FIPS 140-3. Only one method is required.Deployment): If IBM JDK 8 version 81.0.8.30 orBack laterup isthe installedexisting and configured to run with WebSphere Liberty version 25.0.0.3 or later, proceed with method (I).configuration: If IBM Semeru Runtimes version 11backupConfig.0.29,sh 17.0.17, 21.0.9, 25.0.1 or higher is installed and configured with WebSphere Liberty version 25.0.0.12 or later, proceed with method (II).&ltbackup_directory> Method (I) IBM JDK 8 (version 82.0.8.30 orStop later)all withservers WebSphereexcept Libertythe (versiondeployment 25.0.0.3 or later)manager: 1.Stop Ifall Libertynode serveragents isand running,application stop it.servers 2.Keep Edit/createonly the ${server.config.dir}/jvm.optionsdeployment file.manager Edit/add the following three properties:running -Xenablefips140-3 -Dcom.ibm.jsse2.usefipsprovider=true -Dcom.ibm.jsse2.usefipsProviderName=IBMJCEPlusFIPS 3. IfEnable there are existing LTPA keys, delete the ltpa.keys file before restarting the server to generate new FIPS 140-3-compliant keys. DefaultOption location: ${server.output.dir}/resources/security/ltpa.keys A new- ltpa.keysUsing fileAdministrative willConsole: 1. beClick automaticallySecurity created» whenSSL thecertificate Libertyand serverkey restartsmanagement with» FIPSManage 140-3-compliant keysFIPS. 42. RestartSelect the"Enable Liberty server to enable FIPS 140-3". 5. Verify TLS protocol is set to TLS 1.2 or TLS 1.3 in the ${server.config.dir}/server.xml file. &ltsslClick id="defaultSSLConfigApply" sslProtocol="TLSv1.2" /> or &ltsslOption id="defaultSSLConfig"B sslProtocol="TLSv1.3" /> Alternative LTPA Key Creation Method: To manually create LTPA keys with FIPS 140-3 approvedUsing algorithmsAdmin using the securityUtility commandCommand: 1AdminTask. Export the required system properties: export JVM_ARGS="enableFips('[-Xenablefips140-3enableFips -Dcom.ibm.jsse2.usefipsprovider=true -Dcom.ibm.jsse2.usefipsProviderName=2.fipsLevel Run the securityUtility createLTPAKeys command: securityUtility createLTPAKeys FIPS140--password=mypassword --passwordEncoding=aes Important: If LTPA validation keys exist, delete these and generate new validation keys after FIPS 140-3 is enabled using the securityUtility createLTPAKeys command as shown above. Method (II]') IBM Semeru Runtimes with WebSphere Liberty (FIPS 140-3): 1. LibertyStop serverthe isdeployment running, stop itmanager. 2. EnableRestart FIPS 140-3 using the securityUtilitydeployment configureFIPS commandmanager. 3. ToSynchronize enablenodes. acrossOn alleach serversnode, clients and tools (Installation level)run: securityUtilitysyncNode.sh configureFIPS To enable for a specific server: securityUtility configureFIPS --server=&ltserver_nameltdmgr_host> To enable for a specific client: securityUtility configureFIPS --client=&ltclient_nameltdmgr_port> This4. commandStart configuresnode theagents FIPS enablement requirements and creates a Java security properties file.servers 3.Implementation (Optional)for ToStandalone create a custom profile in a specific locationProfile: securityUtility1. configureFIPSBack --customProfileFile=&ltfile_path> Theup defaultthe profileexisting locations areconfiguration: - Installation level: &ltLiberty install location>/wlp/etc/FIPS140-3-Liberty-ApplicationbackupConfig.properties -sh Server level: &ltserver rootltbackup_directory>/resources/security/FIPS140-3-Liberty-Application.properties - Client level: &ltclient root>/resources/security/FIPS140-3-Liberty-Application.properties 42. RestartEnable the Liberty server to enable FIPS 140-3. When the server restarts after FIPS 140-3 is enabled: -Option A new ltpa.keys file is automatically created with FIPS-approved algorithms. -Using ExistingAdministrative ltpa.keys files are backed up to ltpa.keys.nofips.Console: 51. VerifyClick TLSSecurity protocol» isSSL setcertificate toand TLSkey 1.2management or» TLSManage 1FIPS.3 in the ${server.config.dir}/server.xml file. &ltssl id="defaultSSLConfig" sslProtocol="TLSv1.2". /> or &ltsslSelect id="defaultSSLConfig"Enable sslProtocol="TLSv1.3" /> 6. SAML Configuration: If SAML is used, configure only FIPS 140-3-approved signature algorithms in the ${server".config 3.dir}/server.xml file. ApprovedClick algorithms: SHA256, SHA384, SHA512, ECDSAwithSHA256, ECDSAwithSHA384, ECDSAwithSHA512 Example: &ltsamlWebSso20 id="defaultSPApply" signatureMethodAlgorithm="SHA256" />. AlternativeOption LTPAB Key- CreationUsing Method: ToAdmin manually create LTPA keys with FIPS 140-3-approved algorithmsCommand: 1AdminTask.enableFips('[-enableFips Configuretrue FIPS-fipsLevel 140FIPS140-3 at the installation level (as shown in step 2 above]'). 2.For Runboth the securityUtility createLTPAKeys command: securityUtility createLTPAKeys --password=mypassword --passwordEncoding=aes Important: If LTPA validation keys existmethods, deleterestart these and generate new validation keys after FIPS 140-3 is enabled using the securityUtilityapplication createLTPAKeys commandserver.

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-283668 in V2R5