Cyber · Trackr The Free Compliance Library
⌘K
DoD Compliance · STIG

IBM WebSphere Liberty Server Security Technical Implementation Guide

V2R1 · · · Released 24 Oct 2024 · 29 rules
Compare

Pick two releases to diff their requirements.

View

Open a previous version of this STIG.

This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.
Digest of Updates vs. V1R2 · 27 Oct 2022 ✎ 2

Comparison against the immediately-prior release (V1R2). Rule matching uses the Group Vuln ID. Content-change detection compares the rule’s description, check, and fix text after stripping inline markup — cosmetic-only edits aren’t flagged.

Content changes 2

  • V-250325 Medium descriptioncheckfix The WebSphere Liberty Server must log remote session and security activity.
  • V-250341 High check Application security must be enabled on the WebSphere Liberty Server.
Sort by
b
Maximum in-memory session count must be set according to application requirements.
AC-10 - Medium - CCI-000054 - V-250322 - SV-250322r960735_rule
RMF Control
AC-10
Severity
M
CCI
CCI-000054
Version
IBMW-LS-000010
Vuln IDs
  • V-250322
Rule IDs
  • SV-250322r960735_rule
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 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. 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: 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.
Checks: C-53757r795017_chk

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. As a privileged user with access to the server.xml file, review file content and identify the "maxInMemorySessionCount" and the allowOverflow settings. EXAMPLE: grep -i maxInMemorySessionCount server.xml <httpSession maxInMemorySessionCount="xxxx" allowOverflow="false" /> If 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.

Fix: F-53711r795018_fix

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". EXAMPLE: <httpSession maxInMemorySessionCount="5" allowOverflow="false" />

b
The WebSphere Liberty Server Quality of Protection (QoP) must be set to use TLSv1.2 or higher.
AC-17 - Medium - CCI-000068 - V-250323 - SV-250323r960759_rule
RMF Control
AC-17
Severity
M
CCI
CCI-000068
Version
IBMW-LS-000020
Vuln IDs
  • V-250323
Rule IDs
  • SV-250323r960759_rule
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.
Checks: C-53758r862963_chk

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. grep -i appsecurity- server.xml RESULT: &lt;feature&gt;appSecurity-2.0&lt;/feature&gt; Verify the SSL protocol setting is configured for TLSV1.2 for every SSL configuration. There can be multiple SSL configurations and SSL ID settings. grep -i "&lt;ssl id=" server.xml SAMPLE RESULT: &lt;ssl id="TLSSettings" keyStoreRef="TLSKeyStore" trustStoreRef="TLSTrustStore" sslProtocol="TLSv1.2"/&gt; If 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.

Fix: F-53712r862964_fix

To ensure the QoP is set to TLS v1.2 or higher, the ${server.config.dir}/server.xml file must be configured as follows: <featureManager><feature>appSecurity-2.0</feature><feature>ssl-1.0</feature></featureManager> For every SSL configuration, the sslProtocol field must be set to TLS v1.2 or higher. <ssl id="TLSSettings" keyStoreRef="TLSKeyStore" trustStoreRef="TLSTrustStore" sslProtocol="TLSv1.2" />

b
Security cookies must be set to HTTPOnly.
AC-17 - Medium - CCI-001453 - V-250324 - SV-250324r960762_rule
RMF Control
AC-17
Severity
M
CCI
CCI-001453
Version
IBMW-LS-000030
Vuln IDs
  • V-250324
Rule IDs
  • SV-250324r960762_rule
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. In 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. For the LTPA cookie, the httpOnlyCookies element must be set to true: For the JSESSIONID cookie, the cookieHttpOnly element must be set to true:
Checks: C-53759r862966_chk

As a user with local file access to ${server.config.dir}/server.xml, verify appSecurity feature is enabled. &lt;featureManager&gt;&lt;feature&gt;appSecurity-2.0&lt;/feature&gt;&lt;/featureManager&gt; Verify both web application LTPA and http session cookies are configured for httpOnly. &lt;webAppSecurity ssoCookieName="LtpaToken2" ssoRequiresSSL="true" httpOnlyCookies="true" logoutOnHttpSessionExpire="true"/&gt; &lt;httpSession cookieName="JSESSIONID" cookieSecure="true" cookieHttpOnly="true" cookiePath="/"/&gt; If the appSecurity feature is not enabled or if the LPTA or Session cookie settings are not set for httpOnly, this is a finding.

Fix: F-53713r862967_fix

To ensure security cookies use httpOnly, the ${server.config.dir)/server.xml must be configured as follows: <featureManager><feature>appSecurity-2.0</feature></featureManager> <webAppSecurity ssoCookieName="LtpaToken2" ssoRequiresSSL="true" httpOnlyCookies="true" logoutOnHttpSessionExpire="true"/> <httpSession cookieName="JSESSIONID" cookieSecure="true" cookieHttpOnly="true" cookiePath="/"/>

b
The WebSphere Liberty Server must log remote session and security activity.
AC-17 - Medium - CCI-000067 - V-250325 - SV-250325r1015250_rule
RMF Control
AC-17
Severity
M
CCI
CCI-000067
Version
IBMW-LS-000040
Vuln IDs
  • V-250325
Rule IDs
  • SV-250325r1015250_rule
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. Satisfies: 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
Checks: C-53760r1015249_chk

Review the ${server.config.dir}/server.xml file and ensure audit-1.0 and appSecurity-2.0 are defined within the &lt;featureManager&gt; setting in the server.xml file. If audit-1.0 and appSecurity-2.0 are not defined within the &lt;featureManager&gt; setting in the server.xml file, this is a finding. EXAMPLE: &lt;featureManager&gt; &lt;feature&gt;audit-1.0&lt;/feature&gt; &lt;feature&gt;appSecurity-3.0&lt;/feature&gt; &lt;/featureManager&gt;

Fix: F-53714r1015239_fix

To log remote access events, the featureManager setting in the ${server.config.dir}/server.xml must contain the audit and appSecurity features. <featureManager> <feature>audit-1.0</feature> <feature>appSecurity-2.0</feature> </featureManager>

c
Users in the REST API admin role must be authorized.
AC-3 - High - CCI-000213 - V-250326 - SV-250326r960792_rule
RMF Control
AC-3
Severity
H
CCI
CCI-000213
Version
IBMW-LS-000050
Vuln IDs
  • V-250326
Rule IDs
  • SV-250326r960792_rule
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. The admin role must be controlled and users who are in that role must be authorized.
Checks: C-53761r795029_chk

As a user with access to ${server.config.dir}/server.xml, review the file and look for the admin role settings. grep -i administrator-role ${server.config.dir}/server.xml grep -i quickstartsecurity ${server.config.dir}/server.xml If 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. If no admin users exist at all, this is not a finding. If admin users in an LDAP user registry configuration are not documented and approved, this is a finding. If admin users exist in a basic user registry configuration, or in a quickstartsecurity user configuration, this is a finding. LDAP EXAMPLE: &lt;administrator-role&gt; &lt;user&gt;cn=bob,o=ibm,c=us&lt;/user&gt; &lt;/administrator-role&gt; BASIC REGISTRY EXAMPLE: &lt;basicRegistry&gt; &lt;user name="bob" password="bobpassword"/&gt; &lt;user name="joe" password="joepassword"/&gt; &lt;group name="group1" ...&gt; &lt;/group&gt; &lt;/basicRegistry&gt; &lt;administrator-role&gt; &lt;user&gt;bob&lt;/user&gt; &lt;group&gt;group1&lt;/group&gt; &lt;/administrator-role&gt; QUICKSTARTSECURITY EXAMPLE: &lt;featureManager&gt; &lt;feature&gt;restConnector-2.0&lt;/feature&gt; &lt;/featureManager&gt; &lt;quickStartSecurity userName="bob" userPassword="bobpassword" /&gt; &lt;keyStore id="defaultKeyStore" password="keystorePassword"/&gt;

Fix: F-53715r795030_fix

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. If 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. LDAP EXAMPLE: <administrator-role> <user>cn=bob,o=ibm,c=us</user> </administrator-role> BASIC REGISTRY EXAMPLE: <basicRegistry> <user name="bob" password="bobpassword"/> <user name="joe" password="joepassword"/> <group name="group1" ...> </group> </basicRegistry> <administrator-role> <user>bob</user> <group>group1</group> </administrator-role> QUICKSTARTSECURITY EXAMPLE: <featureManager> <feature>restConnector-2.0</feature> </featureManager> <quickStartSecurity userName="bob" userPassword="bobpassword" /> <keyStore id="defaultKeyStore" password="keystorePassword"/>

b
The WebSphere Liberty Server must be configured to offload logs to a centralized system.
AU-5 - Medium - CCI-000140 - V-250327 - SV-250327r960915_rule
RMF Control
AU-5
Severity
M
CCI
CCI-000140
Version
IBMW-LS-000230
Vuln IDs
  • V-250327
Rule IDs
  • SV-250327r960915_rule
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. Satisfies: SRG-APP-000109-AS-000070, SRG-APP-000358-AS-000064
Checks: C-53762r795032_chk

As a privileged user with local file access to ${server.config.dir}/server.xml, verify the logstashCollector-1.0 feature is enabled. grep -i -A5 logstashcollector server.xml EXAMPLE: &lt;featureManager&gt; &lt;feature&gt;logstashCollector-1.0&lt;/feature&gt; &lt;/featureManager&gt; &lt;logstashCollector source="message,accessLog,audit" hostName="&lt;ip address of logstash server&gt;" port="&lt;port of logstash server&gt;" sslRef="DefaultTLSSettings" &lt;/logstashCollector&gt; If "logstashCollector" is not a configured feature and the logstashCollector "source" setting does not contain "message,accessLog,audit", this is a finding.

Fix: F-53716r795033_fix

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. The message, audit, and accessLog sources must be included at a minimum. For additional information refer to the IBM website: https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.WebSphere.wlp.doc/ae/twlp_analytics_logstash.html EXAMPLE: <featureManager> <feature>logstashCollector-1.0</feature> </featureManager> <keyStore id="defaultKeyStore" password="xxxxxxx" /> <keyStore id="defaultTrustStore" location="trust.jks" password="xxxxxxx" /> <ssl id="myTLSConfig" trustStoreRef="defaultTrustStore" keyStoreRef="defaultKeyStore" /> <logstashCollector source="message,accessLog,audit" hostName="your ELK stack server" port="Your ELK stack port" sslRef="myTLSConfig"> </logstashCollector>

b
The WebSphere Liberty Server must protect log information from unauthorized access or changes.
AU-9 - Medium - CCI-000163 - V-250328 - SV-250328r960933_rule
RMF Control
AU-9
Severity
M
CCI
CCI-000163
Version
IBMW-LS-000260
Vuln IDs
  • V-250328
Rule IDs
  • SV-250328r960933_rule
WebSphere Liberty provides the capability to encrypt and sign the log data to prevent unauthorized modification. - The security feature (appSecurity-2.0) must be defined in order to configure a user registry for the servlet to authenticate against. - The audit feature (audit-1.0) must be defined in order to generate audit records. - The servlet feature (servlet-3.1) must be defined to be able to deploy a web application. - The ejb feature (ejbLite-3.1) must be defined to be able to deploy an ejb application. - The ssl feature (ssl-1.0) must be defined to be able to generate and use certificates to sign and encrypt logs. - The ldap feature (ldapRegistry-3.0) must be defined in order to configure an enterprise-level user registry to authenticate users against. When 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. The 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. The 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 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: Satisfies: SRG-APP-000119-AS-000079, SRG-APP-000120-AS-000080
Checks: C-53763r795035_chk

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. audit.log messages.log console.log trace.log (if it exists) If the file permissions for these files are not set to 660, this is a finding.

Fix: F-53717r795036_fix

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. chmod 660 <filename.log> audit.log messages.log console.log trace.log (if it exists)

b
The WebSphere Liberty Server must protect log tools from unauthorized access.
AU-9 - Medium - CCI-001493 - V-250329 - SV-250329r960939_rule
RMF Control
AU-9
Severity
M
CCI
CCI-001493
Version
IBMW-LS-000280
Vuln IDs
  • V-250329
Rule IDs
  • SV-250329r960939_rule
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. Application 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.
Checks: C-53764r795038_chk

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. binaryLog auditUtility If the file permissions for these files are not set to 755, this is a finding.

Fix: F-53718r795039_fix

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. binaryLog auditUtility

b
The WebSphere Liberty Server must be configured to encrypt log information.
AU-9 - Medium - CCI-000162 - V-250330 - SV-250330r960951_rule
RMF Control
AU-9
Severity
M
CCI
CCI-000162
Version
IBMW-LS-000320
Vuln IDs
  • V-250330
Rule IDs
  • SV-250330r960951_rule
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. - The security feature (appSecurity-2.0) must be defined in order to configure a user registry for the servlet to authenticate against. - The audit feature (audit-1.0) must be defined in order to generate audit records. - The servlet feature (servlet-3.1) must be defined to be able to deploy a web application. - The ejb feature (ejbLite-3.1) must be defined to be able to deploy an ejb application. - The ssl feature (ssl-1.0) must be defined to be able to generate and use certificates to sign and encrypt logs. - The ldap feature (ldapRegistry-3.0) must be defined in order to configure an enterprise-level user registry to authenticate users against. When 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. The 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. The 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. One 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: Satisfies: SRG-APP-000126-AS-000085, SRG-APP-000118-AS-000078, SRG-APP-000267-AS-000170
Checks: C-53765r862973_chk

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. As a user with local file access to ${server.config.dir}/server.xml: 1. Verify the following features are configured. &lt;featureManager&gt; &lt;feature&gt;appSecurity-2.0&lt;/feature&gt; &lt;feature&gt;audit-1.0&lt;/feature&gt; &lt;feature&gt;ssl-1.0&lt;/feature&gt; &lt;/featureManager&gt; 2. Verify a keystore is configured. The following is an example: &lt;keyStore id="auditEncKeyStore" password="ENTER THE ENCRYPTION KEYSTORE PASSWORD" location="${server.config.dir}/resources/security/AuditEncryptionKeyStore.jks" type="JKS" /&gt; &lt;keyStore id="auditSignKeyStore" password="ENTER THE SIGNING KEYSTORE PASSWORD" location="${server.config.dir}/resources/security/AuditSigningKeyStore2.jks" type="JKS" /&gt; 3. Verify auditFileHandler encryption is enabled. Signing is optional. &lt;auditFileHandler encrypt="true" encryptAlias="auditencryption" encryptKeyStoreRef="auditEncKeyStore" sign="true" signingAlias="auditsigning2" signingKeyStoreRef="auditSignKeyStore"&gt; &lt;/auditFileHandler&gt; If the features and keystore are not configured, and encryption is not enabled, this is a finding.

Fix: F-53719r862974_fix

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. Signing 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_<timestamp>.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. 1. Enable the following features: <featureManager> <feature>appSecurity-2.0</feature> <feature>audit-1.0</feature> <feature>ssl-1.0</feature> <feature> </featureManager> 2. Verify a keystore is configured. The following is a JKS keystore example. PKCS12 is also a viable keystore: <keyStore id="auditEncKeyStore" password="ENTER THE ENCRYPTION KEYSTORE PASSWORD" location="${server.config.dir}/resources/security/AuditEncryptionKeyStore.jks" type="JKS" /> <keyStore id="auditSignKeyStore" password="ENTER THE SIGNING KEYSTORE PASSWORD" location="${server.config.dir}/resources/security/AuditSigningKeyStore2.jks" type="JKS" /> 3. Enable auditFileHandler encryption. Signing the logs is optional. <auditFileHandler encrypt="true" encryptAlias="auditencryption" encryptKeyStoreRef="auditEncKeyStore" sign="true" signingAlias="auditsigning2" signingKeyStoreRef="auditSignKeyStore"> </auditFileHandler>

b
The WebSphere Liberty Server must protect software libraries from unauthorized access.
CM-5 - Medium - CCI-001499 - V-250331 - SV-250331r960960_rule
RMF Control
CM-5
Severity
M
CCI
CCI-001499
Version
IBMW-LS-000340
Vuln IDs
  • V-250331
Rule IDs
  • SV-250331r960960_rule
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.
Checks: C-53766r795044_chk

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. If the file permissions for all jar files in the lib folder are not set to 664, this is a finding.

Fix: F-53720r795045_fix

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. If 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. chmod 664 *.jar

b
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.
CM-7 - Medium - CCI-000382 - V-250332 - SV-250332r960966_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000382
Version
IBMW-LS-000370
Vuln IDs
  • V-250332
Rule IDs
  • SV-250332r960966_rule
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 DoD ports and protocols website at https://powhatan.iiie.disa.mil/ports/cal.html.
Checks: C-53767r795047_chk

As a privileged user with access to the server.xml file, review the file and identify all TCPIP ports used by the server. EXAMPLE: grep -I "port=" server.xml httpsPort="9443"&gt; Review the PPSM site for the list of approved ports. If any of the ports used are not registered with PPSM, this is a finding.

Fix: F-53721r795048_fix

Every port listed in ${server.config.dir}/server.xml must be registered with PPSM. Refer to the PPSM website on https://cyber.mil/ppsm for information.

b
The WebSphere Liberty Server must use an LDAP user registry.
IA-2 - Medium - CCI-000764 - V-250333 - SV-250333r960969_rule
RMF Control
IA-2
Severity
M
CCI
CCI-000764
Version
IBMW-LS-000380
Vuln IDs
  • V-250333
Rule IDs
  • SV-250333r960969_rule
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. To ensure support to the enterprise, the authentication must use an enterprise solution.
Checks: C-53768r862976_chk

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. &lt;featureManager&gt; &lt;feature&gt;appSecurity-2.0&lt;/feature&gt; &lt;feature&gt;ldapRegistry-3.0&lt;/feature&gt; &lt;/featureManager&gt; &lt;ldapRegistry id="ldap" realm="SampleLdapRealm" host="${ldap.server.name}" port="${ldap.server.port}" ignoreCase="true" baseDN="${ldap.server.base.dn}" ldapType="${ldap.vendor.type}" searchTimeout="8m"&gt; &lt;/ldapRegistry&gt;

Fix: F-53722r862977_fix

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: <featureManager> <feature>appSecurity-2.0</feature> <feature>ldapRegistry-3.0</feature> </featureManager> <ldapRegistry id="ldap" realm="SampleLdapRealm" host="${ldap.server.name}" port="${ldap.server.port}" ignoreCase="true" baseDN="${ldap.server.base.dn}" ldapType="${ldap.vendor.type}" searchTimeout="8m"> </ldapRegistry>

b
Basic Authentication must be disabled.
IA-2 - Medium - CCI-000764 - V-250334 - SV-250334r960969_rule
RMF Control
IA-2
Severity
M
CCI
CCI-000764
Version
IBMW-LS-000381
Vuln IDs
  • V-250334
Rule IDs
  • SV-250334r960969_rule
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. Allowing 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.
Checks: C-53769r795053_chk

As a privileged user with local file access to the ${server.config.dir}/server.xml file, search the server.xml for the basicRegistry setting. grep -i basicregistry server.xml SAMPLE: &lt;basicRegistry id="basic" realm="BasicRealm"&gt; &lt;user name="employee0" password="emp0pwd" /&gt; &lt;user name="employee1" password="emp1pwd" /&gt; &lt;user name="manager0" password="mgr0pwd" /&gt; &lt;group name="employeeGroup"&gt; &lt;member name="employee0" /&gt; &lt;member name="employee1" /&gt; &lt;/group&gt; &lt;/basicRegistry&gt; If &lt;basicRegistry&gt; settings are defined in server.xml, this is a finding.

Fix: F-53723r862979_fix

Delete basicRegistry settings and re-configure the server.xml file to use a centralized LDAP user store. SAMPLE: <featureManager> <feature>appSecurity-2.0</feature> <feature>ldapRegistry-3.0</feature> </featureManager> <ldapRegistry id="ldap" realm="SampleLdapRealm" host="${ldap.server.name}" port="${ldap.server.port}" ignoreCase="true" baseDN="${ldap.server.base.dn}" ldapType="${ldap.vendor.type}" searchTimeout="8m"> </ldapRegistry>

c
Multifactor authentication for network access to privileged accounts must be used.
IA-5 - High - CCI-000187 - V-250335 - SV-250335r1015469_rule
RMF Control
IA-5
Severity
H
CCI
CCI-000187
Version
IBMW-LS-000390
Vuln IDs
  • V-250335
Rule IDs
  • SV-250335r1015469_rule
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. When accessing the application server via a network connection, administrative access to the application server must be PKI Hardware Token enabled. The high level steps required for configuring Liberty Server to use certificate based authentication include the following: 1. Configure Web Application with client certificate authentication. 2. Configure Liberty SSL configuration with client authentication. 3. Configure Liberty LDAP Security Configuration with certificate filter. Satisfies: 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
Checks: C-53770r862981_chk

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. &lt;featureManager&gt; &lt;feature&gt;appSecurity-2.0&lt;/feature&gt; &lt;feature&gt;ldapRegistry-3.0&lt;/feature&gt; &lt;feature&gt;transportSecurity-1.0&lt;/feature&gt; &lt;/featureManager&gt; Verify the TLS connection used for managing the server is configured to use clientAuthentication. The following is used as an example. If the clientAuthentication setting for the TLS management application is not set to "true", this is a finding. EXAMPLE: &lt;!-- default SSL configuration is defaultSSLSettings --&gt; &lt;sslDefault sslRef="defaultSSLSettings" /&gt; &lt;ssl id="defaultSSLSettings" keyStoreRef="defaultKeyStore" sslProtocol="SSL_TLSv2" trustStoreRef="defaultTrustStore" clientAuthentication="true"/&gt; Access the web management interface via a web browser and verify TLS secured connectivity to the web based management application.

Fix: F-53724r862982_fix

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. The application’s web.xml file must be configured to use client certs. EXAMPLE: <login-config> <auth-method>CLIENT-CERT</auth-method> </login-config> The server.xml features must be configured to use transportSecurity and an ldap configuration. <featureManager> <feature>appSecurity-2.0</feature> <feature>ldapRegistry-3.0</feature> <feature>transportSecurity-1.0</feature> </featureManager> The 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. <!-- default SSL configuration is defaultSSLSettings --> <sslDefault sslRef="defaultSSLSettings" /> <ssl id="defaultSSLSettings" keyStoreRef="defaultKeyStore" sslProtocol="SSL_TLSv2" trustStoreRef="defaultTrustStore" clientAuthentication="true"/> <keyStore id="defaultKeyStore" location="key.jks" type="JKS" password="defaultPWD" /> <keyStore id="defaultTrustStore" location="key.jks" type="JKS" password="defaultPWD" /> Configure LDAP certificate filter settings according the certificates being used. <ldapRegistry id="ldap" realm="SampleLdapRealm" host="${ldap.server.name}" port="${ldap.server.port}" ignoreCase="true" baseDN="${ldap.server.base.dn}" ldapType="${ldap.vendor.type}" certificateMapMode="Certificate_Filter" or "Exact_DN" certificateFilter="${your certificate mapping}" searchTimeout="8m" sslEnabled="true"> </ldapRegistry>

c
The WebSphere Liberty Server must store only encrypted representations of user passwords.
IA-5 - High - CCI-000196 - V-250336 - SV-250336r1015470_rule
RMF Control
IA-5
Severity
H
CCI
CCI-000196
Version
IBMW-LS-000440
Vuln IDs
  • V-250336
Rule IDs
  • SV-250336r1015470_rule
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. The 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. It is imperative that administrators understand that the SecurityUtility tool must be run for each application password that is stored within the server.xml file. Satisfies: SRG-APP-000171-AS-000119, SRG-APP-000428-AS-000265, SRG-APP-000429-AS-000157
Checks: C-53771r795059_chk

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. If any passwords appear in plain text, or if any passwords start with {xor}, this is a finding.

Fix: F-53725r795060_fix

For additional information regarding the use of the SecurityUtility command, refer to IBM’s website: https://www.ibm.com/docs/en/was-liberty/base?topic=applications-securityutility-command Create a new xml file with file permissions of 660. File owner and group membership is the same as the WebSphere Liberty server user. Add the following line to the new xml file: <variable name="wlp.password.encryption.key" value="mysecret"/> In the above, "mysecret" is the passphrase selected to create a cryptographic hash that represents the password. Save the file to a secured location. Note the path and name, as it will be needed when updating server.xml. Edit the server.xml file and add the following line: <include location="/path/<xml file created>" /> For every unencrypted password in server.xml, run the following SecurityUtility command, which can be found in the Liberty Server install path: SecurityUtility encode --encoding=aes This will prompt the user to enter the plain-text password stored within the server.xml file. The SecurityUtility tool will generate an AES cryptographic hash of the password. Copy and replace the plain-text password with the hashed value. This must be done for every plain-text password in server.xml. Restart the server by entering: server stop <server name> server start <server name>

c
The WebSphere Liberty Server must use TLS-enabled LDAP.
IA-5 - High - CCI-000197 - V-250337 - SV-250337r961029_rule
RMF Control
IA-5
Severity
H
CCI
CCI-000197
Version
IBMW-LS-000450
Vuln IDs
  • V-250337
Rule IDs
  • SV-250337r961029_rule
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. Application 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.
Checks: C-53772r862984_chk

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. &lt;featureManager&gt; &lt;feature&gt;appSecurity-2.0&lt;/feature&gt; &lt;feature&gt;ssl-1.0&lt;/feature&gt; &lt;feature&gt;ldapRegistry-3.0&lt;/feature&gt; &lt;/featureManager&gt; &lt;ldapRegistry id="ldap" realm="SampleLdapRealm" host="${ldap.server.name}" port="${ldap.server.port}" ignoreCase="true" baseDN="${ldap.server.base.dn}" bindDN="${ldap.server.bind.dn}’ bindPassword="${ldap.server.bind.password}" sslEnabled="true" sslRef="LDAPTLSSettings" ldapType="${ldap.vendor.type}" searchTimeout="8m"&gt; &lt;/ldapRegistry&gt; &lt;sslDefault sslRef="LDAPTLSSettings" /&gt; &lt;ssl id="LDAPTLSSettings" keyStoreRef="LDAPKeyStore" trustStoreRef="LDAPTrustStore" sslProtocol="TLSv1.2"/&gt; &lt;keyStore id="LDAPKeyStore" location="${server.config.dir}/LdapSSLKeyStore.jks" type="JKS" password="{xor}CDo9Hgw=" /&gt; &lt;keyStore id="LDAPTrustStore" location="${server.config.dir}/LdapTLSTrustStore.jks" type="JKS" password="{xor}CDo9Hgw=" /&gt;

Fix: F-53726r862985_fix

To ensure the Liberty Server transmits only encrypted passwords, the ${server.config.dir}/server.xml must be configured as follows: <featureManager> <feature>appSecurity-2.0</feature> <feature>ssl-1.0</feature> <feature>ldapRegistry-3.0</feature> </featureManager> <ldapRegistry id="ldap" realm="SampleLdapRealm" host="${ldap.server.name}" port="${ldap.server.port}" ignoreCase="true" baseDN="${ldap.server.base.dn}" bindDN="${ldap.server.bind.dn}’ bindPassword="${ldap.server.bind.password}" sslEnabled="true" sslRef="LDAPTLSSettings" ldapType="${ldap.vendor.type}" searchTimeout="8m"> </ldapRegistry> <sslDefault sslRef="LDAPTLSSettings" /> <ssl id="LDAPTLSSettings" keyStoreRef="LDAPKeyStore" trustStoreRef="LDAPTrustStore" sslProtocol="TLSv1.2" /> <keyStore id="LDAPKeyStore" location="${server.config.dir}/LdapSSLKeyStore.jks" type="JKS" password="{xor}CDo9Hgw=" /> <keyStore id="LDAPTrustStore" location="${server.config.dir}/LdapTLSTrustStore.jks" type="JKS" password="{xor}CDo9Hgw=" />

b
The WebSphere Liberty Server must use DoD-issued/signed certificates.
IA-5 - Medium - CCI-000187 - V-250338 - SV-250338r961044_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000187
Version
IBMW-LS-000500
Vuln IDs
  • V-250338
Rule IDs
  • SV-250338r961044_rule
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. Satisfies: SRG-APP-000177-AS-000126, SRG-APP-000427-AS-000264, SRG-APP-000514-AS-000137
Checks: C-53773r850894_chk

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: &lt;sslDefault sslRef="DefaultTLSSettings" /&gt; Review the default ssl configuration to identify the default truststore. SAMPLE: &lt;ssl id="DefaultTLSSettings" keyStoreRef="defaultKeyStore" /&gt; &lt;keyStore id="LDAPTrustStore" location="${server.config.dir}/liberty.ks" type="JKS" password="xxxxxxx" /&gt; 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 DoD approved CA, this is a finding.

Fix: F-53727r795066_fix

Do not use self-signed certificates in a production environment. Only import certificates signed by an authorized DoD CA or authorized for DoD 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 DoD signed certificate.

c
The WebSphere Liberty Server must use FIPS 140-2 approved encryption modules when authenticating users and processes.
IA-7 - High - CCI-000803 - V-250339 - SV-250339r961050_rule
RMF Control
IA-7
Severity
H
CCI
CCI-000803
Version
IBMW-LS-000520
Vuln IDs
  • V-250339
Rule IDs
  • SV-250339r961050_rule
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 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-2 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. Satisfies: SRG-APP-000179-AS-000129, SRG-APP-000224-AS-000152, SRG-APP-000416-AS-000140, SRG-APP-000439-AS-000155, SRG-APP-000442-AS-000259, SRG-APP-000514-AS-000136
Checks: C-53774r795068_chk

Review the ${server.config.dir}/jvm.options file. Verify FIPS is in use. If the -Dcom.ibm.jsse2.usefipsprovider=true property is not set in the ${server.config.dir}/jvm.options file, this is a finding. Review the ${JAVA_HOME}/jre/lib/security/java.security file. If the ${JAVA_HOME}/jre/lib/security/java.security file does not contain the following settings, this is a finding. ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImpl ssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImpl Locate the list of cryptographic providers and replace it with the following list in the following order: security.provider.1=com.ibm.crypto.fips.provider.IBMJCEFIPS security.provider.2=com.ibm.jsse2.IBMJSSEProvider2 security.provider.3=com.ibm.crypto.provider.IBMJCE security.provider.4=com.ibm.security.jgss.IBMJGSSProvider security.provider.5=com.ibm.security.cert.IBMCertPath security.provider.6=com.ibm.security.sasl.IBMSASL security.provider.7=com.ibm.xml.crypto.IBMXMLCryptoProvider security.provider.8=com.ibm.xml.enc.IBMXMLEncProvider security.provider.9=org.apache.harmony.security.provider.PolicyProvider security.provider.10=com.ibm.security.jgss.mech.spnego.IBMSPNEGO

Fix: F-53728r795069_fix

Edit the ${server.config.dir}/jvm.options file. Add or modify the -Dcom.ibm.jsse2.usefipsprovider=true property to enable the JSSE2 provider to run in FIPS 140-2 mode. Edit ${JAVA_HOME}/jre/lib/security/java.security file to register additional cryptographic package provides. Update these two lines: #ssl.SocketFactory.provider= #ssl.ServerSocketFactory.provider= to ssl.SocketFactory.provider=com.ibm.jsse2.SSLSocketFactoryImpl ssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImpl Locate the list of cryptographic providers that are located after the line # List of providers and their preference orders and replace it with the following list: security.provider.1=com.ibm.crypto.fips.provider.IBMJCEFIPS security.provider.2=com.ibm.jsse2.IBMJSSEProvider2 security.provider.3=com.ibm.crypto.provider.IBMJCE security.provider.4=com.ibm.security.jgss.IBMJGSSProvider security.provider.5=com.ibm.security.cert.IBMCertPath security.provider.6=com.ibm.security.sasl.IBMSASL security.provider.7=com.ibm.xml.crypto.IBMXMLCryptoProvider security.provider.8=com.ibm.xml.enc.IBMXMLEncProvider security.provider.9=org.apache.harmony.security.provider.PolicyProvider security.provider.10=com.ibm.security.jgss.mech.spnego.IBMSPNEGO

b
HTTP session timeout must be configured.
IA-11 - Medium - CCI-002038 - V-250340 - SV-250340r1015471_rule
RMF Control
IA-11
Severity
M
CCI
CCI-002038
Version
IBMW-LS-000720
Vuln IDs
  • V-250340
Rule IDs
  • SV-250340r1015471_rule
An attacker can take advantage of user sessions that are left open, thus bypassing the user authentication process. To 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. Session 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. Conditions 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. Satisfies: SRG-APP-000295-AS-000263, SRG-APP-000389-AS-000253
Checks: C-53775r795071_chk

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. If the ${server.config.dir}/server.xml does not define the timeout setting as 10 minutes, this is a finding. &lt;httpSession invalidationTimeout="10m"/&gt;

Fix: F-53729r795072_fix

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: <httpSession invalidationTimeout="10m"/> By default, httpSession invalidationTimeout is set to 30m.

c
Application security must be enabled on the WebSphere Liberty Server.
AC-17 - High - CCI-000068 - V-250341 - SV-250341r1015252_rule
RMF Control
AC-17
Severity
H
CCI
CCI-000068
Version
IBMW-LS-000770
Vuln IDs
  • V-250341
Rule IDs
  • SV-250341r1015252_rule
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. Application 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. Satisfies: SRG-APP-000315-AS-000094, SRG-APP-000014-AS-000009
Checks: C-53776r1015251_chk

As a user with local file access to ${server.config.dir}/server.xml file, verify application security is enabled. If the appSecurity-2.0 feature is not defined within server.xml, this is a finding. &lt;featureManager&gt; &lt;feature&gt;appSecurity-2.0&lt;/feature&gt; &lt;/featureManager&gt;

Fix: F-53730r862988_fix

Configure the ${server.config.dir}/server.xml file and add the appSecurity-2.0 feature. <featureManager> <feature>appSecurity-2.0</feature> </featureManager> Review ${server.config.dir}/logs/messages.log Validate log entry that indicates "Security service is ready".

b
Users in a reader-role must be authorized.
AC-6 - Medium - CCI-002235 - V-250342 - SV-250342r961353_rule
RMF Control
AC-6
Severity
M
CCI
CCI-002235
Version
IBMW-LS-000790
Vuln IDs
  • V-250342
Rule IDs
  • SV-250342r961353_rule
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. Users granted reader role access must be authorized.
Checks: C-53777r862990_chk

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. grep -i reader-role ${server.config.dir}/server.xml If the reader-role has been created, users in that role must be documented and approved. If users in the reader-role are not approved, this is a finding. EXAMPLE: &lt;featureManager&gt;&lt;feature&gt;appSecurity-2.0&lt;/feature&gt;&lt;/featureManager&gt; &lt;reader-role&gt; &lt;group&gt;group&lt;/group&gt; &lt;group-access-id&gt;group:realmName/groupUniqueId&lt;/group-access-id&gt; &lt;user&gt;user&lt;/user&gt; &lt;user-access-id&gt;user:realmName/userUniqueId&lt;/user-access-id&gt; &lt;/reader-role&gt;

Fix: F-53731r862991_fix

Edit the ${server.config.dir}/server.xml file. If unauthorized users have been added to the reader-role, remove those users. Otherwise, document the users who are granted the reader-role access. To 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. EXAMPLE: <featureManager> <feature>appSecurity-2.0</feature> </featureManager> <reader-role> <group>group</group><group-access-id> group:realmName/groupUniqueId</group-access-id><user>user</user><user-access-id>user:realmName/userUniqueId</user-access-id> </reader-role> <ldapRegistry id="ldap" realm="SampleLdapRealm" host="${ldap.server.name}" port="${ldap.server.port}" ignoreCase="true" baseDN="${ldap.server.base.dn}" ldapType="${ldap.vendor.type}" searchTimeout="8m"> </ldapRegistry>

b
The WebSphere Liberty Server must allocate JVM log record storage capacity in accordance with organization-defined log record storage requirements.
AU-4 - Medium - CCI-001849 - V-250343 - SV-250343r961392_rule
RMF Control
AU-4
Severity
M
CCI
CCI-001849
Version
IBMW-LS-000830
Vuln IDs
  • V-250343
Rule IDs
  • SV-250343r961392_rule
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. By default, Liberty automatically logs the console.log, messages.log, and trace.log but these default settings must be validated.
Checks: C-53778r795080_chk

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. Review 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. EXAMPLE: &lt;logging traceSpecification="*=info=enabled:my.package.*=all" maxFileSize="40" maxFiles="20"/&gt;

Fix: F-53732r850900_fix

Edit the bootstrap.properties file and configure the com.ibm.ws.logging.console.log.level=ON. Edit the ${server.config.dir}/server.xml file. Configure <logging traceSpecification> in accordance with local policy and system storage limits. EXAMPLE: <logging traceSpecification="*=info=enabled:my.package.*=all" maxFileSize="40" maxFiles="20"/>, where 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.

b
The server.xml file must be protected from unauthorized modification.
CM-5 - Medium - CCI-001813 - V-250344 - SV-250344r961461_rule
RMF Control
CM-5
Severity
M
CCI
CCI-001813
Version
IBMW-LS-000910
Vuln IDs
  • V-250344
Rule IDs
  • SV-250344r961461_rule
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. Protect the server.xml file from unauthorized modification by applying file permission restrictions.
Checks: C-53779r795083_chk

As a privileged user with local file access to ${server.config.dir}/server.xml, verify the server.xml file permissions are set to 660. If the server.xml file permissions are not set to 660, this is a finding.

Fix: F-53733r795084_fix

As a privileged user with local file access to ${server.config.dir}/server.xml. Use the chmod command to configure the correct file permissions of 660. chmod 660 server.xml

b
The WebSphere Liberty Server must prohibit the use of cached authenticators after an organization-defined time period.
IA-5 - Medium - CCI-002007 - V-250345 - SV-250345r961521_rule
RMF Control
IA-5
Severity
M
CCI
CCI-002007
Version
IBMW-LS-000970
Vuln IDs
  • V-250345
Rule IDs
  • SV-250345r961521_rule
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. Smaller authentication cache timeout values can affect performance. When this value is smaller, the Liberty Server accesses the user registry or repository more frequently. Larger 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. If cached authentication information is out of date, the validity of the authentication information may be questionable.
Checks: C-53780r795086_chk

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. As a privileged user with access to server.xml, review the file and verify the authCache timeout parameter is configured for 10 minutes. grep -i authcache server.xml EXAMPLE: &lt;authCache initialSize="100" maxSize="50000" timeout="10m"/&gt; If 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.

Fix: F-53734r862993_fix

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. EXAMPLE: <featureManager> <feature>appSecurity-2.0</feature> </featureManager> <authCache initialSize="100" maxSize="50000" timeout="10m"/>

b
The WebSphere Liberty Server LTPA keys password must be changed.
SC-28 - Medium - CCI-002475 - V-250346 - SV-250346r961599_rule
RMF Control
SC-28
Severity
M
CCI
CCI-002475
Version
IBMW-LS-001050
Vuln IDs
  • V-250346
Rule IDs
  • SV-250346r961599_rule
The default location of the automatically generated Lightweight Third Party Authentication (LTPA) keys file is ${server.output.dir}/resources/security/ltpa.keys. The 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. When the LTPA keys are exchanged between servers, this password must match across the servers for Single Sign On (SSO) to work. Automated 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.
Checks: C-53781r850904_chk

If LTPA is not used, this requirement is not a finding. As 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. EXAMPLE: grep -i "&lt;ltpa" server.xml &lt;ltpa keysFileName="LTPA.keys" keysPassword="myLTPAkeysPassword" expiration="120" monitorInterval="5s" /&gt; If the LTPA setting exists and the password is set to "WebAS", this is a finding.

Fix: F-53735r795090_fix

To update key password and force a regeneration of keys follow these steps. To obtain encoded values, use the Liberty "securityUtility encode" command. 1. Shut down the server. 2. Configure the <ltpa> 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. <ltpa keysFileName="yourLTPAKeysFileName.keys" keysPassword="yourkeysPassword" expiration="120" /> 3. Delete the existing ${wlp.server.dir}/resources/security/ltpa.keys file. 4. Sync changes with all servers in the cell. 5. Start the servers.

b
The WebSphere Liberty Server must remove all export ciphers to protect the confidentiality and integrity of transmitted information.
SC-8 - Medium - CCI-002418 - V-250347 - SV-250347r961632_rule
RMF Control
SC-8
Severity
M
CCI
CCI-002418
Version
IBMW-LS-001110
Vuln IDs
  • V-250347
Rule IDs
  • SV-250347r961632_rule
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.
Checks: C-53782r795092_chk

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. &lt;ssl id="myDefaultSSLConfig" keyStoreRef="defaultKeyStore" trustStoreRef="defaultTrustStore" clientAuthentication="true" sslProtocol="TLS" enabledCiphers="SSL_xxx_yyy_zzz"/&gt;

Fix: F-53736r795093_fix

Review the ${server.config.dir}/server.xml file and if needed, modify the "enabledCiphers" setting for each affected SSL configuration. <ssl id="myDefaultSSLConfig" keyStoreRef="defaultKeyStore" trustStoreRef="defaultTrustStore" clientAuthentication="true" sslProtocol="TLS" enabledCiphers="SSL_xxx_yyy_zzz"/> where xxx, yyy, and zzz do not contain "EXPORT".

b
The WebSphere Liberty Server must be configured to use HTTPS only.
SC-8 - Medium - CCI-002421 - V-250348 - SV-250348r961635_rule
RMF Control
SC-8
Severity
M
CCI
CCI-002421
Version
IBMW-LS-001120
Vuln IDs
  • V-250348
Rule IDs
  • SV-250348r961635_rule
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.
Checks: C-53783r862995_chk

Review the ${server.config.dir}/server.xml file and check the ssl-1.0 feature and httpEndpoint settings. If the ssl-1.0 feature is not defined, this is a finding. If the httpEndpoint settings do not include ssloptions, this is a finding. &lt;featureManager&gt; &lt;feature&gt;servlet-3.0&lt;/feature&gt; &lt;feature&gt;ssl-1.0&lt;/feature&gt; &lt;feature&gt;appSecurity-2.0&lt;/feature&gt; &lt;/featureManager&gt; &lt;httpEndpoint id="defaultHttpEndpoint" host="localhost" httpPort="${bvt.prop.HTTP_default}" httpsPort="${bvt.prop.HTTP_default.secure}" &gt; &lt;tcpOptions soReuseAddr="true" /&gt; &lt;sslOptions sslRef="testSSLConfig" /&gt; &lt;/httpEndpoint&gt;

Fix: F-53737r862996_fix

Modify the server.xml file. Enable the ssl-1.0 feature and configure the httpEndpoint settings. The keystores and truststores must also be configured. <featureManager> <feature>servlet-3.0</feature> <feature>ssl-1.0</feature> <feature>appSecurity-2.0</feature> </featureManager> <httpEndpoint id="defaultHttpEndpoint" host="localhost" httpPort="${bvt.prop.HTTP_default}" httpsPort="${bvt.prop.HTTP_default.secure}" > <tcpOptions soReuseAddr="true" /> <sslOptions sslRef="testSSLConfig" /> </httpEndpoint> <ssl id="defaultSSLConfig" keyStoreRef="defaultKeyStore" trustStoreRef="defaultKeyStore" serverKeyAlias="default" /> <ssl id="testSSLConfig" keyStoreRef="defaultKeyStore" trustStoreRef="alternateTrustStore" serverKeyAlias="alternateCert" enabledCiphers="AES256-SHA AES128-SHA" /> <!-- inbound (HTTPS) keystore --> <keyStore id="defaultKeyStore" password="Liberty" location="${server.config.dir}/resources/security/sslOptions.jks" /> <keyStore id="defaultTrustStore" password="Liberty" location="${server.config.dir}/resources/security/trust.jks" /> <keyStore id="alternateTrustStore" password="Liberty" location="${server.config.dir}/resources/security/optionsTrust.jks" /> <application type="war" id="basicauth" name="basicauth" location="${server.config.dir}/apps/basicauth.war" />

b
The WebSphere Liberty Server must install security-relevant software updates within the time period directed by an authoritative source.
SI-2 - Medium - CCI-002605 - V-250349 - SV-250349r961683_rule
RMF Control
SI-2
Severity
M
CCI
CCI-002605
Version
IBMW-LS-001170
Vuln IDs
  • V-250349
Rule IDs
  • SV-250349r961683_rule
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
Checks: C-53784r795098_chk

Use the "productInfo(.bat/.sh) version" command to determine the WebSphere version. Review the patch level and fix pack. Review 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. If the most recent patches/fix packs have not been applied, this is a finding.

Fix: F-53738r795099_fix

Obtain WebSphere Liberty product security and patch support at http://www-01.ibm.com/support/docview.wss?uid=swg27009661. Run the productInfo validate command to validate the MD5 checksum file for server installation and each feature. If 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: productInfo validate --output=/tmp/validate.txt

b
The WebSphere Liberty Server must generate log records for authentication and authorization events.
AU-12 - Medium - CCI-000172 - V-250350 - SV-250350r961812_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
IBMW-LS-001190
Vuln IDs
  • V-250350
Rule IDs
  • SV-250350r961812_rule
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. Satisfies: 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
Checks: C-53785r795101_chk

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. If the audit1.0 feature is not enabled, this is a finding. If the SECURITY_AUTHN and SECURITY_AUTHZ event handlers are not configured, this is a finding. &lt;featureManager&gt; &lt;feature&gt;audit-1.0&lt;/feature&gt; &lt;/featureManager&gt; &lt;auditFileHandler&gt; &lt;events name="AllAuthn" eventName="SECURITY_AUTHN" /&gt; &lt;events name="AllAuthz" eventName="SECURITY_AUTHZ" /&gt; &lt;/auditFileHandler&gt;

Fix: F-53739r795102_fix

Modify the ${server.config.dir}/server.xml file and configure the audit-1.0 feature. <featureManager> <feature>audit-1.0</feature> </featureManager> Configure the auditFileHandler setting to record SECURITY_AUTHN and SECURITY_AUTHZ events. <auditFileHandler> <events name="AllAuthn" eventName="SECURITY_AUTHN"/> <events name="AllAuthz" eventName="SECURITY_AUTHZ" /> </auditFileHandler> Review audit logs located under the ${server.config.dir}/logs directory and ensure AUTHN and AUTHZ events are logged.