{"stig":{"title":"IBM WebSphere Liberty Server Security Technical Implementation Guide","version":"2","release":"4"},"checks":[{"vulnId":"V-250322","ruleId":"SV-250322r960735_rule","severity":"medium","ruleTitle":"Maximum in-memory session count must be set according to application requirements.","description":"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.\n\nApplication 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 DoD-recommended values, but the settings should be configurable to allow for future DoD direction. While the DoD will specify recommended values, the values can be adjusted to accommodate the operational requirement of a given system.\n\nThe 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: \n\n\nFor 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.","checkContent":"Review the System Security plan to determine the maximum number of concurrent sessions allowed. This is a per user setting and must be defined by the application admins.\n\nAs a privileged user with access to the server.xml file, review file content and identify the \"maxInMemorySessionCount\" and the allowOverflow settings.\n\nEXAMPLE:\ngrep -i maxInMemorySessionCount server.xml\n\n \n\nIf maxInMemorySessionCount is not set in server.xml according to the settings defined in the system security plan or if allowOverflow=\"true\", this is a finding.","fixText":"To limit the max number of concurrent sessions available, the ${server.config.dir}/server.xml must be configured with maxInMemorySessionCount set according to system security plan and allowOverflow=\"false\".\n\nEXAMPLE:\n","ccis":["CCI-000054"]},{"vulnId":"V-250323","ruleId":"SV-250323r960759_rule","severity":"medium","ruleTitle":"The WebSphere Liberty Server Quality of Protection (QoP) must be set to use TLSv1.2 or higher.","description":"Quality of Protection in WebSphere Liberty specifies the security level, ciphers, and mutual authentication settings for the Secure Socket Layer (SSL/TLS) configuration. For Quality of Protection 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 SSL feature (ssl-1.0) must be defined in order to configure ssl settings, and the ldap feature (ldapRegistry-3.0) must be defined in order to configure an enterprise-level user registry for authentication of users.","checkContent":"As a privileged user with local file access to ${server.config.dir}/server.xml, verify the appSecurity-x.x feature and the sslProtocol settings are configured.\n\ngrep -i appsecurity- server.xml\n\nRESULT:\nappSecurity-2.0\n\nVerify the SSL protocol setting is configured for TLSV1.2 for every SSL configuration. There can be multiple SSL configurations and SSL ID settings.\n\ngrep -i \"\n\nIf the SSL protocol setting does not specify TLS v.1.2 or higher, or if the appSecurity feature is not configured, this is a finding.","fixText":"To ensure the QoP is set to TLS v1.2 or higher, the ${server.config.dir}/server.xml file must be configured as follows: \n\nappSecurity-2.0ssl-1.0\n\nFor every SSL configuration, the sslProtocol field must be set to TLS v1.2 or higher.\n\n ","ccis":["CCI-000068"]},{"vulnId":"V-250324","ruleId":"SV-250324r960762_rule","severity":"medium","ruleTitle":"Security cookies must be set to HTTPOnly.","description":"Web applications use cookies to track users across requests. These cookies, while typically not sensitive in themselves, connect to the existing state on the back-end system. If an intruder were to capture one of these cookies, they could potentially use the cookie to act as the user. Important web traffic should be encrypted using SSL. This includes important cookies.\n\nIn the case of WebSphere Liberty Server, the most important cookies are the LTPA cookie and session cookie; therefore, both should be configured to be only sent over SSL. To set httpOnly on the application server’s cookies, the security feature (appSecurity-2.0) must be defined in order to configure a user registry for the servlet to authenticate against. The servlet (servlet-3.1) feature must be defined in order to deploy web applications, the ssl (ssl-1.0) feature must be defined in order to do SSL communications, and the ldap feature (ldapRegistry-3.0) must be defined in order to configure an enterprise-level user registry for authentication of users. \n\nFor the LTPA cookie, the httpOnlyCookies element must be set to true: \n \n\nFor the JSESSIONID cookie, the cookieHttpOnly element must be set to true: \n","checkContent":"As a user with local file access to ${server.config.dir}/server.xml, verify appSecurity feature is enabled.\n\nappSecurity-2.0\n\nVerify both web application LTPA and http session cookies are configured for httpOnly.\n\n \n\n\n\nIf the appSecurity feature is not enabled or if the LPTA or Session cookie settings are not set for httpOnly, this is a finding.","fixText":"To ensure security cookies use httpOnly, the ${server.config.dir)/server.xml must be configured as follows: \n\nappSecurity-2.0\n\n \n\n","ccis":["CCI-001453"]},{"vulnId":"V-250325","ruleId":"SV-250325r1015250_rule","severity":"medium","ruleTitle":"The WebSphere Liberty Server must log remote session and security activity.","description":"Security auditing must be configured in order to log remote session activity. Security auditing will not be performed unless the audit feature (audit-1.0) has been enabled. The security feature (appSecurity-2.0) must be enabled for the security auditing to capture security transactions. Remote session activity will then be logged, regardless of the user attempting that activity.\n\nSatisfies: SRG-APP-000016-AS-000013, SRG-APP-000080-AS-000045, SRG-APP-000089-AS-000050, SRG-APP-000091-AS-000052, SRG-APP-000095-AS-000056, SRG-APP-000096-AS-000059, SRG-APP-000097-AS-000060, SRG-APP-000098-AS-000061, SRG-APP-000099-AS-000062, SRG-APP-000100-AS-000063, SRG-APP-000101-AS-000072, SRG-APP-000266-AS-000168, SRG-APP-000343-AS-000030, SRG-APP-000172-AS-000121","checkContent":"Review the ${server.config.dir}/server.xml file and ensure audit-1.0 and appSecurity-2.0 are defined within the setting in the server.xml file. \n\nIf audit-1.0 and appSecurity-2.0 are not defined within the setting in the server.xml file, this is a finding. \n\nEXAMPLE:\n\naudit-1.0\nappSecurity-3.0\n","fixText":"To log remote access events, the featureManager setting in the ${server.config.dir}/server.xml must contain the audit and appSecurity features. \n\n\naudit-1.0\nappSecurity-2.0\n","ccis":["CCI-000067","CCI-000130","CCI-000131","CCI-000132","CCI-000133","CCI-000134","CCI-000135","CCI-000162","CCI-000166","CCI-000169","CCI-000172","CCI-001312","CCI-001487","CCI-002234"]},{"vulnId":"V-250326","ruleId":"SV-250326r1137578_rule","severity":"high","ruleTitle":"Users in the REST API admin role must be authorized.","description":"Users with console access and OS permissions to the folders where the Liberty Server is installed can make changes to the server. In addition, REST API calls that execute server management tasks are available and can be executed remotely. Adding a user to the admin role will allow that user to make changes to the server via the REST API calls.\n\nThe admin role must be controlled and users who are in that role must be authorized.","checkContent":"As a user with access to ${server.config.dir}/server.xml, review the file and look for the admin role settings.\n\ngrep -i administrator-role ${server.config.dir}/server.xml\ngrep -i quickstartsecurity ${server.config.dir}/server.xml\n\nIf the admin role has been created, users in that role must be documented and approved. However, using the basic registry or the quickstartsecurity methods are not acceptable. The preferred user registry method is to use a centralized access control method via LDAP. \n\nIf no admin users exist at all, this is not a finding.\n\nIf admin users in an LDAP user registry configuration are not documented and approved, this is a finding.\n\nIf admin users exist in a basic user registry configuration, or in a quickstartsecurity user configuration, this is a finding.\n\nLDAP EXAMPLE:\n\n cn=bob,o=ibm,c=us\n \n\nBASIC REGISTRY EXAMPLE:\n\n \n \n \n \n \n\n\n bob\n group1\n \n\nQUICKSTARTSECURITY EXAMPLE:\n\n restConnector-2.0\n \n \n ","fixText":"If an admin user exists in either a basic user registry or a quickstartsecurity registry, edit the ${server.config.dir}/server.xml file and remove the basic registry and/or quickstartsecurity registry settings.\n\nIf an admin user exists via an LDAP user registry setting, document and approve the user(s) or group that have been assigned to the admin role and ensure anyone granted REST API admin rights is authorized.\n\nLDAP EXAMPLE:\n\n cn=bob,o=ibm,c=us\n \n\nBASIC REGISTRY EXAMPLE:\n\n \n \n \n \n \n\n\n bob\n group1\n \n\nQUICKSTARTSECURITY EXAMPLE:\n\n restConnector-2.0\n \n \n ","ccis":["CCI-000213"]},{"vulnId":"V-250327","ruleId":"SV-250327r1043188_rule","severity":"medium","ruleTitle":"The WebSphere Liberty Server must be configured to offload logs to a centralized system.","description":"Log processing failures include, but are not limited to, failures in the application server log capturing mechanisms or log storage capacity being reached or exceeded. In some instances, it is preferred to send alarms to individuals rather than to an entire group. Application servers must be able to trigger an alarm and send an alert to, at a minimum, the SA and ISSO in the event there is an application server log processing failure.\n\nSatisfies: SRG-APP-000109-AS-000070, SRG-APP-000358-AS-000064","checkContent":"As a privileged user with local file access to ${server.config.dir}/server.xml, verify the logstashCollector-1.0 feature is enabled.\n\ngrep -i -A5 logstashcollector server.xml\n\nEXAMPLE:\n\n logstashCollector-1.0\n\n\n\"\n port=\"\"\n sslRef=\"DefaultTLSSettings\"\n \n\nIf \"logstashCollector\" is not a configured feature and the logstashCollector \"source\" setting does not contain \"message,accessLog,audit\", this is a finding.","fixText":"To send Liberty logs to a centralized syslog system, the Elastic environment must be set up as per the ELK stack/Elasticsearch directions. Once that is completed, configure the server.xml. The following is a sample configuration. Individual keystore, truststore, and authentication settings will vary. The SME must substitute their own values as needed. \n\nThe message, audit, and accessLog sources must be included at a minimum.\n\nFor additional information refer to the IBM website:\nhttps://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.WebSphere.wlp.doc/ae/twlp_analytics_logstash.html\n\nEXAMPLE:\n\n\n logstashCollector-1.0\n\n\n\n\n\n\n\n","ccis":["CCI-000140","CCI-001851"]},{"vulnId":"V-250328","ruleId":"SV-250328r960933_rule","severity":"medium","ruleTitle":"The WebSphere Liberty Server must protect log information from unauthorized access or changes.","description":"WebSphere Liberty provides the capability to encrypt and sign the log data to prevent unauthorized modification. \n\n- The security feature (appSecurity-2.0) must be defined in order to configure a user registry for the servlet to authenticate against. \n- The audit feature (audit-1.0) must be defined in order to generate audit records.\n- The servlet feature (servlet-3.1) must be defined to be able to deploy a web application. \n- The ejb feature (ejbLite-3.1) must be defined to be able to deploy an ejb application.\n- The ssl feature (ssl-1.0) must be defined to be able to generate and use certificates to sign and encrypt logs.\n- The ldap feature (ldapRegistry-3.0) must be defined in order to configure an enterprise-level user registry to authenticate users against.\n\nWhen the audit-1.0 feature is defined, all supported audit events will be captured and logged to an audit.log located under ${server.config.dir}/logs.\n\nThe audit log that is currently being logged to is called audit.log. When an audit log fills to a configured maximum capacity, it is archived with a timestamp with the naming convention audit_.log and new records are written to audit.log. \n\nThe audit logs are found under the ${server.config.dir}/logs directory and are named audit.log for the most recent, and audit_.log for any archived logs. \n\nTwo keystores need to be created (ikeyman as part of the JDK may be used) and a personal certificate created in each. One keystore will contain the certificate used to encrypt the logs; the other keystore will contain the certificate used to sign the logs. The audit configuration needs to define the location of these two keystores, their passwords, and the alias of each certificate used to encrypt and sign the logs. As an example: \n \n\n \n\n\n\n\nSatisfies: SRG-APP-000119-AS-000079, SRG-APP-000120-AS-000080","checkContent":"As a user with local file access to ${server.config.dir}/logs, verify the following audit log files have the correct file permissions of 660.\n\naudit.log\nmessages.log\nconsole.log\ntrace.log (if it exists)\n\nIf the file permissions for these files are not set to 660, this is a finding.","fixText":"As a user with local file access to ${server.config.dir}/logs, use the chmod command to configure the following log files to have the correct file permissions of 660.\n\nchmod 660 \n\naudit.log\nmessages.log\nconsole.log\ntrace.log (if it exists)","ccis":["CCI-000163","CCI-000164"]},{"vulnId":"V-250329","ruleId":"SV-250329r960939_rule","severity":"medium","ruleTitle":"The WebSphere Liberty Server must protect log tools from unauthorized access.","description":"Protecting log data also includes identifying and protecting the tools used to view and manipulate log data. Depending on the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. Therefore, it is imperative that access to log tools be controlled and protected from unauthorized access. \n\nApplication servers provide a web- and/or a command line-based management functionality for managing the application server log capabilities. In addition, subsets of log tool components may be stored on the file system as jar or xml configuration files. The application server must ensure that in addition to protecting any web-based log tools, any file system-based tools are protected as well.","checkContent":"As a user with local file access to the /opt/IBM/WebSphere/Liberty/bin folder, verify the following audit tool files have the correct file permissions of 755.\n\nbinaryLog\nauditUtility\n\nIf the file permissions for these files are not set to 755, this is a finding.","fixText":"As a user with local file access to the /opt/IBM/WebSphere/Liberty/bin/ folder, use the chmod command to configure the correct file permissions of 755 for the following files.\n\nbinaryLog\nauditUtility","ccis":["CCI-001493"]},{"vulnId":"V-250330","ruleId":"SV-250330r960951_rule","severity":"medium","ruleTitle":"The WebSphere Liberty Server must be configured to encrypt log information.","description":"Protection of log records is of critical importance. Encrypting log records provides a level of protection that does not rely on host-based protections that can be accidentally misconfigured, such as file system permissions. Cryptographic mechanisms are the industry-established standard used to protect the integrity of log data. An example of a cryptographic mechanism is the computation and application of a cryptographic-signed hash using asymmetric cryptography. \n\n- The security feature (appSecurity-2.0) must be defined in order to configure a user registry for the servlet to authenticate against. \n- The audit feature (audit-1.0) must be defined in order to generate audit records.\n- The servlet feature (servlet-3.1) must be defined to be able to deploy a web application. \n- The ejb feature (ejbLite-3.1) must be defined to be able to deploy an ejb application.\n- The ssl feature (ssl-1.0) must be defined to be able to generate and use certificates to sign and encrypt logs.\n- The ldap feature (ldapRegistry-3.0) must be defined in order to configure an enterprise-level user registry to authenticate users against.\n\nWhen the audit-1.0 feature is defined, all supported audit events will be captured and logged to an audit.log located under ${server.config.dir}/logs.\n\nThe audit log that is currently being logged to is called audit.log. When an audit log fills to a configured maximum capacity, it is archived with a timestamp with the naming convention audit_.log and new records are written to audit.log. \n\nThe audit logs are found under the ${server.config.dir}/logs directory and are named audit.log for the most recent, and audit_.log for any archived logs. \n\nOne keystore needs to be created (ikeyman as part of the JDK may be used) and a personal certificate created. This certificate is used to encrypt the logs. The audit configuration needs to define the location of this keystore, its password, and the alias of the certificate used to encrypt the logs. As an example: \n \n\n \n\n\n\nSatisfies: SRG-APP-000126-AS-000085, SRG-APP-000118-AS-000078, SRG-APP-000267-AS-000170","checkContent":"If the system is configured to send logs to a remote ELK stack log server, as per requirement IBMW-LS-000230, (or other remote logging solution) this requirement is Not Applicable.\n\nAs a user with local file access to ${server.config.dir}/server.xml: \n\n1. Verify the following features are configured.\n\n \nappSecurity-2.0\naudit-1.0\nssl-1.0\n\n\n2. Verify a keystore is configured. The following is an example:\n\n \n\n \n\n3. Verify auditFileHandler encryption is enabled. Signing is optional.\n\n\n\n\nIf the features and keystore are not configured, and encryption is not enabled, this is a finding.","fixText":"If the system is configured to send logs to a remote ELK stack log server, (or other remote logging solution) as per requirement IBMW-LS-000230, this requirement is Not Applicable.\n\nSigning is optional. The encrypted and/or signed audit logs are found under the ${server.config.dir}/logs directory and are named audit.log for the most recent, and audit_.log for any archived logs. Two keystores are recommended but not required when doing both encryption and signing (ikeyman as part of the JDK may be used) and a certificate imported into each. One keystore will contain the certificate used to encrypt the logs; the other keystore will contain the certificate used to sign the logs. The audit configuration must define the location of every keystore, their passwords, and the alias of each certificate used to encrypt and sign the logs.\n\n1. Enable the following features:\n\n\nappSecurity-2.0\naudit-1.0\nssl-1.0\n\n\n\n2. Verify a keystore is configured. The following is a JKS keystore example. PKCS12 is also a viable keystore:\n\n \n\n \n\n3. Enable auditFileHandler encryption. Signing the logs is optional.\n\n\n","ccis":["CCI-000162","CCI-001314","CCI-001350"]},{"vulnId":"V-250331","ruleId":"SV-250331r960960_rule","severity":"medium","ruleTitle":"The WebSphere Liberty Server must protect software libraries from unauthorized access.","description":"Application servers have the ability to specify that the hosted applications use shared libraries. The application server must have a capability to divide roles based upon duties wherein one project user (such as a developer) cannot modify the shared library code of another project user. The application server must also be able to specify that non-privileged users cannot modify any shared library code at all.","checkContent":"As a privileged user with local file access to the /opt/IBM/WebSphere/Liberty/lib/ folder, verify all of the jar files in the lib folder have the correct file permissions of 664.\n\nIf the file permissions for all jar files in the lib folder are not set to 664, this is a finding.","fixText":"As a privileged user with local file access to the /opt/IBM/WebSphere/Liberty/lib/ folder, verify all of the jar files in the lib folder have the correct file permissions of 664.\n\nIf the file permissions for all jar files in the lib folder are not set to 664, use the chmod command to change the file permissions.\n\nchmod 664 *.jar","ccis":["CCI-001499"]},{"vulnId":"V-250332","ruleId":"SV-250332r1043177_rule","severity":"medium","ruleTitle":"The WebSphere Liberty Server must prohibit or restrict the use of nonsecure ports, protocols, modules, and/or services as defined in the PPSM CAL and vulnerability assessments.","description":"Some networking protocols may not meet organizational security requirements to protect data and components.\n\nApplication 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 DoD ports and protocols website at https://powhatan.iiie.disa.mil/ports/cal.html.","checkContent":"As a privileged user with access to the server.xml file, review the file and identify all TCPIP ports used by the server. \n\nEXAMPLE:\ngrep -I \"port=\" server.xml\n\n httpsPort=\"9443\">\n\nReview the PPSM site for the list of approved ports. If any of the ports used are not registered with PPSM, this is a finding.","fixText":"Every port listed in ${server.config.dir}/server.xml must be registered with PPSM. \n\nRefer to the PPSM website on https://cyber.mil/ppsm for information.","ccis":["CCI-000382"]},{"vulnId":"V-250333","ruleId":"SV-250333r1051118_rule","severity":"medium","ruleTitle":"The WebSphere Liberty Server must use an LDAP user registry.","description":"To ensure accountability and prevent unauthorized access, application server users must be uniquely identified and authenticated. This is typically accomplished via the use of a user store which is either local (OS-based) or centralized (LDAP) in nature. Best practice guideline to is to use a centralized enterprise LDAP server.\n\nTo ensure support to the enterprise, the authentication must use an enterprise solution.","checkContent":"As a user with local file access to ${server.config.dir}/server.xml file, verify the LDAP user registry is used to authenticate users. If the LDAP user registry is not defined within server.xml, this is a finding. \n\n\nappSecurity-2.0\nldapRegistry-3.0\n\n\n\n","fixText":"To ensure an enterprise user management system is configured to uniquely identify and authenticate users and processes acting on behalf of org users, the server.xml must be configured to use an ldap configuration as follows:\n\n\nappSecurity-2.0\nldapRegistry-3.0\n\n\n\n","ccis":["CCI-000764"]},{"vulnId":"V-250334","ruleId":"SV-250334r1051118_rule","severity":"medium","ruleTitle":"Basic Authentication must be disabled.","description":"Basic authentication does not use a centralized user store like LDAP. Not using a centralized user store complicates user management tasks and increases the risk that user accounts could remain on the system long after users have moved to their next deployment. Basic Auth also stores user credentials and passwords on the system and creates the potential for an attacker to circumvent strong authentication requirements like multi-factor or certificate based authentication.\n\nAllowing failover to Basic Auth allows the Liberty Server to fall back to basic authentication in the event certificate based authentication methods fail. Configuring the Liberty Server to fall back to basic authentication creates the potential for an attacker to circumvent strong authentication requirements and must be avoided.","checkContent":"As a privileged user with local file access to the ${server.config.dir}/server.xml file, search the server.xml for the basicRegistry setting.\n\ngrep -i basicregistry server.xml\n\nSAMPLE:\n\n \n \n \n \n \n \n \n \n\nIf settings are defined in server.xml, this is a finding.","fixText":"Delete basicRegistry settings and re-configure the server.xml file to use a centralized LDAP user store. \n\nSAMPLE:\n\n\nappSecurity-2.0\nldapRegistry-3.0\n\n\n\n","ccis":["CCI-000764"]},{"vulnId":"V-250335","ruleId":"SV-250335r1015469_rule","severity":"high","ruleTitle":"Multifactor authentication for network access to privileged accounts must be used.","description":"Multifactor authentication creates a layered defense and makes it more difficult for an unauthorized person to access the application server. If one factor is compromised or broken, the attacker still has at least one more barrier to breach before successfully breaking into the target. Unlike a simple username/password scenario where the attacker could gain access by knowing both the username and password without the user knowing his account was compromised, multifactor authentication adds the requirement that the attacker must have something from the user, such as a token, or to biometrically be the user.\n\nWhen accessing the application server via a network connection, administrative access to the application server must be PKI Hardware Token enabled.\n\nThe high level steps required for configuring Liberty Server to use certificate based authentication include the following:\n\n1. Configure Web Application with client certificate authentication.\n2. Configure Liberty SSL configuration with client authentication.\n3. Configure Liberty LDAP Security Configuration with certificate filter.\n\nSatisfies: SRG-APP-000149-AS-000102, SRG-APP-000151-AS-000103, SRG-APP-000402-AS-000247, SRG-APP-000403-AS-000248, SRG-APP-000177-AS-000126","checkContent":"As a user with local file access to ${server.config.dir}/server.xml file, verify the TLS connection used for managing the server is configured to use clientAuthentication.\n\n\nappSecurity-2.0\nldapRegistry-3.0\ntransportSecurity-1.0\n\n\nVerify the TLS connection used for managing the server is configured to use clientAuthentication. The following is used as an example.\n\nIf the clientAuthentication setting for the TLS management application is not set to \"true\", this is a finding.\n\nEXAMPLE:\n \n \n \n\nAccess the web management interface via a web browser and verify TLS secured connectivity to the web based management application.","fixText":"Refer to IBM documentation on how to configure TLS and client based certificate authentication for additional configuration details. The following is a summary list of items needed to configure the system for certificate based authentication. Production systems and installations will vary. \n\nThe application’s web.xml file must be configured to use client certs.\n\nEXAMPLE:\n\n CLIENT-CERT\n\n\nThe server.xml features must be configured to use transportSecurity and an ldap configuration. \n\n\nappSecurity-2.0\nldapRegistry-3.0\ntransportSecurity-1.0\n\n\nThe server.xml TLS and LDAP settings must be configured. The following is an EXAMPLE only. \"Default\" verbiage and keystore information in the below SSL configuration will be different in production systems.\n\n \n \n \n\n \n \n\nConfigure LDAP certificate filter settings according the certificates being used.\n\n\n","ccis":["CCI-000187","CCI-000765","CCI-002009","CCI-002010"]},{"vulnId":"V-250336","ruleId":"SV-250336r1015470_rule","severity":"high","ruleTitle":"The WebSphere Liberty Server must store only encrypted representations of user passwords.","description":"WebSphere Liberty can either provide a local account store or integrate with enterprise account stores such as LDAP directories. If the application server stores application passwords in the server.xml configuration files, the application server must store encrypted representations of passwords rather than unencrypted, clear-text passwords.\n\nThe Liberty Application Server provides a SecurityUtility tool that can take a plain-text or encoded password and convert it to an encrypted password. This tool does not update the ${server.config.dir/server.xml file directly; a manual update of the server.xml is needed once the utility is run. \n\nIt is imperative that administrators understand that the SecurityUtility tool must be run for each application password that is stored within the server.xml file.\n\nSatisfies: SRG-APP-000171-AS-000119, SRG-APP-000428-AS-000265, SRG-APP-000429-AS-000157","checkContent":"As a privileged user with file access to ${server.config.dir}/server.xml, review and ensure there are no clear-text passwords stored within the server.xml file.\n\nIf any passwords appear in plain text, or if any passwords start with {xor}, this is a finding.","fixText":"For additional information regarding the use of the SecurityUtility command, refer to IBM’s website: \nhttps://www.ibm.com/docs/en/was-liberty/base?topic=applications-securityutility-command\n\nCreate a new xml file with file permissions of 660.\n\nFile owner and group membership is the same as the WebSphere Liberty server user.\n\nAdd the following line to the new xml file:\n\n\n\nIn the above, \"mysecret\" is the passphrase selected to create a cryptographic hash that represents the password.\n\nSave the file to a secured location. Note the path and name, as it will be needed when updating server.xml.\n\nEdit the server.xml file and add the following line:\n\n\" />\n\nFor every unencrypted password in server.xml, run the following SecurityUtility command, which can be found in the Liberty Server install path:\n\nSecurityUtility encode --encoding=aes \n\nThis will prompt the user to enter the plain-text password stored within the server.xml file.\n\nThe SecurityUtility tool will generate an AES cryptographic hash of the password.\n\nCopy and replace the plain-text password with the hashed value.\n\nThis must be done for every plain-text password in server.xml.\n\nRestart the server by entering: \nserver stop \nserver start ","ccis":["CCI-000196","CCI-004062","CCI-002475","CCI-002476"]},{"vulnId":"V-250337","ruleId":"SV-250337r961029_rule","severity":"high","ruleTitle":"The WebSphere Liberty Server must use TLS-enabled LDAP.","description":"Passwords need to be protected at all times, and encryption is the standard method for protecting passwords during transmission. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised.\n\nApplication servers have the capability to use either certificates (tokens) or user IDs and passwords in order to authenticate. When the application server transmits or receives passwords, the passwords must be encrypted. The certificate used by LDAP to establish trust with incoming client requests must be imported into a trust keystore created on the Liberty Server (JDK ikeyman may be used to do this). The LDAP configuration must indicate it is using SSL, provide the BindDN and BindPassword and point to the trust keystore containing the LDAP certificate.","checkContent":"As a user with local file access to ${server.config.dir}/server.xml, verify TLS-enabled LDAP is in use. If TLS-Enabled LDAP is not defined within server.xml, this is a finding. \n\n\nappSecurity-2.0\nssl-1.0\nldapRegistry-3.0\n\n\n\n \n\n\n\n\n","fixText":"To ensure the Liberty Server transmits only encrypted passwords, the ${server.config.dir}/server.xml must be configured as follows:\n\n\nappSecurity-2.0\nssl-1.0\nldapRegistry-3.0\n\n\n\n \n\n\n\n\n","ccis":["CCI-000197"]},{"vulnId":"V-250338","ruleId":"SV-250338r961044_rule","severity":"medium","ruleTitle":"The WebSphere Liberty Server must use DoD-issued/signed certificates.","description":"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.\n\nSatisfies: SRG-APP-000177-AS-000126, SRG-APP-000427-AS-000264, SRG-APP-000514-AS-000137","checkContent":"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.\n\ngrep -i ssldefault server.xml\n\nIdentify the default ssl configuration by examining the sslRef flag.\n\nSAMPLE:\n \n\nReview the default ssl configuration to identify the default truststore.\n\nSAMPLE:\n \n \n\nUse the java keytool or ikeyman utilities to open and examine the certificates stored in the truststore.\n\nIf the certificates are self signed or not signed by a DoD approved CA, this is a finding.","fixText":"Do not use self-signed certificates in a production environment. Only import certificates signed by an authorized DoD CA or authorized for DoD use. \n\nObtain the signer certificate either as a Base 64-encoded ASCII file or as binary DER data. \n\nUsing the JDK’s ikeyman or keytool utility, open the default trusted keystore specified in the ${server.config.dir}/server.xml. \n\nClick on signer certificates and import the file that contains the DoD signed certificate.","ccis":["CCI-000187","CCI-002450","CCI-002470"]},{"vulnId":"V-250339","ruleId":"SV-250339r1193261_rule","severity":"high","ruleTitle":"The WebSphere Liberty Server must use FIPS 140-2 approved encryption modules when authenticating users and processes.","description":"Application servers must use and meet requirements of the DOD Enterprise PKI infrastructure for application authentication. Encryption is only as good as the encryption modules used. Unapproved cryptographic module algorithms cannot be verified or relied upon to provide confidentiality or integrity, and DOD data may be compromised due to weak algorithms. The use of TLS provides confidentiality of data in transit between the application server and client. \n\nTLS must be enabled and non-FIPS-approved SSL versions must be disabled. NIST SP 800-52 specifies the preferred configurations for government systems.","checkContent":"Note: If FIPS 140-3 is configured in IBMW-LS-001200, then this is Not Applicable.\n\nThere are two ways to meet this requirement. Only one method is required.\n\nIf IBM JDK 8 is installed and configured to run with WebSphere Liberty, proceed with method (I).\n\nIf IBM Semeru Runtimes version 11 and above is installed and configured with WebSphere Liberty, proceed with method (II). Currently IBM Semeru supports FIPS on RedHat Enterprise Linux.\n\nMethod (I) IBM JDK 8 is configured to run with WebSphere Liberty:\n\n1. Review the ${server.config.dir}/jvm.options file. Verify FIPS is in use by checking the following lines:\n \nDcom.ibm.jsse2.usefipsprovider=true \nDcom.ibm.jsse2.usefipsProviderName=IBMJCEPlusFIPS\n\nIf the properties are not set as shown in the ${server.config.dir}/jvm.options file, this is a finding.\n\n2. Open ${JAVA_HOME}/jre/lib/security/java.security file. Locate the list of cryptographic providers and confirm the following entries in the provider list:\n\ncom.ibm.jsse2.IBMJSSEProvider2\ncom.ibm.crypto.plus.provider.IBMJCEPlusFIPS\ncom.ibm.crypto.provider.IBMJCE\ncom.ibm.crypto.plus.provider.IBMJCEPlus\n\nIf the entries are not set as shown in the ${JAVA_HOME}/jre/lib/security/java.security file, this is a finding.\n\nMethod (II) Semeru Runtimes version 11 and above is installed and configured with WebSphere Liberty. Requires RedHat Enterprise Linux as the Host Operating System.\n\n1. Run the following command on the RedHat Enterprise Linux. Verify FIPS mode is enabled. \n# fips-mode-setup --check\nIf FIPS mode is not enabled, this is a finding.\n \n2. Review the ${server.config.dir}/jvm.options file. Verify \"semeru.fips\" property is set to true. \nDsemeru.fips=true\nIf the property is not set as shown in the ${server.config.dir}/jvm.options file, this is a finding.\n\n3. Confirm NSS packages are installed by running \"# dnf install nss\" in a terminal.\n\n# dnf install nss\nUpdating Subscription Management repositories.\nLast metadata expiration check: 0:56:30 ago on Wed 13 Sep 2023 07:29:35 AM PDT.\nPackage nss-3.79.0-11.el8_7.x86_64 is already installed.\nDependencies resolved.\nNothing to do.\nComplete!\n\nIf the command does not return output stating NSS is installed, this is a finding.\n\n4. Confirm NSS Database has the keystore imported by running \"# certutil -L -d /etc/pki/nssdb\" in a terminal. \n\n# certutil -L -d /etc/pki/nssdb\nCertificate Nickname Trust Attributes\n SSL,S/MIME,JAR/XPI\ndefault CTu,Cu,Cu\n\nIf the command does not return the results as shown, this is a finding.\n\n5. Review the ${server.config.dir}/server.xml and confirm the following entries:\n\nname = NSS-FIPS\nlibrary = /usr/lib64/libsoftokn3.so\nslot = 3\nshowInfo = true\n\nIf the entries are not set as shown in the ${server.config.dir}/server.xml file, this is a finding.\n\n6. Review the ${server.config.dir}/server.xml file with the following steps:\n\n6.1 Locate configuration that is specifying the default SSL configuration for Liberty.\n6.2 Locate the \"keyStoreRef\" attribute in the configuration and find the referenced configuration. \n6.3 Verify the \"provider\" attribute is set to either \"SunPKCS11-NSS-FIPS\" or \"PKCS11-NSS-FIPS\" in the configuration. \n6.4 Verify the \"type\" attribute is set to \"PKCS11\".\n6.5 Verify the \"fileBased\" attribute is set to \"false\".\n6.6 Find the \"location\" attribute for the configuration file of NSS keystore database (In the example below, it is \"/tmp/pkcs11cfg.cfg\").\n6.7 Verify the file is in a location accessible to Liberty.\n\nSnippet of server.xml:\n\n\n\nIf the entries are not set as shown in the ${server.config.dir}/server.xml file, this is a finding.","fixText":"There are two ways to meet this requirement. Only one method is required.\n\nIf IBM JDK 8 is installed and configured to run with WebSphere Liberty, proceed with method (I).\n\nIf IBM Semeru Runtimes version 11 and above is installed and configured with WebSphere Liberty, proceed with method (II). Currently IBM Semeru supports FIPS on RedHat Enterprise Linux.\n\nMethod (I) IBM JDK 8 is configured to run with WebSphere Liberty:\n\n1. Edit/create the ${server.config.dir}/jvm.options file. \nEdit/add the following two properties:\nDcom.ibm.jsse2.usefipsprovider=true \nDcom.ibm.jsse2.usefipsProviderName=IBMJCEPlusFIPS \n\n2. Edit ${JAVA_HOME}/jre/lib/security/java.security file and locate the list of cryptographic providers. Edit/add the following four providers: \n\nsecurity.provider.1=com.ibm.jsse2.IBMJSSEProvider2\nsecurity.provider.2=com.ibm.crypto.plus.provider.IBMJCEPlusFIPS \nsecurity.provider.3=com.ibm.crypto.provider.IBMJCE\nsecurity.provider.4=com.ibm.crypto.plus.provider.IBMJCEPlus\n\nMethod (II) Semeru Runtimes version 11 and above is installed and configured with WebSphere Liberty. Requires RedHat Enterprise Linux as the Host Operating System.\n\n1. Log in as root or super user.\n\n2. Enable FIPS on the RedHat Enterprise Linux. \n$ fips-mode-setup --enable\n$ fips-mode-setup --check\n \n3. Update/create the ${server.config.dir}/jvm.options.\nEdit/add the following property:\nDsemeru.fips=true \n\n4. Install NSS packages. Run \"$ dnf install nss\".\n\n5. Import keystores to NSS Database by using \"pk12util\" command. Replace \"changeit\" for -W option to the desired password. \n\n$ pk12util -i resources/security/key.p12 -W changeit -d /etc/pki/nssdb\npk12util: PKCS12 IMPORT SUCCESSFUL\n\n6. Mark the imported certificates as a trusted certificate authority (CA).\n\n$ certutil -M -n default -t \"CT,CT,CT\" -d /etc/pki/nssdb\n\n7. List the contents of the NSS Database to confirm the alias name and the Trust Attributes.\n\n$ certutil -L -d /etc/pki/nssdb\nCertificate Nickname Trust Attributes\n SSL,S/MIME,JAR/XPI\ndefault CTu,Cu,Cu\n\n8. Create a config file (pkcs11cfg.cfg) with the contents below. It will be used by ${server.config.dir}/server.xml. \n\nname = NSS-FIPS\nlibrary = /usr/lib64/libsoftokn3.so\nslot = 3\nshowInfo = true\n\n9. Update the ${server.config.dir}/server.xml file to use the configuration file in its SSL configuration. \n\n \n\n\n9.1 Find the configuration referenced in the ssl configuration as \"keyStoreRef\". \n9.2 Set \"provider\" attribute to either \"SunPKCS11-NSS-FIPS\" or \"PKCS11-NSS-FIPS\".\n9.3 Set the \"type\" attribute to \"PKCS11\".\n9.4 Set the \"fileBased\" attribute to \"false\".\n9.5 Set the \"location\" attribute to point to the NSS keystore configuration created in step 8 (pkcs11.cfg.cfg).\n9.6 Verify the file is in a location accessible to Liberty.","ccis":["CCI-000803","CCI-001188","CCI-002418","CCI-002422","CCI-002450"]},{"vulnId":"V-250340","ruleId":"SV-250340r1043182_rule","severity":"medium","ruleTitle":"HTTP session timeout must be configured.","description":"An attacker can take advantage of user sessions that are left open, thus bypassing the user authentication process.\n\nTo thwart the vulnerability of open and unused user sessions, the application server must be configured to close the sessions when a configured condition or trigger event is met.\n\nSession termination terminates all processes associated with a user’s logical session except those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated.\n\nConditions or trigger events requiring automatic session termination can include, for example, periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use.\n\nSatisfies: SRG-APP-000295-AS-000263, SRG-APP-000389-AS-000253","checkContent":"As a user with access to the server xml file, review the contents and verify the httpSession time out setting is configured for 10 minutes.\n\nIf the ${server.config.dir}/server.xml does not define the timeout setting as 10 minutes, this is a finding.\n\n","fixText":"The ${server.config.dir}/server.xml file must be configured to update the invalidationTimeout attribute on the httpSession element to set the session timeout value in hours (h) or minutes (m). The server.xml file must define the following: \n\n \n\nBy default, httpSession invalidationTimeout is set to 30m.","ccis":["CCI-002038","CCI-004895","CCI-002361"]},{"vulnId":"V-250341","ruleId":"SV-250341r1015252_rule","severity":"high","ruleTitle":"Application security must be enabled on the WebSphere Liberty Server.","description":"Application security enables security for the applications in the environment. This type of security provides application isolation and requirements for authenticating application users. When a user enables security, both administrative and application security is enabled. \n\nApplication security is in effect only when administrative security is enabled via the security feature. If the application server is to be used for only web applications, only the servlet-3.1 feature needs to be defined. If the application server is to be used for only ejb applications, only the ejbLite-3.1 feature needs to be defined. If both web and ejb applications are to be deployed on the application server, then both the servlet-3.1 and ejbLite-3.1 features need to be defined. The check and fix assumes that the application server will have both web and ejb applications deployed.\n\nSatisfies: SRG-APP-000315-AS-000094, SRG-APP-000014-AS-000009","checkContent":"As a user with local file access to ${server.config.dir}/server.xml file, verify application security is enabled. \n\nIf the appSecurity-2.0 feature is not defined within server.xml, this is a finding.\n\n\nappSecurity-2.0\n","fixText":"Configure the ${server.config.dir}/server.xml file and add the appSecurity-2.0 feature. \n\n\nappSecurity-2.0\n\n\nReview ${server.config.dir}/logs/messages.log\n\nValidate log entry that indicates \"Security service is ready\".","ccis":["CCI-000068","CCI-002314"]},{"vulnId":"V-250342","ruleId":"SV-250342r961353_rule","severity":"medium","ruleTitle":"Users in a reader-role must be authorized.","description":"The reader role is a management role that allows read-only access to select administrative REST APIs as well as the Admin Center UI (adminCenter-1.0). Preventing non-privileged users from viewing privileged functions mitigates the risk that unauthorized individuals or processes may gain unnecessary access to information or privileges.\n\nUsers granted reader role access must be authorized.","checkContent":"As a user with access to the ${server.config.dir}/server.xml file. Review the contents and identify if users have been granted the reader-role.\n\ngrep -i reader-role ${server.config.dir}/server.xml\n\nIf the reader-role has been created, users in that role must be documented and approved. \n\nIf users in the reader-role are not approved, this is a finding.\n\nEXAMPLE:\nappSecurity-2.0\n\n\ngroup\ngroup:realmName/groupUniqueId\nuser\nuser:realmName/userUniqueId\n","fixText":"Edit the ${server.config.dir}/server.xml file. If unauthorized users have been added to the reader-role, remove those users. \n\nOtherwise, document the users who are granted the reader-role access.\n\nTo allow read-only access to select administrative REST APIs, the ${server.config.dir}/server.xml must be configured as follows. Additionally, the users and groups they are a part of must be defined within LDAP.\n\nEXAMPLE:\n\nappSecurity-2.0\n\n\n\ngroup group:realmName/groupUniqueIduseruser:realmName/userUniqueId\n\n\n\n","ccis":["CCI-002235"]},{"vulnId":"V-250343","ruleId":"SV-250343r961392_rule","severity":"medium","ruleTitle":"The WebSphere Liberty Server must allocate JVM log record storage capacity in accordance with organization-defined log record storage requirements.","description":"JVM logs are logs used to store application and runtime related events, rather than audit related events. They are mainly used to diagnose application or runtime bugs. However, they are useful for providing more context when correlated with audit related events. \n\nBy default, Liberty automatically logs the console.log, messages.log, and trace.log but these default settings must be validated.","checkContent":"Review the ${server.config.dir}/bootstrap.properties file, verify console logging is not turned off. If the property com.ibm.ws.logging.console.log.level=OFF, this is a finding. \n\nReview the ${server.config.dir}/server.xml file and verify the logging traceSpecification setting is configured according to system capacity requirements. If the logging traceSpecification settings are not configured, this is a finding.\n\nEXAMPLE:\n","fixText":"Edit the bootstrap.properties file and configure the com.ibm.ws.logging.console.log.level=ON. \n\nEdit the ${server.config.dir}/server.xml file. Configure in accordance with local policy and system storage limits.\n\nEXAMPLE:\n, \n\nwhere maxFileSize is set to the maximum file size defined in local policy and maxFiles is set to the maximum number of historical files defined in local policy and in accordance with system storage limits.","ccis":["CCI-001849"]},{"vulnId":"V-250344","ruleId":"SV-250344r961461_rule","severity":"medium","ruleTitle":"The server.xml file must be protected from unauthorized modification.","description":"When dealing with access restrictions pertaining to change control, it should be noted that any changes to the software, and/or application server configuration could potentially have significant adverse effects on the overall security of the system.\n\nProtect the server.xml file from unauthorized modification by applying file permission restrictions.","checkContent":"As a privileged user with local file access to ${server.config.dir}/server.xml, verify the server.xml file permissions are set to 660.\n\nIf the server.xml file permissions are not set to 660, this is a finding.","fixText":"As a privileged user with local file access to ${server.config.dir}/server.xml.\n\nUse the chmod command to configure the correct file permissions of 660.\n\nchmod 660 server.xml","ccis":["CCI-001813"]},{"vulnId":"V-250345","ruleId":"SV-250345r961521_rule","severity":"medium","ruleTitle":"The WebSphere Liberty Server must prohibit the use of cached authenticators after an organization-defined time period.","description":"Larger authentication cache timeout values can increase security risks. For example, a user who is revoked can still log in by using a credential that is cached in the authentication cache until the cache is refreshed.\n\nSmaller authentication cache timeout values can affect performance. When this value is smaller, the Liberty Server accesses the user registry or repository more frequently.\n\nLarger numbers of entries in the authentication cache, which is caused by an increased number of users, increases the memory usage of the authentication cache. Thus, the application server might slow down and affect performance.\n\nIf cached authentication information is out of date, the validity of the authentication information may be questionable.","checkContent":"Review system security plan and identify the cache timeout parameters for authentication. The value for admin timeout is 10 minutes. However, a case-by-case exception based on operational requirements can be configured with AO acceptance. \n\nAs a privileged user with access to server.xml, review the file and verify the authCache timeout parameter is configured for 10 minutes.\n\ngrep -i authcache server.xml\n\nEXAMPLE:\n\n\nIf the authCache timeout parameter is not configured for 10 minutes, or the AO has not accepted the risk for extending the timeout period specified, this is a finding.","fixText":"Edit the server.xml file and define the authCache timeout value as 10 minutes or AO approved value. Also ensure the appSecurity-2.0 feature is enabled.\n\nEXAMPLE:\n\n \nappSecurity-2.0\n \n\n","ccis":["CCI-002007"]},{"vulnId":"V-250346","ruleId":"SV-250346r1067567_rule","severity":"medium","ruleTitle":"The WebSphere Liberty Server LTPA keys password must be changed.","description":"The default location of the automatically generated Lightweight Third Party Authentication (LTPA) keys file is ${server.output.dir}/resources/security/ltpa.keys. \n\nThe LTPA keys are encrypted with a randomly generated key and a default password of WebAS is initially used to protect the keys. The password is required when importing the LTPA keys into another server. To protect the security of the LTPA keys, change the password. \n\nWhen the LTPA keys are exchanged between servers, this password must match across the servers for Single Sign On (SSO) to work.\n\nAutomated LTPA key generation can create unplanned outages. Plan to change the LTPA keys during a scheduled outage and do not use automated key changes. Distribute the new keys to all nodes in the cell and to all external systems/cells during this outage window.","checkContent":"If LTPA is not used, this requirement is not a finding.\n\nAs a privileged user with access to ${server.config.dir}/server.xml file, review the server.xml file and locate LTPA settings. If the LTPA settings do not exist, this is not a finding.\n\nEXAMPLE:\ngrep -i \"\n\nIf the LTPA setting exists and the password is set to \"WebAS\", this is a finding.","fixText":"To update key password and force a regeneration of keys follow these steps. To obtain encoded values, use the Liberty \"securityUtility encode\" command.\n\n1. Shut down the server.\n\n2. Configure the element in the server.xml file as follows, replacing the sample values in the example with local values. The password may be encoded or encrypted.\n\n\n\n3. Delete the existing ${wlp.server.dir}/resources/security/ltpa.keys file.\n\n4. Sync changes with all servers in the cell.\n\n5. Start the servers.","ccis":["CCI-002475"]},{"vulnId":"V-250347","ruleId":"SV-250347r961632_rule","severity":"medium","ruleTitle":"The WebSphere Liberty Server must remove all export ciphers to protect the confidentiality and integrity of transmitted information.","description":"Export grade encryption suites are not strong and do not meet DoD requirements. The encryption for the session becomes easy for the attacker to break. Do not use export grade encryption.","checkContent":"Review the ${server.config.dir}/server.xml file and check the \"enabledCiphers\" setting. If any of the ciphers specified in the enabledCiphers setting contains the word \"EXPORT\", this is a finding. \n\n","fixText":"Review the ${server.config.dir}/server.xml file and if needed, modify the \"enabledCiphers\" setting for each affected SSL configuration.\n\n \n\nwhere xxx, yyy, and zzz do not contain \"EXPORT\".","ccis":["CCI-002418"]},{"vulnId":"V-250348","ruleId":"SV-250348r1137581_rule","severity":"medium","ruleTitle":"The WebSphere Liberty Server must be configured to use HTTPS only.","description":"Transmission of data can take place between the application server and a large number of devices/applications external to the application server. Examples are a web client used by a user, a backend database, a log server, or other application servers in an application server cluster.","checkContent":"Review the ${server.config.dir}/server.xml file and check the ssl-1.0 feature and httpEndpoint settings. \n\nIf the ssl-1.0 feature is not defined, this is a finding. \n\nIf the httpEndpoint settings do not include ssloptions, this is a finding.\n\n\nservlet-3.0\nssl-1.0\nappSecurity-2.0\n\n\n\n \n \n","fixText":"Modify the server.xml file. Enable the ssl-1.0 feature and configure the httpEndpoint settings. The keystores and truststores must also be configured.\n\n\nservlet-3.0\nssl-1.0\nappSecurity-2.0\n\n \n \n \n \n \n\n \n\n \n\n\n\n\n\n \n\n\n ","ccis":["CCI-002421"]},{"vulnId":"V-250349","ruleId":"SV-250349r1137612_rule","severity":"medium","ruleTitle":"The WebSphere Liberty Server must install security-relevant software updates within the time period directed by an authoritative source.","description":"Security vulnerabilities are often addressed by testing and applying the latest security patches and fix packs. The latest fixpacks can be found at: http://www-01.ibm.com/support/docview.wss?uid=swg27009661","checkContent":"Use the \"productInfo(.bat/.sh) version\" command to determine the WebSphere version. Review the patch level and fix pack. \n\nReview the latest fixpacks at: http://www-01.ibm.com/support/docview.wss?uid=swg27009661 and determine if the system is operating at the latest patch level.\n\nIf the most recent patches/fix packs have not been applied, this is a finding.","fixText":"Obtain WebSphere Liberty product security and patch support at http://www-01.ibm.com/support/docview.wss?uid=swg27009661. \n\nRun the productInfo validate command to validate the MD5 checksum file for server installation and each feature.\n\nIf a feature is not valid, the command outputs an error and lists the manifest file for the affected feature. The following example validates the features for the current installation and outputs the results to the validate.txt file:\n\nproductInfo validate --output=/tmp/validate.txt","ccis":["CCI-002605"]},{"vulnId":"V-250350","ruleId":"SV-250350r961812_rule","severity":"medium","ruleTitle":"The WebSphere Liberty Server must generate log records for authentication and authorization events.","description":"Enabling authentication (SECURITY_AUTHN) and authorization (SECURITY_AUTHZ) event handlers configures the server to record security authorization and authentication events. By logging these events, the logs can be analyzed to identify activity that could be related to security events and to aid post mortem forensic analysis.\n\nSatisfies: SRG-APP-000499-AS-000224, SRG-APP-000495-AS-000220, SRG-APP-000503-AS-000228, SRG-APP-000504-AS-000229, SRG-APP-000505-AS-000230, SRG-APP-000506-AS-000231, SRG-APP-000509-AS-000234, SRG-APP-000092-AS-000053","checkContent":"Review the ${server.config.dir}/server.xml file, verify the audit-1.0 feature is enabled. Also verify the auditFile Handler is configured to log AUTHN and AUTHZ events. \n\nIf the audit1.0 feature is not enabled, this is a finding.\n\nIf the SECURITY_AUTHN and SECURITY_AUTHZ event handlers are not configured, this is a finding. \n\n\naudit-1.0\n\n\n \n \n\n ","fixText":"Modify the ${server.config.dir}/server.xml file and configure the audit-1.0 feature.\n\n\naudit-1.0\n\n\nConfigure the auditFileHandler setting to record SECURITY_AUTHN and SECURITY_AUTHZ events. \n\n\n \n\n \n\nReview audit logs located under the ${server.config.dir}/logs directory and ensure AUTHN and AUTHZ events are logged.","ccis":["CCI-000172","CCI-001464"]},{"vulnId":"V-283668","ruleId":"SV-283668r1193262_rule","severity":"high","ruleTitle":"The WebSphere Liberty Server must use FIPS 140-3-approved encryption modules when authenticating users and processes.","description":"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 DOD 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. \n\nTLS must be enabled and non-FIPS-approved SSL versions must be disabled. NIST SP 800-52 specifies the preferred configurations for government systems.","checkContent":"Note: 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.\n\nThere are two ways to meet this requirement using FIPS 140-3. Only one method is required.\n\nIf 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). \nIf 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).\n\nMethod (I) IBM JDK 8 (version 8.0.8.30 or later) with WebSphere Liberty (version 25.0.0.3 or later):\n\n1. Review the ${server.config.dir}/jvm.options file. Verify FIPS 140-3 is in use by checking the following lines:\n\n-Xenablefips140-3\n-Dcom.ibm.jsse2.usefipsprovider=true\n-Dcom.ibm.jsse2.usefipsProviderName=IBMJCEPlusFIPS\n\nIf the properties are not set as shown in the ${server.config.dir}/jvm.options file, this is a finding.\n\n2. Verify TLS protocol is set to TLS 1.2 or TLS 1.3 in the ${server.config.dir}/server.xml file.\n\nor\n\n\nIf TLS 1.2 or TLS 1.3 is not configured, this is a finding.\n\n3. 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.\n\nDefault location: ${server.output.dir}/resources/security/ltpa.keys\n\nIf LTPA keys were created before FIPS 140-3 was enabled and have not been regenerated, this is a finding.\n\n\nMethod (II) IBM Semeru Runtimes with WebSphere Liberty (FIPS 140-3):\n\n1. Verify FIPS 140-3 is configured by checking for the existence of the FIPS 140-3 profile file in one of the following locations:\n\n- Installation level: /wlp/etc/FIPS140-3-Liberty-Application.properties\n- Server level: /resources/security/FIPS140-3-Liberty-Application.properties\n- Client level: /resources/security/FIPS140-3-Liberty-Application.properties\n\nIf the FIPS 140-3 profile file does not exist, this is a finding.\n\n2. Review the FIPS 140-3 profile file and verify it contains the appropriate security provider configurations. The file should contain entries similar to:\n\nRestrictedSecurity.OpenJCEPlusFIPS.FIPS140-3-Liberty-Application.jce.provider.1 = com.ibm.crypto.plus.\n\nIf the profile file does not contain valid provider configurations, this is a finding.\n\n3. Verify TLS protocol is set to TLS 1.2 or TLS 1.3 in the ${server.config.dir}/server.xml file.\n\n\nor\n\n\nIf TLS 1.2 or TLS 1.3 is not configured, this is a finding.\n\n4. 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.\n\nDefault location: ${server.output.dir}/resources/security/ltpa.keys\n\nIf LTPA keys were created before FIPS 140-3 was enabled and have not been regenerated, this is a\nfinding.\n\n5. 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:\n\nApproved algorithms: SHA256, SHA384, SHA512, ECDSAwithSHA256, ECDSAwithSHA384, ECDSAwithSHA512\n\nExample:\n\n\nIf SHA1 or other nonapproved algorithms are configured, this is a finding.","fixText":"There are two ways to meet this requirement using FIPS 140-3. Only one method is required.\n\nIf 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).\nIf 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).\n\nMethod (I) IBM JDK 8 (version 8.0.8.30 or later) with WebSphere Liberty (version 25.0.0.3 or later):\n\n1. If Liberty server is running, stop it.\n\n2. Edit/create the ${server.config.dir}/jvm.options file. Edit/add the following three properties:\n\n-Xenablefips140-3\n-Dcom.ibm.jsse2.usefipsprovider=true\n-Dcom.ibm.jsse2.usefipsProviderName=IBMJCEPlusFIPS\n\n3. If there are existing LTPA keys, delete the ltpa.keys file before restarting the server to generate new FIPS 140-3-compliant keys.\n\nDefault location: ${server.output.dir}/resources/security/ltpa.keys\n\nA new ltpa.keys file will be automatically created when the Liberty server restarts with FIPS 140-3-compliant keys.\n\n4. Restart the Liberty server to enable FIPS 140-3.\n\n5. Verify TLS protocol is set to TLS 1.2 or TLS 1.3 in the ${server.config.dir}/server.xml file.\n\n\nor\n\n\nAlternative LTPA Key Creation Method:\nTo manually create LTPA keys with FIPS 140-3 approved algorithms using the securityUtility command:\n\n1. Export the required system properties:\n\nexport JVM_ARGS=\"-Xenablefips140-3 -Dcom.ibm.jsse2.usefipsprovider=true -Dcom.ibm.jsse2.usefipsProviderName=2. Run the securityUtility createLTPAKeys command:\nsecurityUtility createLTPAKeys --password=mypassword --passwordEncoding=aes\n\nImportant: 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.\n\nMethod (II) IBM Semeru Runtimes with WebSphere Liberty (FIPS 140-3):\n\n1. Liberty server is running, stop it.\n\n2. Enable FIPS 140-3 using the securityUtility configureFIPS command. To enable across all servers, clients and tools (Installation level):\n\nsecurityUtility configureFIPS\nTo enable for a specific server:\nsecurityUtility configureFIPS --server=\nTo enable for a specific client:\nsecurityUtility configureFIPS --client=\n\nThis command configures the FIPS enablement requirements and creates a Java security properties file.\n\n3. (Optional) To create a custom profile in a specific location:\n\nsecurityUtility configureFIPS --customProfileFile=\n\nThe default profile locations are:\n\n- Installation level: /wlp/etc/FIPS140-3-Liberty-Application.properties\n- Server level: /resources/security/FIPS140-3-Liberty-Application.properties\n- Client level: /resources/security/FIPS140-3-Liberty-Application.properties\n\n4. Restart the Liberty server to enable FIPS 140-3.\n\nWhen the server restarts after FIPS 140-3 is enabled:\n\n- A new ltpa.keys file is automatically created with FIPS-approved algorithms.\n- Existing ltpa.keys files are backed up to ltpa.keys.nofips.\n\n5. Verify TLS protocol is set to TLS 1.2 or TLS 1.3 in the ${server.config.dir}/server.xml file.\n\n\nor\n\n\n6. SAML Configuration: If SAML is used, configure only FIPS 140-3-approved signature algorithms in the ${server.config.dir}/server.xml file.\n\nApproved algorithms: SHA256, SHA384, SHA512, ECDSAwithSHA256, ECDSAwithSHA384, ECDSAwithSHA512\n\nExample:\n\n\nAlternative LTPA Key Creation Method:\nTo manually create LTPA keys with FIPS 140-3-approved algorithms:\n\n1. Configure FIPS 140-3 at the installation level (as shown in step 2 above).\n\n2. Run the securityUtility createLTPAKeys command:\n\nsecurityUtility createLTPAKeys --password=mypassword --passwordEncoding=aes\n\nImportant: If LTPA validation keys exist, delete these and generate new validation keys after FIPS 140-3 is enabled using the securityUtility createLTPAKeys command.","ccis":["CCI-000803","CCI-001188","CCI-002418","CCI-002422","CCI-002450"]}]}