None Computing title IBM WebSphere Traditional V9.x Security Technical Implementation Guide version 2 releaseinfo Release: 1 Vuln_Num V-255818 Rule_ID SV-255818r960735_rule Severity medium Rule_Title The WebSphere Application Server maximum in-memory session count must be set according to application requirements. Vuln_Discuss Application management includes the ability to control the number of sessions that utilize an application by all accounts and/or account types. Limiting the number of allowed sessions is helpful in limiting risks related to Denial of Service attacks. Application servers host and expose business logic and application processes. The application server must possess the capability to limit the maximum number of concurrent sessions in a manner that affects the entire application server or on an individual application basis. Although there is some latitude concerning the settings themselves, the settings should follow 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. Check_Content Review system documentation. Identify the application session requirements. In the administrative console page, click Servers >> Server Types >> WebSphere application servers >> [server_name] >> Session management. Ensure the Maximum in-memory session count field is set to the number of sessions allowable. If not set according to application requirements, this is a finding. Fix_Text In the administrative console page, click Servers >> Server Types >> WebSphere application servers >> [server_name] >> Session management. Edit the Maximum in-memory session count field to be the number of sessions allowable. Not_Reviewed Vuln_Num V-255819 Rule_ID SV-255819r1043182_rule Severity medium Rule_Title The WebSphere Application Server admin console session timeout must be configured. Vuln_Discuss 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. Check_Content Review System Security Plan and system configuration documentation. Access the Deployment Manager (DMGR) operating system. Locate the deployment.xml file. The default file location where deployment.xml is installed are provided below. UNIX: /opt/IBM/WebSphere/Profiles/DefaultDmgr01/config/cells/<CELL NAME>/applications/isclite.ear/deployments/isclite/ Windows: C:\Program Files\IBM\WebSphere\Profiles\DefaultDmgr01\config\cells\<CELL NAME>\applications\isclite.ear\deployments\isclite\ Search the deployment.xml file for the string, "invalidationtimeout=" UNIX: grep -i invalidationtimeout $PATH/deployment.xml Windows: findstr -I invalidationtimeout= $PATH\deployment.xml The value is expressed in minutes and the default value is set to "30 minutes". If "invalidationtimeout" is not set to "10 minutes", this is a finding. Fix_Text Locate the deployment.xml file. The default file locations where deployment.xml is installed are provided below. UNIX: /opt/IBM/WebSphere/Profiles/DefaultDmgr01/config/cells/<CELL NAME>/applications/isclite.ear/deployments/isclite/ Windows: C:\Program Files\IBM\WebSphere\Profiles\DefaultDmgr01\config\cells\<CELL NAME>\applications\isclite.ear\deployments\isclite\ Make a backup copy of the deployment.xml file. Edit the deployment.xml file. Modify the "invalidationtimeout=" value and set to "10". Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255820 Rule_ID SV-255820r960765_rule Severity medium Rule_Title The WebSphere Application Server security auditing must be enabled. Vuln_Discuss Security auditing will not be performed unless the audit security subsystem has been enabled. Global security must be enabled for the security audit subsystem to function, as no security auditing occurs if global security is not also enabled. Enable global security before enabling security auditing. Satisfies: SRG-APP-000016-AS-000013, SRG-APP-000343-AS-000030, SRG-APP-000080-AS-000045, SRG-APP-000092-AS-000053, SRG-APP-000266-AS-000168, SRG-APP-000267-AS-000170 Check_Content In the administrative console, navigate to Security >> Security auditing. If "Enable security auditing" is not enabled, this is a finding. Fix_Text In the administrative console, navigate to Security >> Security auditing to enable. Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255821 Rule_ID SV-255821r960765_rule Severity medium Rule_Title The WebSphere Application Server groups in the user registry mapped to WebSphere auditor roles must be configured in accordance with the security plan. Vuln_Discuss Logging must be utilized in order to track system activity, assist in diagnosing system issues, and provide evidence needed for forensic investigations post security incident. Remote access by administrators requires that the admin activity be logged. Application servers provide a web and command line-based remote management capability for managing the application server. Application servers must ensure that all actions related to administrative functionality such as application server configuration are logged. Satisfies: SRG-APP-000016-AS-000013, SRG-APP-000343-AS-000030 Check_Content Review System Security Plan documentation. Identify groups and roles. In the administrative console, navigate to Users and Groups >> Administrative Group Roles. Check the roles for each group and compare to System Security Plan. If any group is not authorized by the ISSO/ISSM to be in an auditor role, this is a finding. Fix_Text Document all groups in an Auditor role in the security plan. In the administrative console, navigate to Users and Groups >> Administrative group roles. If an unauthorized group is in the auditor role, remove the auditor role from the group. Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255822 Rule_ID SV-255822r960765_rule Severity medium Rule_Title The WebSphere Application Server users in the WebSphere auditor role must be configured in accordance with the System Security Plan. Vuln_Discuss Logging must be utilized in order to track system activity, assist in diagnosing system issues, and provide evidence needed for forensic investigations post security incident. Remote access by administrators requires that the admin activity be logged. Application servers provide a web and command line-based remote management capability for managing the application server. Application servers must ensure that all actions related to administrative functionality such as application server configuration are logged. Satisfies: SRG-APP-000016-AS-000013, SRG-APP-000343-AS-000030, SRG-APP-000090-AS-000051 Check_Content Review System Security Plan documentation. Identify users and roles. In the administrative console, navigate to Users and Groups >> Administrative User Roles. Check the roles for each user. If any user is not authorized by the ISSO/ISSM to be in the role of an auditor, this is a finding. Fix_Text In the administrative console, navigate to Users and Groups >> Administrative User roles. If an unauthorized user is in the auditor role, remove the user from the auditor role. Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255823 Rule_ID SV-255823r960765_rule Severity medium Rule_Title The WebSphere Application Server audit event type filters must be configured. Vuln_Discuss Logging must be utilized in order to track system activity, assist in diagnosing system issues, and provide evidence needed for forensic investigations post security incident. Remote access by administrators requires that the admin activity be logged. Application servers provide a web and command line-based remote management capability for managing the application server. Application servers must ensure that all actions related to administrative functionality such as application server configuration are logged. Satisfies: SRG-APP-000016-AS-000013, SRG-APP-000343-AS-000030, SRG-APP-000089-AS-000050, SRG-APP-000495-AS-000220, SRG-APP-000499-AS-000224, SRG-APP-000503-AS-000228, SRG-APP-000504-AS-000229, SRG-APP-000505-AS-000230, SRG-APP-000506-AS-000231, SRG-APP-000093-AS-000054, SRG-APP-000095-AS-000056, 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-000381-AS-000089, SRG-APP-000080-AS-000045 Check_Content In the administrative console, navigate to Security >> Security auditing >> Event type Filters. Verify the following events and outcomes are enabled in the "Events and Outcomes" box. Also note the name of the filter associated with these events. This name will be referenced in STIG ID WBSP-AS-000110. AUTHN: SUCCESS,INFO,WARNING,ERROR,DENIED,REDIRECT AUTHZ: SUCCESS,INFO,WARNING,ERROR,DENIED,REDIRECT AUTHN_TERMINATE: SUCCESS,INFO,WARNING,ERROR,DENIED,REDIRECT REPOSITORY_SAVE: SUCCESS,INFO,WARNING,ERROR,DENIED,REDIRECT If these audit filters are not configured in "Events and Outcomes", this is a finding. Fix_Text In the administrative console, navigate to Security >> Security auditing >> Event type Filters. Click the "New" button to create a new filter; give it a unique name. Select SECURITY_AUTHN, SECURITY_AUTHZ, SECURITY_AUTHN_TERMINATE, and ADMIN_REPOSITORY_SAVE from "Selectable events". Add them to the "Enabled events" box by clicking on the right arrow. Select INFO, ERROR, SUCCESS, DENIED, REDIRECT, and WARNING from the "Selectable event outcomes" box. Click the right arrow to fill in "Enabled events outcomes" box. Click "OK". Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255824 Rule_ID SV-255824r960765_rule Severity medium Rule_Title The WebSphere Application Server audit service provider must be enabled. Vuln_Discuss Logging must be utilized in order to track system activity, assist in diagnosing system issues, and provide evidence needed for forensic investigations post security incident. Remote access by administrators requires that the admin activity be logged. Application servers provide a web and command line-based remote management capability for managing the application server. Application servers must ensure that all actions related to administrative functionality such as application server configuration are logged. Satisfies: SRG-APP-000016-AS-000013, SRG-APP-000343-AS-000030 Check_Content In the administrative console, navigate to Security >> Security auditing >> Audit Service Provider [provider name]. Under "Enabled filters", determine if the filter name from select the name of the filter that was recorded from STIG ID WBSP-AS-000100. If the filter that was identified in STIG ID WBSP-AS-000100 is not enabled, this is a finding. Fix_Text In the administrative console, navigate to Security >> Security auditing >> Event type Filters. Identify and record the event type filter that contains the required "Events and Outcomes". In the administrative console, click on Security >> Security auditing >> Audit Service Provider [provider name]. Under "Selectable filters", select the filter that was previously identified and recorded. Click the right arrow to add it to the list. Click "OK". Click "Save" to save the changes. Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255825 Rule_ID SV-255825r960765_rule Severity medium Rule_Title The WebSphere Application Server automatic repository checkpoints must be enabled to track configuration changes. Vuln_Discuss Without enabling repository checkpoints, you will not be able to determine the history of changes to WebSphere configuration files, and who made those changes. Check_Content Review System Security Plan documentation. Identify the required "Automatic CheckPoint Depth" setting that has been defined. From administrative console, click System administration >> Extended repository service. If "Enable automatic repository checkpoints" is not selected or if the "automatic checkpoint depth" is less than the number of saves defined in the System Security Plan, this is a finding. Fix_Text From administrative console click System administration >> Extended repository service >> Enable automatic repository checkpoints. Enter a "checkpoint depth value" according to the security plan. Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255826 Rule_ID SV-255826r961278_rule Severity high Rule_Title The WebSphere Application Server administrative security must be enabled. Vuln_Discuss In previous releases of WebSphere® Application Server, when a user enabled global security, both administrative and application security were enabled. The previous notion of global security is split into administrative security and application security, each of which you can enable separately. As a result of this split, WebSphere Application Server clients must know whether application security is disabled at the target server. Administrative security is enabled, by default. Application security is disabled, by default. Before you can enable application security, you must verify that administrative security is enabled. Application security is in effect only when administrative security is enabled. Check_Content From the administrative console, click Security >> Global Security. If "Enable administrative security" is not selected, this is a finding. Fix_Text From the administrative console, click Security >> Global Security. Click "Enable administrative security". Click "Save". Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255827 Rule_ID SV-255827r961863_rule Severity high Rule_Title The WebSphere Application Server bus security must be enabled. Vuln_Discuss A service integration bus is a group of one or more application servers or server clusters in a WebSphere® Application Server cell that cooperate to provide asynchronous messaging services. The application servers or server clusters in a bus are known as bus members. When a bus is created with bus security enabled, the following conditions apply: The bus requires client authentication. The bus enforces authorization policy. The bus requires use of SSL transport chains. Check_Content Review System Security Plan documentation. Interview the system administrator. Identify the service integration buses configured on the WAS. If there are no service integration buses, this requirement is NA. From the administration console, navigate to Security >> Bus Security. For each service integration bus, if security is not enabled, this is a finding. Fix_Text From the administration console, navigate to Security >> Bus Security. For each service integration bus where security is not enabled, click on "Disabled". Click the check box to "Enable bus security". Configure the transport settings and authorization policies according to application security access requirements specified in the security plan. Not_Reviewed Vuln_Num V-255828 Rule_ID SV-255828r961278_rule Severity medium Rule_Title The WebSphere Application Server users in a local user registry group must be authorized for that group. Vuln_Discuss Application servers provide remote access capability and must be able to enforce remote access policy requirements or work in conjunction with enterprise tools designed to enforce policy requirements. Automated monitoring and control of remote access sessions allows organizations to detect cyber attacks and also ensure ongoing compliance with remote access policies by logging connection activities of remote users. Examples of policy requirements include, but are not limited to, authorizing remote access to the information system, limiting access based on authentication credentials, and monitoring for unauthorized access. Satisfies: SRG-APP-000315-AS-000094, SRG-APP-000380-AS-000088, SRG-APP-000133-AS-000092, SRG-APP-000033-AS-000024, SRG-APP-000153-AS-000104 Check_Content If the systems user registry is managed by LDAP, this requirement is NA. Review the System Security Plan documentation. Interview the system administrator. Obtain a list of authorized users. In the administrative console, navigate to Users and Groups >> Manage Groups. Select each group. Select the "Members" tab. Validate the members of the group are authorized. If users in the group are not authorized by the ISSO/ISSM, this is a finding. Fix_Text From administrative console, navigate to Users and Groups >> Administrative group roles. Note: names of the groups and the roles assigned to each group. Navigate back to User and Groups >> Manage Groups. Click on every group. For each group, click on users. If there is any user who does not belong to the group based on the roles assigned to the group, click on the checkbox next to the user. Click "Remove". Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255829 Rule_ID SV-255829r960759_rule Severity medium Rule_Title The WebSphere Application Server Quality of Protection (QoP) must be set to use TLSv1.2 or higher. Vuln_Discuss Quality of Protection specifies the security level, ciphers, and mutual authentication settings for the Secure Socket Layer (SSL/TLS) configuration. Check_Content From the administrative console, navigate to Security >> SSL certificate and key management. Click "SSL configurations". Click on each SSL configuration to review. Under "Additional Properties", click "Quality of protection (QoP)" settings. If the "Protocol" field does not show "TLSv1.2 or greater", this is a finding. Fix_Text From the administrative console, navigate to Security >> SSL certificate and key management. Click "SSL configurations". Click on each SSL configuration. Under "Additional Properties", click "Quality of protection (QoP)" settings. At the "Protocol" pull-down menu, select "TLSv1.2 or greater". Click "OK". Click "Save". Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255830 Rule_ID SV-255830r960759_rule Severity high Rule_Title The WebSphere Application Server global application security must be enabled. Vuln_Discuss Application security enables security for the applications in your environment. This setting provides application isolation and meets security requirements such as using SSL for authenticating application users. In previous releases of WebSphere® Application Server, when a user enabled global security, both administrative and application security were enabled. The previous notion of global security is split into administrative security and application security, each of which you can enable separately. As a result of this split, WebSphere Application Server clients must know whether application security is disabled at the target server. Administrative security is enabled, by default. Application security is disabled, by default. Before you can enable application security, you must verify that administrative security is enabled. Application security is in effect only when administrative security is enabled. Satisfies: SRG-APP-000014-AS-000009, SRG-APP-000172-AS-000120 Check_Content From the administrative console, navigate to Security >> Global Security. If "Enable administrative security" and "Enable application security" are not selected, this is a finding. Fix_Text From the administrative console, navigate to Security >> Global Security. Click on "Enable administrative security". Click on "Enable application security". Click "OK". Click "Save". Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255831 Rule_ID SV-255831r960759_rule Severity high Rule_Title The WebSphere Application Server Single Sign On (SSO) must have SSL enabled for Web and SIP Security. Vuln_Discuss Remote management access is accomplished by leveraging common communication protocols and establishing a remote connection to the application server via a network for the purposes of managing the application server. If cryptography is not used, then the session data traversing the remote connection could be intercepted and compromised. Types of management interfaces utilized by an application server include web-based HTTPS interfaces as well as command line-based management interfaces. Satisfies: SRG-APP-000014-AS-000009, SRG-APP-000172-AS-000120, SRG-APP-000158-AS-000108 Check_Content From the administrative console, navigate to Security >> Global Security. Expand "Web and SIP security". Click on "Single sign-on (SSO)". If "requires SSL" is not selected, this is a finding. Fix_Text From the administrative console, navigate to Security >> Global Security. Expand "Web and SIP security". Click on "Single sign-on (SSO)". Select "Requires SSL". Click "OK". Click "Save". Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255832 Rule_ID SV-255832r960762_rule Severity medium Rule_Title The WebSphere Application Server security cookies must be set to HTTPOnly. Vuln_Discuss Web applications use cookies to track users across requests. These cookies, while typically not sensitive in themselves, connect you to your existing state on the back end system. If an intruder were to capture one of your cookies, they could potentially use the cookie to act as you. Important Web traffic should be encrypted using SSL. This includes important cookies. In the case of WebSphere Application Server, the most important cookie is the LTPA cookie, and therefore it should be configured to be sent only over SSL. Check_Content From the administrative console, navigate to Security >> Global Security. Expand "Web and SIP security". Click on "Single sign-on (SSO)". If "Set security cookies to HTTPOnly" is not selected, this is a finding. Fix_Text From the administrative console, navigate to Security >> Global Security. Expand "Web and SIP security". Select "Set security cookies to HTTPOnly". Click "OK". Click "Save". Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255833 Rule_ID SV-255833r1137578_rule Severity high Rule_Title The WebSphere Application Server Java 2 security must be enabled. Vuln_Discuss Java 2 security provides a policy-based fine grained access control mechanism that increases overall system integrity by checking for permissions before allowing access to certain protected system resources. Java 2 Security is independent on J2EE role-based authorization. Java 2 Security guards access to system resources such as file input and output, sockets, and properties, whereas J2EE security guards access to Web resources such as servlets and JSP files. Administrators should understand the possible consequences of enabling Java 2 Security if applications are not prepared for Java 2 Security. Java 2 Security places some new requirements on application developers and administrators. Admins need to make sure that all the applications are granted the required permissions; otherwise, applications may fail to run. By default, applications are granted the permissions recommended in the J2EE 1.3 Specification. For details of default permissions granted to applications in WebSphere, please refer to the following policy files: /QIBM/ProdData/Java400/jdk14/lib/security/java.policy /QIBM/UserData/WebASE51/ASE/instance/properties/server.policy /QIBM/UserData/WebASE51/ASE/instance/config/cells/cell/nodes/node/app.policy where instance is the name of your instance, cell is the name of your cell, and node is the name of your node. Check_Content From the admin console, select Security >> Global Security >> Java 2 Security. If "Use Java 2 security to restrict application access to local resources" is not selected, this is a finding. Fix_Text From the admin console, select Security >> Global Security >> Java 2 Security. Select the "Use Java 2 security to restrict application access to local resources" check box. Ensure the application security policies are defined and access permissions are granted accordingly. Policies are created and access is granted on an application by application basis. Application access to the underlying host is based upon application access requirements. Not_Reviewed Vuln_Num V-255834 Rule_ID SV-255834r1137578_rule Severity high Rule_Title The WebSphere Application Server Java 2 security must not be bypassed. Vuln_Discuss WebSphere provides a passive filter mechanism that will allow administrators to set Java 2 security in the admin console as enabled while still allowing applications to access host resources. This setting bypasses the enforcement of Java2 security. Application access is allowed and activity is logged to the system.out file. This feature is to aid in the identification of application access requirements to the underlying host so security policies can be created. This feature is executed via a custom property that is set for each application server instance operating on the WebSphere server. This setting should only be enabled in a development or testing environment in order to identify what applications access requirements are so security policies can then be created. Check_Content If the system is a development or test system, this requirement is NA. From the admin console, select Servers >> Server Types >> WebSphere application servers. For each application server, select Server Infrastructure >> Administration >> Custom properties. If the "com.ibm.websphere.java2secman.norethrow" resource value exists and is set to "true", this is a finding. Fix_Text From the admin console, select Servers >> Server Types >> WebSphere application servers. For each application server, select Server Infrastructure >> Administration >> Custom properties. Delete the "com.ibm.websphere.java2secman.norethrow" resource value from production systems. Not_Reviewed Vuln_Num V-255835 Rule_ID SV-255835r1137578_rule Severity medium Rule_Title The WebSphere Application Server users in the admin role must be authorized. Vuln_Discuss Strong access controls are critical to securing the application server. Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) must be employed by the application server to control access between users (or processes acting on behalf of users) and objects (e.g., applications, files, records, processes, application domains) in the application server. Without stringent logical access and authorization controls, an adversary may have the ability, with very little effort, to compromise the application server and associated supporting infrastructure. Satisfies: SRG-APP-000033-AS-000024, SRG-APP-000380-AS-000088, SRG-APP-000340-AS-000185 Check_Content Review System Security Plan documentation. In the administrative console, navigate to Users and Groups >> Administrative user roles. If users assigned to the admin role are not authorized by the ISSO/ISSM, this is a finding. Fix_Text Navigate to User and Groups >> Administrative user roles. If an unauthorized user is assigned to the admin role, click on the user, remove admin rights and assign proper roles as defined in System Security Plan. Do not delete any user with the "Primary administrative user name" designation. Click "OK". Click "Save". Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255836 Rule_ID SV-255836r1137578_rule Severity medium Rule_Title The WebSphere Application Server LDAP groups must be authorized for the WebSphere role. Vuln_Discuss Strong access controls are critical to securing the application server. Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) must be employed by the application server to control access between users (or processes acting on behalf of users) and objects (e.g., applications, files, records, processes, application domains) in the application server. Without stringent logical access and authorization controls, an adversary may have the ability, with very little effort, to compromise the application server and associated supporting infrastructure. Satisfies: SRG-APP-000033-AS-000024, SRG-APP-000267-AS-000170 Check_Content Review System Security Plan documentation. Review details regarding LDAP groups that are mapped to WebSphere roles. In the administrative console, under Users and Groups >> Administrative group roles. If there is a LDAP group or groups assigned to a WebSphere role that has not been authorized by the ISSO/ISSM, this is a finding. Fix_Text Navigate to User and Groups >> Administrative group roles. If any group is assigned roles that the group should not have, click on the group. Assign only the role(s) the group should have. Click "OK". Click "Save". Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255837 Rule_ID SV-255837r961353_rule Severity medium Rule_Title The WebSphere Application Server users in a LDAP user registry group must be authorized for that group. Vuln_Discuss Preventing non-privileged users from executing privileged functions mitigates the risk that unauthorized individuals or processes may gain unnecessary access to information or privileges. Restricting non-privileged users also prevents an attacker, who has gained access to a non-privileged account, from elevating privileges, creating accounts, and performing system checks and maintenance. Check_Content If a file based or local federated repository is in use, this requirement is NA. Review System Security Plan documentation. Interview the system administrator. In the administrative console select Security >> Global Security. Under "User Account Repository", verify the "Available realm Definition" is set to "Standalone LDAP registry". Select "Configure". The properties of the LDAP repository are displayed for purposes of identifying the LDAP server. Work with the admin of LDAP repository. Identify users and groups. Validate members of groups are authorized. If the group members have not been authorized by the ISSO/ISSM, this is a finding. Fix_Text In the LDAP server admin console, assign WebSphere users to the appropriate WebSphere group. Not_Reviewed Vuln_Num V-255838 Rule_ID SV-255838r960843_rule Severity medium Rule_Title The WebSphere Application Server management interface must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. Vuln_Discuss Application servers are required to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system management interface, providing privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance that states that: (i) users are accessing a U.S. Government information system; (ii) system usage may be monitored, recorded, and subject to audit; (iii) unauthorized use of the system is prohibited and subject to criminal and civil penalties; and (iv) the use of the system indicates consent to monitoring and recording. System use notification messages can be implemented in the form of warning banners displayed when individuals log on to the information system. System use notification is intended only for information system access including an interactive logon interface with a human user, and is not required when an interactive interface does not exist. Use this banner for desktops, laptops, and other devices accommodating banners of 1300 characters. The banner shall be implemented as a click-through banner at logon (to the extent permitted by the operating system), meaning it prevents further activity on the information system unless and until the user executes a positive action to manifest agreement by clicking on a box indicating "OK". "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." Check_Content Point browser to the URL of the WebSphere administration console. If the Standard Mandatory DoD Notice and Consent Banner is not displayed, this is a finding. Fix_Text Open the file ${WAS_HOME}/properties/login.info. Follow the instructions in the HTML comment section to create the pre-logon banner. Enter the Standard DoD Mandatory Notice and Consent banner into the HTML section. If logged on to the admin console, log out and log back on to validate the changes. Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255839 Rule_ID SV-255839r960846_rule Severity medium Rule_Title The WebSphere Application Server management interface must retain the Standard Mandatory DoD Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access. Vuln_Discuss To establish acceptance of system usage policy, a click-through banner at the application server management interface logon is required. The banner shall prevent further activity on the application server unless and until the user executes a positive action to manifest agreement by clicking on a box indicating "OK". Check_Content Point browser to the URL of the WebSphere administration console. If the Standard Mandatory DoD Notice and Consent Banner is not retained until the user acknowledges the usage conditions, this is a finding. Fix_Text Open the file ${WAS_HOME}/properties/login.info. Follow the instructions in the HTML comment section to create the pre-logon banner. Enter the Standard DoD Mandatory Notice and Consent banner into the HTML section. If logged on to the admin console, log out and log back on to validate the changes. Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255840 Rule_ID SV-255840r960885_rule Severity low Rule_Title The WebSphere Application Server must generate log records when successful/unsuccessful attempts to access subject privileges occur. Vuln_Discuss Accessing a subject's privileges can be used to elevate a lower-privileged subject's privileges temporarily in order to cause harm to the application server or to gain privileges to operate temporarily for a designed purpose. When these actions take place, the event needs to be logged. Application servers either provide a local user store, or they integrate with enterprise user stores like LDAP. When the application server provides the user store and enforces authentication, the application server must generate a log record when modification of privileges is successfully or unsuccessfully performed. Check_Content In the administrative console, navigate to Security >> Security auditing >> Audit Service Provider. Click on the providers in the list. Note: names of all the filters, e.g., "DefaultAuditSpecification_1". Go back to Security >> Security auditing >> Event type Filters. Find the filters previously noted. If you do not see the filter for SECURITY_AUTHN, SECURITY_AUTHZ, SECURITY_AUTHN_TERMINATE, and ADMIN_REPOSITORY_SAVE that has INFO, ERROR, SUCCESS, DENIED, REDIRECT, and WARNING defined, this is a finding. Fix_Text In the administrative console, navigate to Security >> Security auditing >> Audit Service Provider. Click on the providers in the list. Note the names of all the filters, e.g., "DefaultAuditSpecification_1". Go back to Security >> Security auditing >> Event type Filters. Find the filters previously noted. If you do not see that the provider filter for SECURITY_AUTHN, SECURITY_AUTHZ, SECURITY_AUTHN_TERMINATE, and ADMIN_REPOSITORY_SAVE that has INFO, ERROR, SUCCESS, DENIED, REDIRECT, and WARNING defined, click the "New" button to create a new filter. Give it a unique name. Select "SECURITY_AUTHN" and "ADMIN_REPOSITORY_SAVE" from the "Events to associate with audit filter" field. Click the right arrow to fill in "Enabled events" field. From "Event outcomes to associate with an audit filter" field, select INFO, ERROR, SUCCESS, DENIED, REDIRECT, and WARNING. Click the right arrow to fill in "Enabled event outcomes" field. Click "OK". Go back to Security >> Security auditing >> Audit Service Provider >> [provider]. Under "Selectable filters", select the new filter just created. Click the right arrow to add it to the list. Click "OK". Click "Save". Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255841 Rule_ID SV-255841r961392_rule Severity medium Rule_Title The WebSphere Application Server must allocate JVM log record storage capacity in accordance with organization-defined log record storage requirements. Vuln_Discuss 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. But sometimes they may be useful in providing more context when correlated with audit related events. The proper management of log records not only dictates proper archiving processes and procedures be established, it also requires allocating enough storage space to maintain the logs online for a defined period of time. If adequate online log storage capacity is not maintained, intrusion monitoring, security investigations, and forensic analysis can be negatively affected. It is important to keep a defined amount of logs online and readily available for investigative purposes. The logs may be stored on the application server until they can be archived to a log system or, in some instances, a Storage Area Networks (SAN). Regardless of the method used, log record storage capacity must be sufficient to store log data when the data cannot be offloaded to a log system or SAN. Check_Content Review System Security Plan documentation. Identify the JVM log size and rotation settings based on component log policy. From the administrative console, navigate to Troubleshooting >> Logs and Trace. Choose [server name]. Click on the server name to select it. Click "JVM" Logs. For "System.out" verify "File Size" is selected and "Maximum size" and "Maximum Historical Log Files" are set according to the System Security Plan. For "System.err" verify "File Size" is selected and "Maximum size" and "Maximum Historical Log Files" are set according to the System Security Plan. If log size and log history retention settings for "System.err" and "System.out" are not set as per the System Security Plan, this is a finding. Fix_Text Identify JVM log size and history retention based on component log policy. Document those values in the System Security Plan. From the administrative console, navigate to Troubleshooting >> Logs and Trace. Select each [server name]. Click "JVM" Logs. Under "System.out", "Log Rotation", select "File size" in the "Maximum Size" entry field, enter the maximum log size based on policy. Under "System.err", "Log Rotation", select "File Size" in the "Maximum Size" entry field, enter the maximum log size based on policy. Click "OK". Click "Save". Not_Reviewed Vuln_Num V-255842 Rule_ID SV-255842r961392_rule Severity medium Rule_Title The WebSphere Application Server must allocate audit log record storage capacity in accordance with organization-defined log record storage requirements. Vuln_Discuss The proper management of log records not only dictates proper archiving processes and procedures be established, it also requires allocating enough storage space to maintain the logs online for a defined period of time. If adequate online log storage capacity is not maintained, intrusion monitoring, security investigations, and forensic analysis can be negatively affected. It is important to keep a defined amount of logs online and readily available for investigative purposes. The logs may be stored on the application server until they can be archived to a log system or, in some instances, a Storage Area Networks (SAN). Regardless of the method used, log record storage capacity must be sufficient to store log data when the data cannot be offloaded to a log system or SAN. Check_Content Review System Security Plan documentation. Identify the Audit Service Provider log size and rotation settings based on component log policy. From administrative console, click Security >> Security auditing >> Audit service provider. Select each [audit_service_provider_name]. If "Audit Log Size" and "Max Number of Audit Log Files" are not configured as per the System Security Plan, this is a finding. Fix_Text Identify Audit Service Provider log size and history retention based on component log policy. Document those values in the System Security Plan. From administrative console, click Security >> Security auditing >>Related Items>> Audit service provider >> [audit_service_provider_name]. Under Audit log file size specify the size of the file in MB as defined by your policy. Under "Maximum number of audit logs files", specify the maximum number of logs you want to keep on the file system as defined by your policy. Click "OK". Click "Save". Not_Reviewed Vuln_Num V-255843 Rule_ID SV-255843r961401_rule Severity medium Rule_Title The WebSphere Application Server must provide an immediate real-time alert to authorized users of all log failure events requiring real-time alerts. Vuln_Discuss It is critical for the appropriate personnel to be aware if a system is at risk of failing to process logs as required. Log processing failures include software/hardware errors, failures in the log capturing mechanisms, and log storage capacity being reached or exceeded. Notification of the failure event will allow administrators to take actions so that logs are not lost. Check_Content If notifications of log processing failures are done via an alternative notification process, this is not a finding. In the administrative console, navigate to Security >> Security auditing >> Audit monitor. If "Enabled monitoring" is not checked and "Monitor notification" is not set to a name in the notifications list, this is a finding. Fix_Text Establish and utilize a notification process for WebSphere log events or configure WebSphere to send log events alerts via email. In the administrative console, navigate to Security >> Security auditing >> Audit monitor. Select a "Monitor" notification from the dropdown box or create a new notification. Click on "New". Specify a unique name for the new notification. Click "Message log" checkbox. Select "Email sent to notification list". Enter emails in the "Email address to add" field. Enter the mail server address in the "Outgoing mail (STMP) server" field. Click ">" to put email in "List of email addresses" field. Click "OK". Select the "Enable monitoring" check box to turn on audit failure notifications. Select the notification configuration to be used from the "Monitor notification" dropdown menu. Click "OK". Click "Save". Not_Reviewed Vuln_Num V-255844 Rule_ID SV-255844r960912_rule Severity low Rule_Title The WebSphere Application Server must alert the SA and ISSO, at a minimum, in the event of a log processing failure. Vuln_Discuss Logs are essential to monitor the health of the system, investigate changes that occurred to the system, or investigate a security incident. When log processing fails, the events during the failure can be lost. To minimize the timeframe of the log failure, an alert needs to be sent to the SA and ISSO at a minimum. 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. Check_Content If the SA and ISSO are notified of log processing failures via an alternative notification process, this is not a finding. In the administrative console, navigate to Security >> Security auditing >> Audit monitor. If "Enabled monitoring" is not checked and "Monitor notification" is not set to a notification in the notifications list, that includes the SA and ISSO, this is a finding. Fix_Text Establish and utilize a notification process for WebSphere log events or configure WebSphere to send log event alerts via email. In the administrative console, navigate to Security >> Security auditing >> Audit monitor. Click on "New" button. Specify a unique name for the new notification name. Click "Message log" checkbox. Select "Email sent to notification list". Enter SA and ISSO emails in the "Email address to add" field. Enter the mail server address in the "Outgoing mail (STMP) server" field. Click ">" to put email in "List of email addresses" field. Click "OK". Select the "Enable monitoring" check box to turn on audit failure notifications. Select the notification configuration to be used from the "Monitor notification" dropdown menu. Click "OK". Click "Save". Not_Reviewed Vuln_Num V-255845 Rule_ID SV-255845r960912_rule Severity medium Rule_Title The WebSphere Application Server audit subsystem failure action must be set to Log warning. Vuln_Discuss Logs are essential to monitor the health of the system, investigate changes that occurred to the system, or investigate a security incident. When log processing fails, the events during the failure can be lost. To minimize the timeframe of the log failure, an alert needs to be sent to the SA and ISSO at a minimum. 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. WebSphere must be set to log warnings that the audit subsystem has failed or is in danger or failing so action can be taken to correct the issue. Check_Content In the administrative console, navigate to Security >> Security auditing. If "Audit subsystem failure action" is not set to "Log Warning", this is a finding. Fix_Text In the administrative console, navigate to Security >> Security auditing. Click the "Audit subsystem failure action" dropdown box. Select "Log Warning". Click "Apply". Click "Save" to save the configuration. Restart the DMGR and all JVMs. Not_Reviewed Vuln_Num V-255846 Rule_ID SV-255846r1043188_rule Severity low Rule_Title The WebSphere Application Server must shut down by default upon log failure (unless availability is an overriding concern). Vuln_Discuss It is critical that, when a system is at risk of failing to process logs, it detects and takes action to mitigate the failure. Log processing failures include software/hardware errors, failures in the log capturing mechanisms, and log storage capacity being reached or exceeded. During a failure, the application server must be configured to shut down unless the application server is part of a high availability system or availability is an overriding concern. When availability is an overriding concern, other approved actions in response to a log failure include: (i) If the failure was caused by the lack of log record storage capacity, the application must continue generating log records if possible (automatically restarting the log service if necessary), overwriting the oldest log records in a first-in-first-out manner. (ii) If log records are sent to a centralized collection server and communication with this server is lost or the server fails, the application must queue log records locally until communication is restored or until the log records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local log data with the collection server. If the server will continue to process without any logging mitigations in place and the availability of the server is not critical to the success of the mission, the server must be configured to shut down on log failure. Check_Content If the System Security Plan documentation specifies system availability is an overriding concern, this requirement is NA. In the admin console click Security >> Security Auditing. If "Audit subsystem failure action" is not set to "Terminate", this is a finding. Fix_Text In the admin console click Security >> Security Auditing. Set "Audit subsystem failure action" to "Terminate". Restart the DMGR and all JVMs. Not_Reviewed Vuln_Num V-255847 Rule_ID SV-255847r1043188_rule Severity low Rule_Title The WebSphere Application Server high availability applications must be configured to fail over to another system in the event of log subsystem failure. Vuln_Discuss This requirement is dependent upon system MAC and availability. If the system MAC and availability do not specify redundancy requirements, this requirement is NA. It is critical that, when a system is at risk of failing to process logs as required, it detects and takes action to mitigate the failure. Application servers must be capable of failing over to another system which can handle application and logging functions upon detection of an application log processing failure. This will allow continual operation of the application and logging functions while minimizing the loss of operation for the users and loss of log data. Check_Content If the System Security Plan documentation does not require redundancy, this requirement is NA. Click Servers >> Clusters >> WebSphere application server clusters. Ensure you have a cluster defined for every application requiring redundancy. If there is not a cluster defined for every application requiring redundancy, this is a finding. Fix_Text In the admin console, Click Servers >> Clusters >> WebSphere application server clusters. Define a cluster for every high availability application as outlined in the System Security Plan documentation. Refer to vendor documentation for steps on creating a fail over cluster. Not_Reviewed Vuln_Num V-255848 Rule_ID SV-255848r960930_rule Severity low Rule_Title The WebSphere Application Server must be configured to protect log information from any type of unauthorized read access. Vuln_Discuss WebSphere uses role-based access controls to restrict access to log data. To take advantage of this capability, WebSphere administrators must identify specific users and place them into their respective roles. The auditor role is used for controlling access to logs. Check_Content Review system documentation and System Security Plan. Identify the home folder and user account for the WebSphere installation. Log on to the operating system that is hosting the WebSphere application server. By default, WebSphere will be installed in the "/opt/IBM/Websphere" folder on UNIX like systems and in the "C:\Program Files\IBM\Websphere\" folder on Windows systems. On UNIX systems, verify file permissions for the "WebSphere" folder are set to "770" for the WebSphere user, group, and other. Permissions do not propagate to sub-folders. On Windows systems, verify file permissions for "WebSphere" folder allow SYSTEM, WebSphere User and Admin Group full control. Permissions do not propagate to sub-folders. If file permissions exceed these restrictions, this is a finding. Fix_Text On the system hosting the WebSphere application server, log on to the operating system with admin rights. Navigate to the WebSphere folder, change permissions on the folder. Do not propagate permissions to sub-folders. For UNIX systems: set "WebSphere" folder permissions to "770". For Windows systems: set "WebSphere" folder permission to allow full control for SYSTEM, WebSphere user and Admin Group. Do not propagate permissions to sub-folders. Not_Reviewed Vuln_Num V-255849 Rule_ID SV-255849r960933_rule Severity medium Rule_Title The WebSphere Application Server must protect log information from unauthorized modification. Vuln_Discuss WebSphere uses role-based access controls to restrict access to log data. To take advantage of this capability, WebSphere administrators must identify specific users and place them into their respective roles. The auditor role is used for controlling access to logs. Check_Content Review System Security Plan and the system documentation. Identify the home folder and user account for the WebSphere installation. Log on to the operating system that is hosting the WebSphere application server. By default, WebSphere will be installed in the "/opt/IBM/Websphere" folder on UNIX like systems and in the "C:\Program Files\IBM\Websphere\" folder on Windows systems. On UNIX systems, verify file permissions for the "WebSphere" folder are set to "770" for the WebSphere user, group and other. Permissions do not propagate to sub-folders. On Windows systems, verify file permissions for "WebSphere" folder allow SYSTEM, WebSphere User, and Admin Group full control. Permissions do not propagate to sub-folders. If file permissions exceed these restrictions, this is a finding. Fix_Text On the system hosting the WebSphere application server, log on to the operating system with admin rights. Navigate to the "WebSphere" folder, change permissions on the folder. Do not propagate permissions to sub-folders. For UNIX systems: set "WebSphere folder" permissions to "770". For Windows systems: set "WebSphere folder" permission to allow full control for SYSTEM, WebSphere user, and Admin Group. Do not propagate permissions to sub-folders. Not_Reviewed Vuln_Num V-255850 Rule_ID SV-255850r960936_rule Severity medium Rule_Title The WebSphere Application Server must protect log information from unauthorized deletion. Vuln_Discuss WebSphere uses role based access controls to restrict access to log data. To take advantage of this capability, WebSphere administrators must identify specific users and place them into their respective roles. The auditor role is used for controlling access to logs. Check_Content Review System Security Plan and the system documentation. Identify the home folder and user account for the WebSphere installation. Log on to the operating system that is hosting the WebSphere application server. By default, WebSphere will be installed in the "/opt/IBM/Websphere" folder on UNIX like systems and in the "C:\Program Files\IBM\Websphere\" folder on Windows systems. On UNIX systems, verify file permissions for the "WebSphere" folder are set to "770" for the WebSphere user, group, and other. Permissions do not propagate to sub-folders. On Windows systems, verify file permissions for "WebSphere" folder allow SYSTEM, WebSphere User and Admin Group full control. Permissions do not propagate to sub-folders. If file permissions exceed these restrictions, this is a finding. Fix_Text On the system hosting the WebSphere application server, log on to the operating system with admin rights. Navigate to the WebSphere folder, change permissions on the folder. Do not propagate permissions to sub-folders. For UNIX systems: set "WebSphere" folder permissions to "770". For Windows systems: set "WebSphere" folder permission to allow full control for SYSTEM, WebSphere user, and Admin Group. Do not propagate permissions to sub-folders. Not_Reviewed Vuln_Num V-255851 Rule_ID SV-255851r960939_rule Severity medium Rule_Title The WebSphere Application Server wsadmin file must be protected from unauthorized access. Vuln_Discuss Protecting log data also includes identifying and protecting the tools used to view and manipulate log data. Depending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. It is, therefore, 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. Check_Content Review System Security Plan and the system documentation. Identify the home folder and user account for the WebSphere installation. Log on to the operating system that is hosting the WebSphere application server. By default, WebSphere will be installed in the "/opt/IBM/Websphere" folder on UNIX like systems and in the "C:\Program Files\IBM\Websphere\" folder on Windows systems. On UNIX systems, verify file permissions for the "WebSphere" folder are set to "770" for the WebSphere user, group, and other. Permissions do not propagate to sub-folders. On Windows systems, verify file permissions for "WebSphere" folder allow SYSTEM, WebSphere User, and Admin Group full control. Permissions do not propagate to sub-folders. If file permissions exceed these restrictions, this is a finding. Fix_Text On the system hosting the WebSphere application server, log on to the operating system with admin rights. Navigate to the "WebSphere" folder, and change permissions on the folder. Do not propagate permissions to sub-folders. For UNIX systems: set the "WebSphere" folder permissions to "770". For Windows systems: set the "WebSphere" folder permission to allow full control for SYSTEM, WebSphere user, and Admin Group. Do not propagate permissions to sub-folders. Not_Reviewed Vuln_Num V-255852 Rule_ID SV-255852r960942_rule Severity medium Rule_Title The WebSphere Application Server wsadmin file must be protected from unauthorized modification. Vuln_Discuss Protecting log data also includes identifying and protecting the tools used to view and manipulate log data. Depending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. It is, therefore, imperative that access to log tools be controlled and protected from unauthorized modification. If an attacker were to modify log tools, he could also manipulate logs to hide evidence of malicious activity. 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. Check_Content Review System Security Plan and the system documentation. Identify the home folder and user account for the WebSphere installation. Log on to the operating system that is hosting the WebSphere application server. By default, WebSphere will be installed in the "/opt/IBM/Websphere" folder on UNIX like systems and in the "C:\Program Files\IBM\Websphere\" folder on Windows systems. On UNIX systems, verify file permissions for the "WebSphere" folder are set to "770" for the WebSphere user, group, and other. Permissions do not propagate to sub-folders. On Windows systems, verify file permissions for "WebSphere" folder allow SYSTEM, WebSphere User, and Admin Group full control. Permissions do not propagate to sub-folders. If file permissions exceed these restrictions, this is a finding. Fix_Text On the system hosting the WebSphere Application Server, log on to the operating system with admin rights. Navigate to the "WebSphere" folder. Change the permissions on the folder. Do not propagate permissions to sub-folders. For UNIX systems: set the "WebSphere" folder permissions to "770". For Windows systems: set the "WebSphere" folder permission to allow full control for SYSTEM, WebSphere user, and Admin Group. Do not propagate permissions to sub-folders. Not_Reviewed Vuln_Num V-255853 Rule_ID SV-255853r960945_rule Severity medium Rule_Title The WebSphere Application Server wsadmin file must be protected from unauthorized deletion. Vuln_Discuss Protecting log data also includes identifying and protecting the tools used to view and manipulate log data. Depending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. It is, therefore, imperative that access to log tools be controlled and protected from unauthorized modification. If an attacker were to delete log tools, the application server administrator would have no way of managing or viewing the logs. 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, class, 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 from unauthorized deletion as well. Check_Content Review system documentation and security plan. Identify the home folder and user account for the WebSphere installation. Log on to the operating system that is hosting the WebSphere application server. By default, WebSphere will be installed in the "/opt/IBM/Websphere" folder on UNIX like systems and in the "C:\Program Files\IBM\Websphere\" folder on Windows systems. On UNIX systems, verify file permissions for the "WebSphere" folder are set to "770" for the WebSphere user, group, and other. Permissions do not propagate to sub-folders. On Windows systems, verify file permissions for WebSphere folder allow SYSTEM, WebSphere User, and Admin Group full control. Permissions do not propagate to sub-folders. If file permissions exceed these restrictions, this is a finding. Fix_Text On the system hosting the WebSphere application server, log on to the operating system with admin rights. Navigate to the "WebSphere" folder, change permissions on the folder. Do not propagate permissions to sub-folders. For UNIX systems: set the "WebSphere" folder permissions to "770". For Windows systems: set "WebSphere" folder permission to allow full control for SYSTEM, WebSphere user, and Admin Group. Do not propagate permissions to sub-folders. Not_Reviewed Vuln_Num V-255854 Rule_ID SV-255854r960951_rule Severity medium Rule_Title The WebSphere Application Server must be configured to encrypt log information. Vuln_Discuss 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. Encryption of log records must be tempered with architecture designs that incorporate log data into SIEM systems that read and act upon log data. Some SIEM systems may not be able to decrypt encrypted log data so encrypting the logs could be detrimental to the incident response process. This must be taken into account and addressed in the security plan. Check_Content Review System Security Plan documentation. If the System Security Plan does not specify the encryption of audit records, this requirement is NA. From the administrative console, click Security >> Security Auditing >> Audit record encryption configuration. If the "Enable encryption" check box is not selected, this is a finding. Fix_Text From the administrative console, click Security >> Security Auditing >> Audit record encryption configuration. Select the "Enable encryption" checkbox. Select the keystore that contains the encrypting certificate from the drop-down menu or click "New" to create a new keystore. If you are using an existing certificate to encrypt your audit records, ensure the Certificate in the keystore is selected and specify the intended certificate in the "Certificate alias" drop-down menu. If you are generating a new certificate to encrypt your audit records, do NOT use the "Create a new certificate in the selected keystore" option, this will generate a SHA-1 signed certificate, which is not allowed. Instead, select Security >> SSL Certificate and key management >> KeyStores and Certificates. Select the keystore that is associated with the server hosting the audit logs. Select "Personal Certificates". Select "Create". Select either a CA-Signed or Chained Certificate based on your requirements. Fill in the information required to generate the certificate. Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255855 Rule_ID SV-255855r960951_rule Severity medium Rule_Title The WebSphere Application Server must be configured to sign log information. Vuln_Discuss 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. Check_Content From the administrative console, click Security >> Security Auditing >> Audit record signing configuration. If the "Enable signing" checkbox is not selected, this is a finding. Fix_Text From the administrative console, click Security >> Security Auditing >> Audit record signing configuration. Select the "Enable signing" checkbox. Select the keystore that contains the encrypting certificate from the drop-down menu. If you are using an existing certificate to sign your audit records, ensure the Certificate in keystore is selected and specify the intended certificate in the "Certificate alias" drop-down menu. If you are generating a new certificate to sign your audit records, do NOT use the "Create a new certificate in the selected keystore" option, this will generate a SHA-1 signed certificate, which is not allowed. Instead, select Security >> SSL Certificate and key management >> KeyStores and Certificates. Select the keystore that is associated with the server hosting the audit logs. Select "Personal Certificates". Select "Create". Select either a CA-Signed or Chained Certificate based on your requirements. Fill in the information required to generate the certificate. Restart the DMGR and all the JVMs. Not_Reviewed Vuln_Num V-255856 Rule_ID SV-255856r960963_rule Severity medium Rule_Title The WebSphere Application Server process must not be started from the command line with the -password option. Vuln_Discuss The use of the -password option to launch a WebSphere process from the command line can result in a security exposure. Password information may become visible to any user with the ability to view system processes. For example, on a Linux system the "ps" command will display all running processes, which would include all of the command line flags used to start a WebSphere process. Check_Content Review System Security Plan documentation. Interview the system administrator. Access operating system to list commands currently running. For UNIX: run "ps -ef | grep -i wsadmin.sh" For windows: from a DOS prompt as admin user run "WMIC path win32_process where "caption='wsadmin.exe'" get CommandLine" If the results show "wsadmin.sh(exe) -user <username> -password <password>", this is a finding. Fix_Text When starting WebSphere commands, such as wsadmin, stopManager, stopNode, stopServer, or syncNode; do not use the "-password <password>" option. Use the interactive mode instead; you will be prompted for user id and password. For scripts, you may configure user id and password in the "connector properties" files. These files are under "Profile_Root/Properties" folder. - soap.client.props: for default SOAP - sas.client.props : for RMI and JSR160RMI connectors - ipc.client.props: for IPC connector Not_Reviewed Vuln_Num V-255857 Rule_ID SV-255857r960963_rule Severity medium Rule_Title The WebSphere Application Server files must be owned by the non-root WebSphere user ID. Vuln_Discuss Having files owned by the root or administrator user is an indication that the WebSphere processes are being run with escalated privileges. Running as root/admin user gives attackers elevated privileges that can be used to compromise the system more easily compared to operating the WebSphere processes with regular user privileges. Specifying a regular OS user when installing and managing WebSphere is best practice. By doing so, the WebSphere files will be owned by the user ID specified rather than being owned by the admin user. Use the underlying OS file permissions to ensure that access to the WebSphere files are restricted to only those users who require access. Check_Content Review System Security Plan documentation. Interview the system administrator. Determine the OS user and group information associated with the WebSphere processes. Identify the paths, files, and folders associated with the WebSphere installation. These include: - <WAS_HOME>: where you installed WebSphere. <WAS_HOME> default location: For UNIX: /opt/IBM/WebSphere/AppServer For Windows: C:\Program Files\IBM\WebSphere\AppServer - <PROFILE_HOME>: where the appserver instance resides. The default location is under "<WAS_HOME>/profiles". - <OTHER_HOME>: any additional files that may reside outside of <WAS_HOME>. Examples include: - shared library .jar files - Resource Adapter .rar files - Key and trust store files (.jks and .p12) - Other files such as jdbc drivers For Linux, use the command "find <directory> -user root" to find files owned by root user. On windows use the "dir /Q /S" command from the root directories to show the owners of all files. Examine the output for files owned by the administrator or root account. If any WebSphere file or additional files as described above are owned by root or the administrator, this is a finding. Fix_Text Note: executing this fix without proper planning regarding file ownership can render your installation inoperable. See vulnerability discussion before executing this fix. Ensure all WebSphere related files and folders are owned by the WebSphere OS user. Ensure OS group membership is restricted. File ownership changes for UNIX systems: chown -R <user> <WAS_HOME> chown -R <user> <PROFILE_HOME>, chown -R <user> <OTHER_HOME>, <OTHER_HOME> may be zero or more directories for other files Group ownership changes for UNIX systems: chgrp -R <user> <WAS_HOME> chgrp -R <user> <PROFILE_HOME>, chgrp -R <user> <OTHER_HOME>, where <OTHER_HOME> may be zero or more root directories for other files File ownership changes for Windows systems: "takeown /r /u <user> /f <directory /p <password of user>", where the <directory> is <WAS_HOME>, <PROFILE_HOME>, or <OTHER_HOME> Not_Reviewed Vuln_Num V-255858 Rule_ID SV-255858r960963_rule Severity low Rule_Title The WebSphere Application Server sample applications must be removed. Vuln_Discuss WebSphere samples are not intended for use in a production environment. Do not run them there, as they create significant security risks. In particular, the snoop servlet can provide an outsider with tremendous amounts of information about your system. This is precisely the type of information you do not want to give a potential intruder. Do not install the samples during the profile creation or uninstall the sample programs. Check_Content Navigate to Applications >> All Applications. Review all applications installed on the application server. If the sample applications snoop, ivt, or DefaultApplication are installed on a production system, this is a finding. Fix_Text Navigate to Applications >> All Applications. Click on the corresponding application checkbox. Select "Remove". Click "OK". Click "Save". Not_Reviewed Vuln_Num V-255859 Rule_ID SV-255859r960963_rule Severity low Rule_Title The WebSphere Application Server must remove JREs left by web server and plug-in installers for web servers and plugins running in the DMZ. Vuln_Discuss When you install IBM HTTP Server, the installer leaves behind a JRE. Remove this JRE, as it provides functions that are not needed by the Web server or plug-in under normal conditions. Keep in mind that this will make it impossible to run some tools such as ikeyman on this Web server. When you install the WebSphere Application Server HTTP Server plug-in using the IBM installer, it also leaves behind a JRE. Also, remove this JRE post install. Having a functioning JRE in the DMZ provides attackers who have breached into the DMZ with additional tools to carry out further attacks. Check_Content This check needs to be run on the web server operating in the DMZ. Review system documentation. Identify web servers operating in DMZ. If there are no web servers configured for the DMZ, this is not applicable. From the administrative console, select Server Types >> Web Servers. Select each web server operating in the DMZ. Identify the "Web server installation location". Open a secured command shell to the web server in the DMZ. Change directory to the web server installation location. CD to the /plugins folder. If a /java directory exists in the plugins folder, this is a finding. Fix_Text For web servers provided with the WebSphere installation that are operating in the DMZ. Remove the /java directory from within the plugins folder. Not_Reviewed Vuln_Num V-255860 Rule_ID SV-255860r960963_rule Severity medium Rule_Title The WebSphere Application Server must be run as a non-admin user. Vuln_Discuss Running WebSphere as an admin user gives attackers immediate admin privileges in the event the WebSphere processes are compromised. Best practice is to operate the WebSphere server with an account that has limited OS privileges. To configure system startup: https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/trun_processrestart.html Check_Content Interview systems manager. Identify the OS user ID that the WAS server runs as. Using relevant OS commands review OS processes and search for WAS processes (running as Java). Ensure they are running under the assigned non-administrative user id. For UNIX: "ps -ef|grep -i websphere" For Windows: "wmic path win32_process where "caption = 'java.exe'" get CommandLine If the WebSphere processes are running as the root or administrator user, this is a finding. Fix_Text Ensure that WAS processes are started via the specified non-privileged OS user ID when running commands such as startManager, startNode, and startServer. If startManager and startNode are in the system startup scripts, ensure that they are not started as the root user or admin user for Windows systems. For example, in the UNIX system, the inittab entry may look like: "was:235:respawn:/usr/WebSphere/AppServer/bin/rc.was >/dev/console 2>&1". Ensure the user is not a root user and is instead a regular OS user. Not_Reviewed Vuln_Num V-255861 Rule_ID SV-255861r960963_rule Severity medium Rule_Title The WebSphere Application Server must disable JSP class reloading. Vuln_Discuss Application servers provide a myriad of differing processes, features, and functionalities. Some of these processes may be deemed to be unnecessary or too unsecure to run on a production DoD system. Application servers must provide the capability to disable or deactivate functionality and services that are deemed to be non-essential to the server mission or can adversely impact server performance, for example, disabling dynamic JSP reloading on production application servers as a best practice. Check_Content From admin console, navigate to: Applications >> All applications >> [application name] >> JSP and JSP options. If "JSP enable class reloading" is checked, this is a finding. Fix_Text To disable JSP reloading: From the admin console, navigate to: Applications >> All applications >> [application name] >> JSP and JSP options. Uncheck "JSP enable class reloading". Not_Reviewed Vuln_Num V-255862 Rule_ID SV-255862r1043177_rule Severity medium Rule_Title The WebSphere Application Server must prohibit or restrict the use of nonsecure ports, protocols, modules, and/or services as defined in the PPSM CAL and vulnerability assessments. Vuln_Discuss Some networking protocols may not meet organizational security requirements to protect data and components. Application servers natively host a number of various features, such as management interfaces, httpd servers, and message queues. These features all run on TCPIP ports. This creates the potential that the vendor may choose to utilize port numbers or network services that have been deemed unusable by the organization. The application server must have the capability to both reconfigure and disable the assigned ports without adversely impacting application server operation capabilities. For a list of approved ports and protocols, reference the DoD ports and protocols website at https://powhatan.iiie.disa.mil/ports/cal.html. Check_Content In the administrative console, click Servers >> All Servers. Select each [server_name]. Select >> Ports. Confirm server ports are registered with PPSM. Navigate to System Administration >> Deployment Manager >> Ports. Confirm ports are registered with PPSM. Navigate to System Administration >> node agents. For each [node agent], select >> Ports. Confirm ports are registered with PPSM. If any of available ports are not registered with PPSM, or if those ports to be connected through the firewall are not approved by PPSM, this is a finding. Fix_Text Ensure all available ports are registered with PPSM. Not_Reviewed Vuln_Num V-255863 Rule_ID SV-255863r1051118_rule Severity medium Rule_Title The WebSphere Application Server LDAP user registry must be used. Vuln_Discuss To assure 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. To ensure support to the enterprise, the authentication must utilize an enterprise solution. Check_Content In the administrative console, click Security >> Global security. If the "Available realm definitions" drop down box under the "User account repository" section is not set to "Standalone LDAP registry", this is a finding. Fix_Text In the administrative console, click Security >> Global security. Under "User account repository", click the "Available realm definitions" drop-down list. Select "Standalone LDAP" registry. Click "Configure". Provide the Primary Administrative user name, type of LDAP server, hostname for the LDAP server, define the Base distinguished name. Click "OK". On "Global security" panel, click "Set as current". Click "Apply". Click "Save". Recycle and synchronize the JVMS. Not_Reviewed Vuln_Num V-255864 Rule_ID SV-255864r1051118_rule Severity medium Rule_Title The WebSphere Application Server local file-based user registry must not be used. Vuln_Discuss WebSphere does not provide direct audit of changes to the built-in file registry. The built-in file registry must not be used to support user logon accounts. Use an LDAP/AD server and manage user accounts centrally. Check_Content Navigate to Security >> Global Security. Under "User Account Repository" if the "Federated Repositories" is chosen, click on "Configure". Under "Repositories in the realm", if "o=defaultWIMFileBasedRealm" appears in the "Base Entry" column, this is a finding. Fix_Text Navigate to Security >> Global Security. Under "User Account Repository", select "Stand alone LDAP" from the "Available realm definitions" drop-down. Click on "Configure". Select an existing user from the LDAP directory to be the primary WebSphere admin user. Identify the type of LDAP server; specify an IP or DNS name for the LDAP Server, and the port used to connect to the LDAP server. Specify BASE DN. Specify the BIND DN. Specify the BIND Password. Select the "SSL enabled" check box to use secure LDAP. Click "Apply". Click "Save". Go to Global Security. Select "Standalone LDAP registry" from the "Available realm definitions" drop-down. Click "Set as current". Click "Apply". Click "Save". Restart the dmgr and synchronize the JVMs. Not_Reviewed Vuln_Num V-255865 Rule_ID SV-255865r960972_rule Severity medium Rule_Title The WebSphere Application Server multifactor authentication for network access to privileged accounts must be used. Vuln_Discuss 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. Multifactor authentication is defined as: using two or more factors to achieve authentication. Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric). A CAC or PKI Hardware Token meets this definition. A privileged account is defined as an information system account with authorizations of a privileged user. These accounts would be capable of accessing the web management interface. When accessing the application server via a network connection, administrative access to the application server must be PKI Hardware Token enabled. Satisfies: SRG-APP-000149-AS-000102, SRG-APP-000391-AS-000239, SRG-APP-000392-AS-000240, SRG-APP-000151-AS-000103, SRG-APP-000177-AS-000126, SRG-APP-000402-AS-000247, SRG-APP-000403-AS-000248, SRG-APP-000404-AS-000249, SRG-APP-000219-AS-000147 Check_Content Check that the admin console is enabled for client certificate logon. In the Deployment Manager, check the file on: <WAS_INSTALL>/profiles/<profileName>/config/cells/<cellName>/applications/isclite.ear/deployments/isclite/isclite.war/WEB-INF/web.xml. If the "XML element <auth-method>FORM</auth-method>" is present, this is a finding. Fix_Text From the admin console, select System Administration >> Deployment Manager >> Java and Process Management >> Process definition >> Java Virtual Machine >> Custom Properties. Select "New". Insert the following case sensitive value into the "Name" field: "adminconsole.certLogin". Select "Value". Enter "true". Click "Apply". Click "Save". Select Security >> SSL Certificate and Key management >> SSL Configurations >> Select CellDefaultSSLSettings >> Quality of Protection (QOP) settings. In the "Client Authentication" drop-box, make sure "Supported" or "Required" is selected. Click "Apply". Click "Save". Save a backup copy and edit the "Web.xml" file as follows: <WAS_INSTALL>/profiles/<profileName>/config/cells/<cellName>/applications/isclite.ear/deployments/isclite/isclite.war/WEB-INF/web.xml: --- Change: < security-constraint> <web-resource-collection> <web-resource-name>Protected Area</web-resource-name> <url-pattern>/</url-pattern> --- So it becomes: < security-constraint> <web-resource-collection> <web-resource-name>Protected Area</web-resource-name> <url-pattern>/</url-pattern> <url-pattern>/logon.jsp</url-pattern> <url-pattern>/logonError.jsp</url-pattern> --- Add these security constraints if not already present: <security-constraint> <web-resource-collection> <web-resource-name>free pages</web-resource-name> <url-pattern>/*.jsp</url-pattern> <url-pattern>/css/*</url-pattern> <url-pattern>/images/*</url-pattern> <url-pattern>/j_security_check</url-pattern> </web-resource-collection> </security-constraint> --- Change: <auth-method>FORM</auth-method> to <auth-method>CLIENT-CERT</auth-method> Save the "web.xml" file. Stop and restart the Deployment Manager. Log on to the admin console using your certificate. Not_Reviewed Vuln_Num V-255866 Rule_ID SV-255866r960993_rule Severity medium Rule_Title The WebSphere Application Server must provide security extensions to extend the SOAP protocol and provide secure authentication when accessing sensitive data. Vuln_Discuss Application servers may provide a web services capability that could be leveraged to allow remote access to sensitive application data. A web service which is a repeatable process used to make data available to remote clients, should not be confused with a web server. Many web services utilize SOAP, which in turn utilizes XML and HTTP as a transport. Natively, SOAP does not provide security protections. As such, the application server must provide security extensions to enhance SOAP capabilities to ensure that secure authentication mechanisms are employed to protect sensitive data. The WS_Security suite is a widely used and acceptable SOAP security extension. Check_Content Review System Security Plan documentation. Interview the system administrator. Identify any application web service providers and the secure authentication requirements for each service provider. From admin console, navigate to Applications >> All applications. Click on each application that is a web service provider where the security plan specifies security extensions are to be applied. Navigate to "Service provider policy sets and bindings". Verify that any web service providers that are required to have security extensions applied as per the security plan have a policy attached. If "Attached policy set" column displays none, but the System Security Plan specifies security extensions as required, this is a finding. Fix_Text To attach policy sets for your service providers: From admin console, navigate to Applications >> All applications >> [application]. For each application that is a web service provider and requires secure authentication, click on "Service provider policy sets and bindings." Click button on the "Select" column to select a resource. Click on "Attach Policy Set" drop down. Select policy set that best matches the provider environment. Click button on the "Select" column to select the same resource. Click on the "Assign binding" drop down. Select a binding that best matches the environment. Click "Save". Restart DMGR and resync the JVMs. Not_Reviewed Vuln_Num V-255867 Rule_ID SV-255867r960993_rule Severity medium Rule_Title The WebSphere Application Server must provide security extensions to extend the SOAP protocol and provide secure authentication when accessing sensitive data. Vuln_Discuss Application servers may provide a web services capability that could be leveraged to allow remote access to sensitive application data. A web service, which is a repeatable process used to make data available to remote clients, should not be confused with a web server. Many web services utilize SOAP, which in turn utilizes XML and HTTP as a transport. Natively, SOAP does not provide security protections. As such, the application server must provide security extensions to enhance SOAP capabilities to ensure that secure authentication mechanisms are employed to protect sensitive data. The WS_Security suite is a widely used and acceptable SOAP security extension. Check_Content Review System Security Plan documentation. Interview the system administrator. Identify any application web service clients. Identify the secure authentication requirements for each client. From admin console, navigate to Applications >> All applications. Click on each application that is a web service client where the security plan specifies security extensions are to be applied. Navigate to "Service client policy sets and bindings". Verify that any web service clients that are required to have security extensions applied as per the security plan have a policy attached. If "Attached policy set" column displays none, but the System Security Plan specifies security extensions as required, this is a finding. Fix_Text To attach policy sets for your service clients: From admin console, navigate to Applications >> All applications >> [application]. For each application that is a web service client and requires secure authentication, click on "Service client policy sets and bindings." Click button on the "Select" column to select a resource. Click on "Attach Client Policy Set" drop down. Select policy set that best matches the environment. Click button on the "Select" column to select the same resource. Click on the "Assign binding" drop down. Select a binding that best matches the environment. Click "Save". Restart DMGR and resync the JVMs. Not_Reviewed Vuln_Num V-255868 Rule_ID SV-255868r961863_rule Severity medium Rule_Title The WebSphere Application Server must authenticate all network-connected endpoint devices before establishing any connection. Vuln_Discuss Device authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device. Device authentication is accomplished via the use of certificates and protocols such as SSL mutual authentication. Device authentication is performed when the application server is providing web services capabilities and data protection requirements mandate the need to establish the identity of the connecting device before the connection is established. Note: with LDAP registry, the entire DN in the certificate is used to look up LDAP. Filters may be configured. With other registries, only the first attribute after the first "=", e.g., CN=<user> is used. https://www.ibm.com/support/knowledgecenter/prodconn_1.0.0/com.ibm.scenarios.wmqwassecure.doc/topics/implementing.htm?cp=SSEQTP_8.0.0 Satisfies: SRG-APP-000394-AS-000241, SRG-APP-000177-AS-000126 Check_Content Review System Security Plan documentation. Identify mutual authentication connection requirements. From the admin console, navigate to Security >> SSL Certificate and Key Management >> SSL Configuration. Select each [NodeDefaultSSLSettings] then go to Quality of Protection (QoP) Settings. If "Client authentication" is not set according to the security plan, this is a finding. Fix_Text From the admin console, navigate to Security >> SSL Certificate and Key Management >> SSL Configuration. For each [NodeDefaultSSLSettings] select Quality of Protection (QoP) Settings. Set "Client authentication" according to the security plan. Not_Reviewed Vuln_Num V-255869 Rule_ID SV-255869r961863_rule Severity medium Rule_Title The WebSphere Application Server must authenticate all endpoint devices before establishing a local, remote, and/or network connection using bidirectional authentication that is cryptographically based. Vuln_Discuss Device authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk. Device authentication is performed when the application server is providing web services capabilities and data protection requirements mandate the need to establish the identity of the connecting device before the connection is established. Because of the challenges of applying this requirement on a large scale, organizations are encouraged to only apply the requirement to those limited number (and type) of devices that truly need to support this capability. Note: with LDAP registry, the entire DN in the certificate is used to look up LDAP. Filters may be configured. With other registries, only the first attribute after the first "=", e.g., CN=<user> is used. Check_Content Review System Security Plan documentation. Identify mutual authentication connection requirements. From the admin console, navigate to Security >> SSL Certificate and Key Management >> SSL Configuration. Select each [NodeDefaultSSLSettings] then go to Quality of Protection (QoP) Settings. If "Client authentication" is not set according to the security plan, this is a finding. Note: with LDAP registry, the entire DN in the certificate is used to look up LDAP. Filters may be configured. With other registries, only the first attribute after the first "=", e.g., CN=<user> is used. Fix_Text From the admin console, navigate to Security >> SSL Certificate and Key Management >> SSL Configuration. For each [NodeDefaultSSLSettings] select Quality of Protection (QoP) Settings. Set "Client authentication" according to the security plan. Not_Reviewed Vuln_Num V-255870 Rule_ID SV-255870r961029_rule Severity high Rule_Title The WebSphere Application Server application security must be enabled for each security domain except for publicly available applications specified in the System Security Plan. Vuln_Discuss By default, all administrative and user applications in WebSphere® Application Server use the global security configuration. For example, a user registry defined in global security is used to authenticate users for every application in the cell. WebSphere allows for additional WebSphere security domains where different security attributes for some or all of your user applications can be set. These domains must also be configured to use application security. Check_Content Review System Security Plan documentation. Identify any publicly available applications. These are applications available to the public that do not require authentication to access (e.g., recruiting websites). If such applications exist on the system and are specifically allowed according to the security plan, this requirement is NA for those applications only. Navigate to security >> security domains. Click through each security domain. If "Customize for this domain" is checked for Application Security under the Security Attributes, but "Enable application security" is not checked, this is a finding. Fix_Text Navigate to security >> security domains. Click through each security domain. If "Customize for this domain" is checked for Application Security under the Security Attributes, but "Enable application security" is not checked, check "Enable application security". Expand "show" to find all affected nodes and servers. Click "OK". Click "Save". Synchronize the changes. Restart all affected nodes and servers. Not_Reviewed Vuln_Num V-255871 Rule_ID SV-255871r961029_rule Severity high Rule_Title The WebSphere Application Server secure LDAP (LDAPS) must be used for authentication. Vuln_Discuss Passwords need to be protected at all times, and encryption is the standard method for protecting passwords during transmission. Application servers have the capability to utilize LDAP directories for authentication. If LDAP connections are not protected during transmission, sensitive authentication credentials can be stolen. When the application server utilizes LDAP, the LDAP traffic must be encrypted. To ensure an error-free operation for this step, first extract to a file the Signer certificate of the LDAP and send that file to the WebSphere Application Server machine. Then add the certificate to the truststore being defined for the LDAP. In this way, you are assured that the remaining actions for this step will be successful. Satisfies: SRG-APP-000172-AS-000121, SRG-APP-000172-AS-000120 Check_Content In the administrative console, click Security >> Global security. Under "User account repository", click "Configure" for the "Standalone LDAP registry", on "Standalone LDAP registry" panel. If the "SSL" flag is not enabled, this is a finding. Fix_Text In the administrative console, click Security >> Global security. Under User account repository, click the "Available realm definitions" drop-down list. Select Standalone LDAP registry. Click "Configure". Click "SSL enabled". Click "OK". On Global security panel, click "Set as current". Click "Apply". Click "Save". To ensure an error-free operation for this step, you need to first extract to a file the Signer certificate of the LDAP and send that file to the WebSphere Application Server machine. You can then add the certificate to the trust store being defined for the LDAP. In this way, you are assured that the remaining actions for this step will be successful. Not_Reviewed Vuln_Num V-255872 Rule_ID SV-255872r961521_rule Severity medium Rule_Title The WebSphere Application Server must prohibit the use of cached authenticators after an organization-defined time period. Vuln_Discuss When the application server is using PKI authentication, a local revocation cache must be stored for instances when the revocation cannot be authenticated through the network, but if cached authentication information is out of date, the validity of the authentication information may be questionable. Check_Content Review System Security Plan documentation. Identify the cache timeout parameters for authentication. Standard value for admin timeout is 10 minutes; however, the ISSO may allow a case by case exception based on operational requirements. From the admin console, navigate to Security >> Global Security >> Authentication cache settings. If "Enable authentication cache" check box is set and "Cache timeout" is larger than the parameters specified in the security plan, this is a finding. Fix_Text From the admin console, navigate to Security >> Global Security >> Authentication. Click on "Authentication cache" settings. Enter the settings for "Cache timeout" in accordance with the parameters defined in the Systems Security Plan. Not_Reviewed Vuln_Num V-255873 Rule_ID SV-255873r961041_rule Severity high Rule_Title The WebSphere Application Server default keystore passwords must be changed. Vuln_Discuss The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and can pretend to be the authorized user. Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys. Java-based application servers utilize the Java keystore, which provides storage for cryptographic keys and certificates. The keystore is usually maintained in a file stored on the file system. Check_Content Review System Security Plan documentation. Interview the system administrator. Identify installation folders and DMGR info. Access the DMGR system via the OS. Stop the DMGR processes. This will shut down the application server so plan outages accordingly. The default file paths and DefaultMgr installation names are provided below, adjust paths, and dmgr name if your installation differs from the default. For UNIX systems: cd /opt/IBM/Websphere/Profiles/<DefaultDmgr01>/logs/dmgr/ -stopManager.sh -user [admin user name] - password [admin user password] -archive the SystemOut*.log files. (Copy to another location) -startManager.sh -grep -i cwpki0041w SystemOut.log For Windows: cd C:\program files\IBM\Websphere\Profiles\<DefaultDmgr01>\logs\dmgr\ -stopManager.exe -user [admin user name] - password [admin user password] -archive the SystemOut*.log files. (Copy to another location) -startManager.exe -findstr -I cwpki0041w systemout.log If the results include: "CWPKI0041W: One or more keystores are using the default password", this is a finding. Fix_Text Navigate to Security >> SSL Certificate and Key Management >> Key stores and certificates. Select a keystore from the list. Click "Change Password". Enter the new password and password confirmation. Click "OK". Repeat for every keystore in the list. Synchronize changes to all nodes. Not_Reviewed Vuln_Num V-255874 Rule_ID SV-255874r961044_rule Severity medium Rule_Title The WebSphere Application Server must use signer for DoD-issued certificates. Vuln_Discuss The cornerstone of PKI is the private key used to encrypt or digitally sign information. The key by itself is a cryptographic value that does not contain specific user information, but the key can be mapped to a user. Without mapping the certificate used to authenticate to the user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis. Application servers must provide the capability to utilize and meet requirements of the DoD Enterprise PKI infrastructure for application authentication. Check_Content Navigate to Security >> SSl certificate and key management >> SSL Configurations >> CellDefaultSSLSettings >> KeyStores and certificates. Click on cell default trust store. Click on "Signer Certificates". If no DoD root or intermediate certificates are present, this is a finding. Fix_Text Obtain the signer certificate either as Base 64 encoded ASCII file, or as binary DER data. Navigate to Security >> SSl certificate and key management >> SSL Configurations >> CellDefaultSSLSettings >> key stores and certificates. Click on cell default trust store. Click on "Signer Certificates". Click "Add". Enter a new alias for the signer, and the location of the file that stores signer certificate. For "Data type", choose the type appropriate for the file, either Base64-encoded ASCII data file, or binary DER data. Click "OK". Not_Reviewed Vuln_Num V-255875 Rule_ID SV-255875r1193273_rule Severity medium Rule_Title The WebSphere Application Server must utilize FIPS 140-2-approved encryption modules when authenticating users and processes. Vuln_Discuss Encryption is only as good as the encryption modules in use. Unapproved cryptographic module algorithms cannot be verified or 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. Check_Content Note: If FIPS 140-3 is configured in WBSP-AS-001770, this is not applicable. From the administrative console, click Security >> SSL certificate and key management >> Manage FIPS. If "Enable FIPS 140-2" is not selected, this is a finding. Fix_Text From administrative console, click Security >> SSL certificate and key management >> Manage FIPS. Check "Enable FIPS 140-2". Click "Save". Synchronize with the nodes. Restart all the JVMs. Not_Reviewed Vuln_Num V-255876 Rule_ID SV-255876r961527_rule Severity medium Rule_Title The WebSphere Application Server must accept Personal Identity Verification (PIV) credentials from other federal agencies to access the management interface. Vuln_Discuss Personal Identity Verification (PIV) credentials are those credentials issued by federal agencies that conform to FIPS Publication 201 and supporting guidance documents. OMB Memorandum 11-11 requires federal agencies to continue implementing the requirements specified in HSPD-12 to enable agency-wide use of PIV credentials. PIV credentials are only used in an unclassified environment. Access may be denied to authorized users if federal agency PIV credentials are not accepted to access the management interface. Check_Content Check that the admin console is enabled for client certificate logon. In the Deployment Manager, check the file on: <WAS_INSTALL>/profiles/<profileName>/config/cells/<cellName>/applications/isclite.ear/deployments/isclite/isclite.war/WEB-INF/web.xml. If the XML element "<auth-method>FORM</auth-method>" is present, this is a finding. Fix_Text From the admin console, select System Administration >> Deployment Manager >> Java and Process Management >> Process definition >> Java Virtual Machine >> Custom Properties. Select "New". Insert the following case sensitive value into the "Name" field: "adminconsole.certLogin" Select "Value". Enter "true". Click "Apply". Click "Save". Select Security >> SSL Certificate and Key management >> SSL Configurations >> Select CellDefaultSSLSettings >> Quality of Protection (QOP) settings. In the "Client Authentication" drop box, make sure "Supported" or "Required" is selected. Click "Apply". Click "Save". Save a backup copy and edit the Web.xml file as follows: <WAS_INSTALL>/profiles/<profileName>/config/cells/<cellName>/applications/isclite.ear/deployments/isclite/isclite.war/WEB-INF/web.xml: --- Change: < security-constraint> <web-resource-collection> <web-resource-name>Protected Area</web-resource-name> <url-pattern>/</url-pattern> --- So it becomes: < security-constraint> <web-resource-collection> <web-resource-name>Protected Area</web-resource-name> <url-pattern>/</url-pattern> <url-pattern>/logon.jsp</url-pattern> <url-pattern>/logonError.jsp</url-pattern> --- Add these security constraints if not already present: <security-constraint> <web-resource-collection> <web-resource-name>free pages</web-resource-name> <url-pattern>/*.jsp</url-pattern> <url-pattern>/css/*</url-pattern> <url-pattern>/images/*</url-pattern> <url-pattern>/j_security_check</url-pattern> </web-resource-collection> </security-constraint> --- Change: <auth-method>FORM</auth-method> to <auth-method>CLIENT-CERT</auth-method> Save the "web.xml" file. Stop and restart the Deployment Manager. Log on to the admin console using your certificate. Not_Reviewed Vuln_Num V-255877 Rule_ID SV-255877r1137585_rule Severity medium Rule_Title The WebSphere Application Server must use DoD-approved Signer Certificates. Vuln_Discuss Class 3 PKI certificates are used for servers and software signing rather than for identifying individuals. Class 4 certificates are used for business-to-business transactions. Utilizing unapproved certificates not issued or approved by DoD or CNS creates an integrity risk. The application server must utilize approved DoD or CNS Class 3 or Class 4 certificates for software signing and business-to-business transactions. Check_Content From administrative console, navigate to Security >> SSL Certificates and Key Management >> KeyStores and Certificates. For each keystore, click on "Signer Certificates". If any of the certificates are not issued by an approved DoD CA, this is a finding. Fix_Text Utilize DoD certificates that have been issued by a DoD PKI CA. To replace a non-DoD PKI-established certificate: From the administrative console, navigate to Security >> SSL Certificates and Key Management >> KeyStores and Certificates. For each keystore that requires the change: Import a new certificate by clicking "Import". Click "keystore" file. Enter the location of the new certificate. Specify the type of keystore and keystore password. Specify alias information. Click "Apply". After the certificate is imported, click on "Replace" to replace the original certificate with the new certificate. Not_Reviewed Vuln_Num V-255878 Rule_ID SV-255878r1137579_rule Severity medium Rule_Title The WebSphere Application Servers must not be in the DMZ. Vuln_Discuss The application server consists of the management interface and hosted applications. By separating the management interface from hosted applications, the user must authenticate as a privileged user to the management interface before being presented with management functionality. This prevents non-privileged users from having visibility to functions not available to the user. By limiting visibility, a compromised non-privileged account does not offer information to the attacker to functionality and information needed to further the attack on the application server. Application server management functionality includes functions necessary to administer the application server and requires privileged access via one of the accounts assigned to a management role. The hosted application and hosted application functionality consists of the assets needed for the application to function, such as the business logic, databases, user authentication, etc. The separation of application server administration functionality from hosted application functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, network addresses, network ports, or combinations of these methods, as appropriate. Check_Content Review System Security Plan and system architecture documentation. Interview the system administrator. Identify any DMZ networks. If there are no DMZ networks in the application server's architecture, this requirement is NA. In the administrative console, click Servers >> Server Types >> WebSphere application servers. For each application server, review the "hostname" field and determine if the application server has a DMZ network IP address. If any application server is hosted in the DMZ network, this is a finding. Fix_Text If any application server host is installed in the DMZ, reassign IP address to a secured network and reconfigure the application server. Not_Reviewed Vuln_Num V-255879 Rule_ID SV-255879r1043178_rule Severity medium Rule_Title The WebSphere Application Server DoD root CAs must be in the trust store. Vuln_Discuss This control focuses on communications protection at the session, versus packet level. At the application layer, session IDs are tokens generated by web applications to uniquely identify an application user's session. Web applications utilize session tokens or session IDs in order to establish application user identity. Proper use of session IDs addresses man-in-the-middle attacks, including session hijacking or insertion of false information into a session. Application servers must provide the capability to perform mutual authentication. Mutual authentication is when both the client and the server authenticate each other. Check_Content Review System Security Plan documentation for location of the trust store used to store the signers of the administrators certificates. By default this is "cellDefaultTrustStore". Navigate to Security >> SSL certificate and key management >> Keystore and certificates. Click on the trust store used to store the signers of the administrators' certificates (root CA). (The default is cellDefaultTrustStore). Click on "Signer Certificates". If there are no DoD signer certificates, this is a finding. Fix_Text Navigate to Security >> SSL certificate and key management >> Keystore and certificates. Click on the trust store used to store the signers of the administrators' certificates. (The default is cellDefaultTrustStore). Click on "Signer Certificates". Click "Add". Follow the instructions to import the signer from a file. Click "OK". Not_Reviewed Vuln_Num V-255880 Rule_ID SV-255880r961596_rule Severity medium Rule_Title The WebSphere Application Server personal certificates in all keystores must be issued by an approved DoD CA. Vuln_Discuss Untrusted Certificate Authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DoD systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DoD-approved CA, trust of this CA has not been established. The DoD will only accept PKI certificates obtained from a DoD-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of SSL/TLS certificates. The application server must only allow the use of DoD PKI-established certificate authorities for verification. Check_Content Review System Security Plan documentation for a list of DoD-approved CAs. From administrative console, navigate to Security >> SSL Certificates and Key Management >> KeyStores and Certificates. For each keystore, click on "Personal Certificates". If any of the certificates are not issued by an approved DoD CA, this is a finding. Fix_Text Utilize DoD certificates that have been issued by an approved DoD PKI CA. To replace a non-DoD PKI-established certificate: From the administrative console, navigate to Security >> SSL Certificates and Key Management >> KeyStores and Certificates. For each keystores that requires the change: Import a new certificate by clicking "Import". Click "keystore" file. Enter the location of the new certificate. Specify the type of keystore and keystore password. Specify alias information. Click "Apply". After the certificate is imported, click on "Replace" to replace the original certificate with the new certificate. Not_Reviewed Vuln_Num V-255881 Rule_ID SV-255881r961122_rule Severity low Rule_Title The WebSphere Application Server must be configured to perform complete application deployments when using A/B clusters. Vuln_Discuss Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. When an application is deployed to the application server, if the deployment process does not complete properly and without errors, there is the potential that some application files may not be deployed or may be corrupted and an application error may occur during runtime. The application server must be able to perform complete application deployments. A partial deployment can leave the server in an inconsistent state. Application servers may provide a transaction rollback function to address this issue. Check_Content Review System Security Plan documentation to determine if the server is configured to use A/B clusters. If the System Security Plan does not specify utilizing A/B clusters, the requirement is NA. From the administration console, select WebSphere application server clusters. Select each cluster name. Select cluster members. If the weight of any cluster member is "0", this is a finding. Fix_Text From the administration console, select WebSphere application server clusters. Select each cluster name. Select cluster members >> Details. Set all cluster members configured weight to a non-zero value. Not_Reviewed Vuln_Num V-255882 Rule_ID SV-255882r961122_rule Severity low Rule_Title The WebSphere Application servers with an RMF categorization of high must be in a high-availability (HA) cluster. Vuln_Discuss This requirement is dependent upon system MAC and confidentiality. If the system MAC and confidentiality levels do not specify redundancy requirements, this requirement is NA. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. When application failure is encountered, preserving application state facilitates application restart and return to the operational mode of the organization with less disruption of mission/business processes. Clustering of multiple application servers is a common approach to providing fail-safe application availability when system MAC and confidentiality levels require redundancy. Satisfies: SRG-APP-000225-AS-000154, SRG-APP-000435-AS-000069 Check_Content Review Systems Security Plan and identify system categorization. If the system is not categorized as HIGH, this requirement is NA. In the administrative console, click Servers >> Clusters >> WebSphere application server clusters. Ensure you have a cluster defined, if not this is a finding. Fix_Text In the administrative console, click Servers >> Clusters >> WebSphere application server clusters >> New. Specify a name for the cluster. Click "Next". Specify the name of the first cluster member. Select the node on which you want this cluster member to reside, leave remaining fields as default. Click "Next". Create additional cluster members as needed (give unique name for each member and click "Add Member"), when finished adding members click "Next". Click "Finish" to create the cluster. Click "Save". Refer to vendor documentation that provides direction on the creation of clusters for specific details. Restart DMGR and sync all JVMs. Not_Reviewed Vuln_Num V-255883 Rule_ID SV-255883r1067567_rule Severity low Rule_Title The WebSphere Application Server must not generate LTPA keys automatically. Vuln_Discuss Automated LTPA key generation can create unplanned outages. Plan to change your LTPA keys during a scheduled outage. Distribute the new keys to all nodes in the cell and to all external systems/cells during this outage window. Check_Content If LTPA is not utilized, this is not applicable. Request the documented process to manually regenerate the LTPA keys. The time period for regeneration must be defined, documented, and accepted by the ISSO but must be performed at least annually. Navigate to Security >> SSL Certificate and Key Management >> Key set groups >> Cell LTPAKeySetGroup. If automatically generate keys is checked, this is a finding. Fix_Text Navigate to Security >> SSL Certificate and Key Management >> Key set groups >> Cell LTPAKeySetGroup. Uncheck automatically generate keys. Click "OK". Click "Save". Restart the "Deployment Manager". Not_Reviewed Vuln_Num V-255884 Rule_ID SV-255884r1067567_rule Severity low Rule_Title The WebSphere Application Server must periodically regenerate LTPA keys. Vuln_Discuss The encryption of authentication information that is exchanged between servers involves the Lightweight Third-Party Authentication (LTPA) mechanism. LTPA utilizes encryption keys, if LTPA is utilized, the LTPA keys must be regenerated on a regular basis. The time period must be defined, documented and accepted by the ISSO but must be performed at least annually. Note: If LTPA keys are shared across cells, you must export the keys from the cell where the keys have been regenerated, and import into the cells whose keys have not changed. Instructions for managing the LTPA keys is provided here: https://www.ibm.com/support/knowledgecenter/en/SSAW57_9.0.0/com.ibm.websphere.nd.multiplatform.doc/ae/tsec_sslmanagelptakeys.html Check_Content If LTPA is not utilized, this is not applicable. Request the documented process to manually regenerate the LTPA keys. The time period for regeneration must be defined, documented and accepted by the ISSO but must be performed at least annually. Review documented process for LTPA key regeneration. If there is no process to regenerate LTPA keys periodically, this is a finding. Fix_Text These steps must be documented and then executed during the down time scheduled for periodic LTPA key regeneration. The time period must be defined, documented and accepted by the ISSO but must be performed at least annually. Navigate to Security >> SSL Certificate and Key Management >> Key set groups. Check "CellLTPAKeySetGroup". Click "Generate Keys". Click "Save". Then synchronize the changes to all nodes. Not_Reviewed Vuln_Num V-255885 Rule_ID SV-255885r961620_rule Severity medium Rule_Title The WebSphere Application Server high availability applications must be installed on a cluster. Vuln_Discuss DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. To reduce the possibility or effect of a DoS, the application server must employ defined security safeguards. These safeguards will be determined by the placement of the application server and the type of applications being hosted within the application server framework. There are many examples of technologies that exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting processes or restricting the number of sessions the application opens at one time). Employing increased capacity and bandwidth, combined with service redundancy or clustering, may reduce the susceptibility to some DoS attacks. Check_Content Review Systems Security Plan and identify system categorization. If the system is not categorized as HIGH, this requirement is NA. Identify HA applications installed on the server. Verify applications defined as requiring HA protections are running on a cluster. From the admin console, navigate to Application >> All Applications >> [application name] >> Target specific application status. If the target application has been designated as an HA application but is not running on a cluster, this is a finding. Fix_Text To create a cluster, navigate to Servers >> Clusters >> WebSphere Application Server Clusters >> New and follow the wizard. After cluster creation, re-install your application to the cluster. Refer to product documentation for specific details on how to create and manage WebSphere clusters. Not_Reviewed Vuln_Num V-255886 Rule_ID SV-255886r961620_rule Severity low Rule_Title The WebSphere Application Server memory session settings must be defined according to application load requirements. Vuln_Discuss DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. To reduce the possibility or effect of a DoS, the application server must employ defined security safeguards. These safeguards will be determined by the placement of the application server and the type of applications being hosted within the application server framework. There are many examples of technologies that exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting processes or restricting the number of sessions the application opens at one time). Employing increased capacity and bandwidth, combined with service redundancy or clustering, may reduce the susceptibility to some DoS attacks. Check_Content Review System Security Plan documentation. Identify the application load requirements defined by system owner. Regular application user session timeout values are defined at the DoD level at 20 minutes. An ISSO risk acceptance is required to deviate from that value. If session timeout values are not set to "20" and an ISSO risk acceptance is provided, this is not a finding. From the admin console, navigate to Servers >> all servers >> [web application server] >> Session management. For every [web application server], verify maximum in-memory session count. Verify "allow overflow" and "session timeout" are set according to application load requirements. If they are not set according to application load requirements, this is a finding. Fix_Text From the admin console navigate to Servers >> all servers >> [web application server] >> Session management. For every [web application server], set the "Maximum in-memory session count", "allow overflow", and "session timeout" values according to your organizational requirements. Not_Reviewed Vuln_Num V-255887 Rule_ID SV-255887r961620_rule Severity medium Rule_Title The WebSphere Application Server thread pool size must be defined according to application load requirements. Vuln_Discuss A thread pool enables components of the application server to reuse threads, which eliminates the need to create new threads at run time. Creating new threads expends system resources and can possibly lead to a DoS. Perform loading for your application to determine the required thread pool sizes. Check_Content Review System Security Plan documentation. Identify the application thread pool size requirements defined by system owner. From the admin console navigate to Servers >> all servers >> [server name] >> ThreadPools. Verify thread pool size according to specifications in documentation. If the maximum size for each threadpool is set too large, and not set according to application requirements, this is a finding. Fix_Text Perform loading for your application to determine the required thread pool sizes. To set thread pool size: From the admin console >> Servers >> all servers >> [server name] >> Additional Properties >> Select Thread Pools. Set the thread pool size for each threadpool. Not_Reviewed Vuln_Num V-255888 Rule_ID SV-255888r961632_rule Severity medium Rule_Title The WebSphere Application Server must remove all export ciphers to protect the confidentiality and integrity of transmitted information. Vuln_Discuss 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. Information on disabling export ciphers can be found in Knowledge Center at this link: http://www.ibm.com/support/knowledgecenter/SS7K4U_8.5.5/com.ibm.websphere.ihs.doc/ihs/rihs_ciphspec.html Check_Content From the administrative console, navigate to Security >> SSL certificate and key management >> SSL configurations >> [Name] >> for each SSL Configuration Select "Quality of protection (QoP) settings". Under "Cipher suite" settings, if any of the ciphers contained in the "Selected ciphers" box" contain "EXPORT" in their name, this is a finding. Fix_Text From the administrative console, navigate to Security >> SSL certificate and key management >> SSL configurations >> [Name] >> for each SSL configuration Select "Quality of protection (QoP) settings" under "Cipher suite" settings. Identify any ciphers that include "EXPORT" in their name. Remove the cipher by selecting the cipher. Click "Remove" button. Click "OK". Recycle the DMGR and sync the JVMs. Not_Reviewed Vuln_Num V-255889 Rule_ID SV-255889r961863_rule Severity medium Rule_Title The WebSphere Application Server distribution and consistency services (DCS) transport links must be encrypted. Vuln_Discuss A Core Group (HA Domain) is a component of the high availability manager function. It can contain stand-alone servers, cluster members, node agents, administrative agents, and the deployment manager. Core groups rely on DCS, which uses a reliable multicast message (RMM) system for transport. RMM can use one of several wire transport technologies. Depending on your environment, sensitive information might be transmitted over DCS. For example, data in DynaCache and the security subject cache are transmitted using DCS. To ensure this, select a transport type of channel framework and DCS-Secure as channel chain for each core group. Be aware that DCS always authenticates messages when global security is enabled. Once the transport is encrypted, you then have a highly secure channel. Once you have done this, all services that rely on DCS are now using an encrypted and authenticated transport. Those services are DynaCache, memory-to-memory session replication, core groups, Web services caching, and stateful session bean persistence. Check_Content From the admin console navigate to Servers >> Core groups. For every Core Group listed, select the Core Group [CoreGroup Name]. Under "Transport Type", select the "Channel Framework" button. If the "transport chain" drop down box is not set to "DCS-Secure", this is a finding. Fix_Text From the admin console navigate to Core groups >> for every Core Group listed. Select the [Core Group Name]. Under "Transport" type, select "CHANNEL_FRAMEWORK" button. In the "Transport chain" drop down box set to "DCS-SECURE". Click "Save". Sync the configuration. Not_Reviewed Vuln_Num V-255890 Rule_ID SV-255890r1137581_rule Severity medium Rule_Title The WebSphere Application Server plugin must be configured to use HTTPS only. Vuln_Discuss The Web server plug-in transmits information from the Web server to the Web container over HTTP by default. Extra steps must be taken to protect the traffic from the Web server to the Web container. To force the use of HTTPS for all traffic from the plug-in, disable the HTTP transport from the Web container on every application server and then regenerate and deploy the plug-in. WCInboundDefault and the HttpQueueInboundDefault transport chains must be disabled. At which time the plug-in can only use HTTPS and so it will use it for all traffic regardless of how the traffic arrived at the Web container. Check_Content From the admin console, navigate to Servers >> Server Types >> WebSphere Application Servers >> select each server (server name) >> Web Container Settings >> Web container transport chains. Verify both "WCInboundDefault" and the "HttpQueueInboundDefault" transport chains are disabled. If they are not disabled, this is a finding. Fix_Text From the admin console, navigate to Servers >> Server Types >> WebSphere Application Servers >> select each server (server name) >> Web Container Settings >> Web container transport chains. Select the "WCInboundDefault" and the "HttpQueueInboundDefault" transport chains and disable them. Click "Apply". Click "Save". Restart the DMGR and resynch the JVMs. Not_Reviewed Vuln_Num V-255891 Rule_ID SV-255891r961677_rule Severity medium Rule_Title The WebSphere Application Server must remove organization-defined software components after updated versions have been installed. Vuln_Discuss By default, when updating WebSphere application server, the older version of binaries are saved in case a "roll back" is necessary. Not keeping the older version makes it more difficult for attackers to "revert" back to the older version. Check_Content Review System Security Plan and system documentation to locate the "IBM InstallationManager" folder. Default locations are: UNIX: /opt/InstallationManager Windows: C:\Program Files\InstallationManager UNIX: <IMHOME>/eclipse/tools/imcl -c Select "P" preferences. Select "3" Files for rollback. Windows: <IMHOME>\eclipse\tools\imcl.exe -c Select "P" preferences. Select "3" Files for rollback. If "Save files for rollback" is checked, this is a finding. Fix_Text Review System Security Plan and system documentation to locate the "IBM InstallationManager" folder. Default locations are: UNIX: /opt/InstallationManager Windows: C:\Program Files\InstallationManager UNIX: <IMHOME>/eclipse/tools/imcl -c Select "P" preferences. Select "3" Files for rollback. Enter "1" to deselect. Enter "A" for apply. Enter "R" to return to Main Menu. Windows: <IMHOME>\eclipse\tools\imcl.exe -c Select "P" preferences. Select "3" Files for rollback. Enter "1" to deselect. Enter "A" for apply. Enter "R" to return to Main Menu. Not_Reviewed Vuln_Num V-255892 Rule_ID SV-255892r1137612_rule Severity medium Rule_Title The WebSphere Application Server must apply the latest security fixes. Vuln_Discuss Security vulnerabilities are often addressed by testing and applying the latest security patches and fix packs. Latest fixpacks can be found at: http://www-01.ibm.com/support/docview.wss?uid=swg27009661 Check_Content Use the admin console to determine the WebSphere version. Review patch level and fix pack. If the most recent patches/fix packs have not been applied, this is a finding. Fix_Text Obtain WebSphere product security and patch support. Test and apply the latest applicable WebSphere security fixes. Not_Reviewed Vuln_Num V-255893 Rule_ID SV-255893r1137612_rule Severity medium Rule_Title The WebSphere Application Server must install security-relevant software updates within the time period directed by an authoritative source (e.g., IAVMs, CTOs, DTMs, and STIGs). Vuln_Discuss Security flaws with software applications are discovered daily. Vendors are constantly updating and patching their products to address newly discovered security vulnerabilities. Organizations (including any contractor to the organization) are required to promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes) to production systems after thorough testing of the patches within a lab environment. Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling must also be addressed expeditiously. Check_Content From the admin console, click on "welcome". Under Suite Name, locate "WebSphere Application Server". View the "version". Access IBM support website: https://www.ibm.com/support Identify the most recent patch/fix version available for the WebSphere Traditional Application Server (not the Liberty version). If the most recent patches/fix packs have not been applied, this is a finding. Fix_Text Sign up to receive WebSphere security bulletins at the IBM website. Monitor IAVMs, CTOs, and DTMs for update notices affecting WebSphere. Obtain WebSphere product security and patch support. Test and apply the latest applicable WebSphere security fixes. Not_Reviewed Vuln_Num V-283677 Rule_ID SV-283677r1193276_rule Severity medium Rule_Title The WebSphere Application Server must use FIPS 140-3-approved encryption modules when authenticating users and processes. Vuln_Discuss Encryption is only as good as the encryption modules in use. Unapproved cryptographic module algorithms cannot be verified and cannot be relied upon to provide confidentiality or integrity, and DOD data may be compromised due to weak algorithms. The use of TLS provides confidentiality of data in transit between the application server and client. FIPS 140-3-approved TLS versions include TLS V1.0 or greater. TLS must be enabled and non-FIPS-approved SSL versions must be disabled. NIST SP 800-52 specifies the preferred configurations for government systems. Check_Content Note: If FIPS 140-2 is configured in WBSP-AS-001290, this is not applicable. This is allowed until 21 September 2026. If FIPS 140-2 is still in use after this date, this is a finding. From administrative console, click Security >> SSL certificate and key management >> Manage FIPS. If "Enable FIPS 140-3" is not selected, this is a finding. Fix_Text Implementation for Cell Profile (Network Deployment): 1. Back up the existing configuration: backupConfig.sh <backup_directory> 2. Stop all servers except the deployment manager: - Stop all node agents and application servers. - Keep only the deployment manager running. 3. Enable FIPS 140-3. Option A - Using Administrative Console: 1. Click Security >> SSL certificate and key management >> Manage FIPS. 2. Select "Enable FIPS 140-3". 3. Click "Apply". Option B - Using Admin Command: AdminTask.enableFips('[-enableFips true -fipsLevel FIPS140-3 ]') 1. Stop the deployment manager. 2. Restart the deployment manager. 3. Synchronize nodes. On each node, run: syncNode.sh <dmgr_host> <dmgr_port> 4. Start node agents and servers Implementation for Standalone Profile: 1. Back up the existing configuration: backupConfig.sh <backup_directory> 2. Enable FIPS 140-3. Option A - Using Administrative Console: 1. Click Security >> SSL certificate and key management >> Manage FIPS. 2. Select "Enable FIPS 140-3". 3. Click "Apply". Option B - Using Admin Command: AdminTask.enableFips('[-enableFips true -fipsLevel FIPS140-3 ]') For both methods, restart the application server. Not_Reviewed