Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
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.
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" />
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: <feature>appSecurity-2.0</feature> 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 "<ssl id=" server.xml SAMPLE RESULT: <ssl id="TLSSettings" keyStoreRef="TLSKeyStore" trustStoreRef="TLSTrustStore" sslProtocol="TLSv1.2"/> 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.
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" />
As a user with local file access to ${server.config.dir}/server.xml, verify appSecurity feature is enabled. <featureManager><feature>appSecurity-2.0</feature></featureManager> Verify both web application LTPA and http session cookies are configured for httpOnly. <webAppSecurity ssoCookieName="LtpaToken2" ssoRequiresSSL="true" httpOnlyCookies="true" logoutOnHttpSessionExpire="true"/> <httpSession cookieName="JSESSIONID" cookieSecure="true" cookieHttpOnly="true" cookiePath="/"/> If the appSecurity feature is not enabled or if the LPTA or Session cookie settings are not set for httpOnly, this is a finding.
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="/"/>
Review the ${server.config.dir}/server.xml file and ensure audit-1.0 and appSecurity-2.0 are defined within the <featureManager> setting in the server.xml file. If audit-1.0 and appSecurity-2.0 are not defined within the <featureManager> setting in the server.xml file, this is a finding. EXAMPLE: <featureManager> <feature>audit-1.0</feature> <feature>appSecurity-3.0</feature> </featureManager>
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>
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: <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"/>
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"/>
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: <featureManager> <feature>logstashCollector-1.0</feature> </featureManager> <logstashCollector source="message,accessLog,audit" hostName="<ip address of logstash server>" port="<port of logstash server>" sslRef="DefaultTLSSettings" </logstashCollector> If "logstashCollector" is not a configured feature and the logstashCollector "source" setting does not contain "message,accessLog,audit", this is a finding.
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>
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.
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)
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.
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
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. <featureManager> <feature>appSecurity-2.0</feature> <feature>audit-1.0</feature> <feature>ssl-1.0</feature> </featureManager> 2. Verify a keystore is configured. The following is an example: <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. Verify auditFileHandler encryption is enabled. Signing is optional. <auditFileHandler encrypt="true" encryptAlias="auditencryption" encryptKeyStoreRef="auditEncKeyStore" sign="true" signingAlias="auditsigning2" signingKeyStoreRef="auditSignKeyStore"> </auditFileHandler> If the features and keystore are not configured, and encryption is not enabled, this is a finding.
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>
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.
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
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"> 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.
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.
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. <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>
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>
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: <basicRegistry id="basic" realm="BasicRealm"> <user name="employee0" password="emp0pwd" /> <user name="employee1" password="emp1pwd" /> <user name="manager0" password="mgr0pwd" /> <group name="employeeGroup"> <member name="employee0" /> <member name="employee1" /> </group> </basicRegistry> If <basicRegistry> settings are defined in server.xml, this is a finding.
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>
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. <featureManager> <feature>appSecurity-2.0</feature> <feature>ldapRegistry-3.0</feature> <feature>transportSecurity-1.0</feature> </featureManager> 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: <!-- default SSL configuration is defaultSSLSettings --> <sslDefault sslRef="defaultSSLSettings" /> <ssl id="defaultSSLSettings" keyStoreRef="defaultKeyStore" sslProtocol="SSL_TLSv2" trustStoreRef="defaultTrustStore" clientAuthentication="true"/> Access the web management interface via a web browser and verify TLS secured connectivity to the web based management application.
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>
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.
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>
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. <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=" />
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=" />
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: <sslDefault sslRef="DefaultTLSSettings" /> Review the default ssl configuration to identify the default truststore. SAMPLE: <ssl id="DefaultTLSSettings" keyStoreRef="defaultKeyStore" /> <keyStore id="LDAPTrustStore" location="${server.config.dir}/liberty.ks" type="JKS" password="xxxxxxx" /> Use the java keytool or ikeyman utilities to open and examine the certificates stored in the truststore. If the certificates are self signed or not signed by a DoD approved CA, this is a finding.
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.
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
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
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. <httpSession invalidationTimeout="10m"/>
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.
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. <featureManager> <feature>appSecurity-2.0</feature> </featureManager>
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".
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: <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>
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>
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: <logging traceSpecification="*=info=enabled:my.package.*=all" maxFileSize="40" maxFiles="20"/>
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.
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.
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
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: <authCache initialSize="100" maxSize="50000" timeout="10m"/> 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.
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"/>
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 "<ltpa" server.xml <ltpa keysFileName="LTPA.keys" keysPassword="myLTPAkeysPassword" expiration="120" monitorInterval="5s" /> If the LTPA setting exists and the password is set to "WebAS", this is a finding.
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.
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. <ssl id="myDefaultSSLConfig" keyStoreRef="defaultKeyStore" trustStoreRef="defaultTrustStore" clientAuthentication="true" sslProtocol="TLS" enabledCiphers="SSL_xxx_yyy_zzz"/>
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".
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. <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>
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" />
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.
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
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. <featureManager> <feature>audit-1.0</feature> </featureManager> <auditFileHandler> <events name="AllAuthn" eventName="SECURITY_AUTHN" /> <events name="AllAuthz" eventName="SECURITY_AUTHZ" /> </auditFileHandler>
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.