Free DISA STIG and SRG Library | Vaulted

IBM WebSphere Traditional V9.x Security Technical Implementation Guide

Version 1 Release 1
2018-08-23
U_IBM_WebSphere_Traditional_V9-x_STIG_V1R1_Manual-xccdf.xml
This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.

Vulnerabilities (76)

The WebSphere Application Server maximum in-memory session count must be set according to application requirements.

Finding ID
WBSP-AS-000010
Rule ID
SV-95907r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000001-AS-000001
CCI
CCI-000054
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server admin console session timeout must be configured.

Finding ID
WBSP-AS-000020
Rule ID
SV-95909r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000295-AS-000263
CCI
CCI-002361
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server automatic repository checkpoints must be enabled to track configuration changes.

Finding ID
WBSP-AS-000120
Rule ID
SV-95911r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000016-AS-000013
CCI
CCI-000067
Target Key
(None)
Documentable
No
Discussion

Without enabling repository checkpoints, you will not be able to determine the history of changes to WebSphere configuration files, and who made those changes.

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.

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.

The WebSphere Application Server administrative security must be enabled.

Finding ID
WBSP-AS-000130
Rule ID
SV-95913r1_rule
Severity
Cat I
CCE
(None)
Group Title
SRG-APP-000315-AS-000094
CCI
CCI-002314
Target Key
(None)
Documentable
No
Discussion

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.

Fix Text

From the administrative console, click Security >> Global Security. Click "Enable administrative security". Click "Save". Restart the DMGR and all the JVMs.

Check Content

From the administrative console, click Security >> Global Security. If "Enable administrative security" is not selected, this is a finding.

The WebSphere Application Server bus security must be enabled.

Finding ID
WBSP-AS-000140
Rule ID
SV-95915r1_rule
Severity
Cat I
CCE
(None)
Group Title
SRG-APP-000315-AS-000095
CCI
CCI-002315
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server security auditing must be enabled.

Finding ID
WBSP-AS-000070
Rule ID
SV-95917r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000016-AS-000013
CCI
CCI-002234
Target Key
(None)
Documentable
No
Discussion

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

Fix Text

In the administrative console, navigate to Security >> Security auditing to enable. Restart the DMGR and all the JVMs.

Check Content

In the administrative console, navigate to Security >> Security auditing. If "Enable security auditing" is not enabled, this is a finding.

The WebSphere Application Server groups in the user registry mapped to WebSphere auditor roles must be configured in accordance with the security plan.

Finding ID
WBSP-AS-000080
Rule ID
SV-95919r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000016-AS-000013
CCI
CCI-002234
Target Key
(None)
Documentable
No
Discussion

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

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.

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.

The WebSphere Application Server users in the WebSphere auditor role must be configured in accordance with the System Security Plan.

Finding ID
WBSP-AS-000090
Rule ID
SV-95921r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000016-AS-000013
CCI
CCI-002234
Target Key
(None)
Documentable
No
Discussion

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

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.

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.

The WebSphere Application Server audit event type filters must be configured.

Finding ID
WBSP-AS-000100
Rule ID
SV-95923r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000016-AS-000013
CCI
CCI-002234
Target Key
(None)
Documentable
No
Discussion

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

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.

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.

The WebSphere Application Server audit service provider must be enabled.

Finding ID
WBSP-AS-000110
Rule ID
SV-95925r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000016-AS-000013
CCI
CCI-002234
Target Key
(None)
Documentable
No
Discussion

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

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.

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.

The WebSphere Application Server users in a local user registry group must be authorized for that group.

Finding ID
WBSP-AS-000150
Rule ID
SV-95927r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000315-AS-000094
CCI
CCI-002314
Target Key
(None)
Documentable
No
Discussion

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

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.

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.

The WebSphere Application Server Quality of Protection (QoP) must be set to use TLSv1.2 or higher.

Finding ID
WBSP-AS-000160
Rule ID
SV-95929r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000014-AS-000009
CCI
CCI-000068
Target Key
(None)
Documentable
No
Discussion

Quality of Protection specifies the security level, ciphers, and mutual authentication settings for the Secure Socket Layer (SSL/TLS) configuration.

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.

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.

The WebSphere Application Server global application security must be enabled.

Finding ID
WBSP-AS-000170
Rule ID
SV-95931r1_rule
Severity
Cat I
CCE
(None)
Group Title
SRG-APP-000014-AS-000009
CCI
CCI-000197
Target Key
(None)
Documentable
No
Discussion

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

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.

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.

The WebSphere Application Server Single Sign On (SSO) must have SSL enabled for Web and SIP Security.

Finding ID
WBSP-AS-000180
Rule ID
SV-95933r1_rule
Severity
Cat I
CCE
(None)
Group Title
SRG-APP-000014-AS-000009
CCI
CCI-000778
Target Key
(None)
Documentable
No
Discussion

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

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.

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.

The WebSphere Application Server security cookies must be set to HTTPOnly.

Finding ID
WBSP-AS-000190
Rule ID
SV-95935r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000015-AS-000010
CCI
CCI-001453
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server Java 2 security must be enabled.

Finding ID
WBSP-AS-000211
Rule ID
SV-95937r1_rule
Severity
Cat I
CCE
(None)
Group Title
SRG-APP-000033-AS-000024
CCI
CCI-000213
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server Java 2 security must not be bypassed.

Finding ID
WBSP-AS-000212
Rule ID
SV-95939r1_rule
Severity
Cat I
CCE
(None)
Group Title
SRG-APP-000033-AS-000024
CCI
CCI-000213
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server users in the admin role must be authorized.

Finding ID
WBSP-AS-000220
Rule ID
SV-95941r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000033-AS-000024
CCI
CCI-002235
Target Key
(None)
Documentable
No
Discussion

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

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.

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.

The WebSphere Application Server LDAP groups must be authorized for the WebSphere role.

Finding ID
WBSP-AS-000230
Rule ID
SV-95943r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000033-AS-000024
CCI
CCI-001314
Target Key
(None)
Documentable
No
Discussion

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

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.

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.

The WebSphere Application Server users in a LDAP user registry group must be authorized for that group.

Finding ID
WBSP-AS-000240
Rule ID
SV-95945r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000340-AS-000185
CCI
CCI-002235
Target Key
(None)
Documentable
No
Discussion

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.

Fix Text

In the LDAP server admin console, assign WebSphere users to the appropriate WebSphere group.

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.

The WebSphere Application Server management interface must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system.

Finding ID
WBSP-AS-000310
Rule ID
SV-95947r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000068-AS-000035
CCI
CCI-000048
Target Key
(None)
Documentable
No
Discussion

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."

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.

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.

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.

Finding ID
WBSP-AS-000320
Rule ID
SV-95949r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000069-AS-000036
CCI
CCI-000050
Target Key
(None)
Documentable
No
Discussion

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".

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.

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.

The WebSphere Application Server must generate log records when successful/unsuccessful attempts to access subject privileges occur.

Finding ID
WBSP-AS-000380
Rule ID
SV-95951r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000091-AS-000052
CCI
CCI-000172
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server must allocate JVM log record storage capacity in accordance with organization-defined log record storage requirements.

Finding ID
WBSP-AS-000580
Rule ID
SV-95953r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000357-AS-000038
CCI
CCI-001849
Target Key
(None)
Documentable
No
Discussion

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.

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".

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.

The WebSphere Application Server must allocate audit log record storage capacity in accordance with organization-defined log record storage requirements.

Finding ID
WBSP-AS-000590
Rule ID
SV-95955r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000357-AS-000038
CCI
CCI-001849
Target Key
(None)
Documentable
No
Discussion

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.

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".

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.

The WebSphere Application Server must provide an immediate real-time alert to authorized users of all log failure events requiring real-time alerts.

Finding ID
WBSP-AS-000630
Rule ID
SV-95957r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000360-AS-000066
CCI
CCI-001858
Target Key
(None)
Documentable
No
Discussion

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.

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".

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.

The WebSphere Application Server must alert the SA and ISSO, at a minimum, in the event of a log processing failure.

Finding ID
WBSP-AS-000640
Rule ID
SV-95959r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000108-AS-000067
CCI
CCI-000139
Target Key
(None)
Documentable
No
Discussion

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.

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".

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.

The WebSphere Application Server audit subsystem failure action must be set to Log warning.

Finding ID
WBSP-AS-000650
Rule ID
SV-95961r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000108-AS-000067
CCI
CCI-000139
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server must shut down by default upon log failure (unless availability is an overriding concern).

Finding ID
WBSP-AS-000660
Rule ID
SV-95963r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000109-AS-000068
CCI
CCI-000140
Target Key
(None)
Documentable
No
Discussion

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.

Fix Text

In the admin console click Security >> Security Auditing. Set "Audit subsystem failure action" to "Terminate". Restart the DMGR and all JVMs.

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.

The WebSphere Application Server high availability applications must be configured to fail over to another system in the event of log subsystem failure.

Finding ID
WBSP-AS-000670
Rule ID
SV-95965r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000109-AS-000070
CCI
CCI-000140
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server must be configured to protect log information from any type of unauthorized read access.

Finding ID
WBSP-AS-000740
Rule ID
SV-95967r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000118-AS-000078
CCI
CCI-000162
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server must protect log information from unauthorized modification.

Finding ID
WBSP-AS-000750
Rule ID
SV-95969r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000119-AS-000079
CCI
CCI-000163
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server must protect log information from unauthorized deletion.

Finding ID
WBSP-AS-000760
Rule ID
SV-95971r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000120-AS-000080
CCI
CCI-000164
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server wsadmin file must be protected from unauthorized access.

Finding ID
WBSP-AS-000770
Rule ID
SV-95973r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000121-AS-000081
CCI
CCI-001493
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server wsadmin file must be protected from unauthorized modification.

Finding ID
WBSP-AS-000780
Rule ID
SV-95975r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000122-AS-000082
CCI
CCI-001494
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server wsadmin file must be protected from unauthorized deletion.

Finding ID
WBSP-AS-000790
Rule ID
SV-95977r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000123-AS-000083
CCI
CCI-001495
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server must be configured to encrypt log information.

Finding ID
WBSP-AS-000810
Rule ID
SV-95979r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000126-AS-000085
CCI
CCI-001350
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server must be configured to sign log information.

Finding ID
WBSP-AS-000820
Rule ID
SV-95981r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000126-AS-000085
CCI
CCI-001350
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server process must not be started from the command line with the -password option.

Finding ID
WBSP-AS-000910
Rule ID
SV-95983r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000141-AS-000095
CCI
CCI-000381
Target Key
(None)
Documentable
No
Discussion

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.

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

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.

The WebSphere Application Server files must be owned by the non-root WebSphere user ID.

Finding ID
WBSP-AS-000920
Rule ID
SV-95985r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000141-AS-000095
CCI
CCI-000381
Target Key
(None)
Documentable
No
Discussion

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.

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>

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.

The WebSphere Application Server sample applications must be removed.

Finding ID
WBSP-AS-000930
Rule ID
SV-95987r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000141-AS-000095
CCI
CCI-000381
Target Key
(None)
Documentable
No
Discussion

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.

Fix Text

Navigate to Applications >> All Applications. Click on the corresponding application checkbox. Select "Remove". Click "OK". Click "Save".

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.

The WebSphere Application Server must remove JREs left by web server and plug-in installers for web servers and plugins running in the DMZ.

Finding ID
WBSP-AS-000940
Rule ID
SV-95989r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000141-AS-000095
CCI
CCI-000381
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server must be run as a non-admin user.

Finding ID
WBSP-AS-000960
Rule ID
SV-95991r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000141-AS-000095
CCI
CCI-000381
Target Key
(None)
Documentable
No
Discussion

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

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.

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.

The WebSphere Application Server must disable JSP class reloading.

Finding ID
WBSP-AS-000970
Rule ID
SV-95993r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000141-AS-000095
CCI
CCI-000381
Target Key
(None)
Documentable
No
Discussion

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.

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".

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.

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.

Finding ID
WBSP-AS-000980
Rule ID
SV-96007r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000142-AS-000014
CCI
CCI-000382
Target Key
(None)
Documentable
No
Discussion

Some networking protocols may not meet organizational security requirements to protect data and components. Application servers natively host a number of various features, such as management interfaces, httpd servers, and message queues. These features all run on TCPIP ports. This creates the potential that the vendor may choose to 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.

Fix Text

Ensure all available ports are registered with PPSM.

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.

The WebSphere Application Server LDAP user registry must be used.

Finding ID
WBSP-AS-001010
Rule ID
SV-96013r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000148-AS-000101
CCI
CCI-000764
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server local file-based user registry must not be used.

Finding ID
WBSP-AS-001020
Rule ID
SV-96019r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000148-AS-000101
CCI
CCI-000764
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server multifactor authentication for network access to privileged accounts must be used.

Finding ID
WBSP-AS-001030
Rule ID
SV-96025r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000149-AS-000102
CCI
CCI-002011
Target Key
(None)
Documentable
No
Discussion

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

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.

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.

The WebSphere Application Server must provide security extensions to extend the SOAP protocol and provide secure authentication when accessing sensitive data.

Finding ID
WBSP-AS-001080
Rule ID
SV-96039r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000156-AS-000106
CCI
CCI-001941
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server must provide security extensions to extend the SOAP protocol and provide secure authentication when accessing sensitive data.

Finding ID
WBSP-AS-001090
Rule ID
SV-96043r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000156-AS-000106
CCI
CCI-001941
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server must authenticate all network-connected endpoint devices before establishing any connection.

Finding ID
WBSP-AS-001110
Rule ID
SV-96047r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000394-AS-000241
CCI
CCI-001958
Target Key
(None)
Documentable
No
Discussion

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

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.

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.

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.

Finding ID
WBSP-AS-001120
Rule ID
SV-96055r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000395-AS-000109
CCI
CCI-001967
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server application security must be enabled for each security domain except for publicly available applications specified in the System Security Plan.

Finding ID
WBSP-AS-001180
Rule ID
SV-96057r1_rule
Severity
Cat I
CCE
(None)
Group Title
SRG-APP-000172-AS-000120
CCI
CCI-000197
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server secure LDAP (LDAPS) must be used for authentication.

Finding ID
WBSP-AS-001200
Rule ID
SV-96061r1_rule
Severity
Cat I
CCE
(None)
Group Title
SRG-APP-000172-AS-000121
CCI
CCI-000197
Target Key
(None)
Documentable
No
Discussion

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

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.

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.

The WebSphere Application Server must prohibit the use of cached authenticators after an organization-defined time period.

Finding ID
WBSP-AS-001210
Rule ID
SV-96065r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000400-AS-000246
CCI
CCI-002007
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server default keystore passwords must be changed.

Finding ID
WBSP-AS-001230
Rule ID
SV-96071r1_rule
Severity
Cat I
CCE
(None)
Group Title
SRG-APP-000176-AS-000125
CCI
CCI-000186
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server must use signer for DoD-issued certificates.

Finding ID
WBSP-AS-001260
Rule ID
SV-96075r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000177-AS-000126
CCI
CCI-000187
Target Key
(None)
Documentable
No
Discussion

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.

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".

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.

The WebSphere Application Server must utilize FIPS 140-2-approved encryption modules when authenticating users and processes.

Finding ID
WBSP-AS-001290
Rule ID
SV-96079r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000179-AS-000129
CCI
CCI-002450
Target Key
(None)
Documentable
No
Discussion

Encryption is only as good as the encryption modules utilized. Unapproved cryptographic module algorithms cannot be verified and cannot be relied upon to provide confidentiality or integrity, and DoD data may be compromised due to weak algorithms. The use of TLS provides confidentiality of data in transit between the application server and client. FIPS 140-2 approved TLS versions include TLS V1.0 or greater. TLS must be enabled and non-FIPS-approved SSL versions must be disabled. NIST SP 800-52 specifies the preferred configurations for government systems. Satisfies: SRG-APP-000179-AS-000129, SRG-APP-000440-AS-000167, SRG-APP-000442-AS-000259, SRG-APP-000439-AS-000155, SRG-APP-000224-AS-000152, SRG-APP-000514-AS-000136, SRG-APP-000416-AS-000140

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.

Check Content

From administrative console, click Security >> SSL certificate and key management >> Manage FIPS. If "Enable FIPS 140-2" is not selected, this is a finding.

The WebSphere Application Server must accept Personal Identity Verification (PIV) credentials from other federal agencies to access the management interface.

Finding ID
WBSP-AS-001300
Rule ID
SV-96081r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000402-AS-000247
CCI
CCI-002009
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server must use DoD-approved Signer Certificates.

Finding ID
WBSP-AS-001370
Rule ID
SV-96083r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000514-AS-000137
CCI
CCI-002450
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Servers must not be in the DMZ.

Finding ID
WBSP-AS-001390
Rule ID
SV-96085r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000211-AS-000146
CCI
CCI-001082
Target Key
(None)
Documentable
No
Discussion

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.

Fix Text

If any application server host is installed in the DMZ, reassign IP address to a secured network and reconfigure the application server.

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.

The WebSphere Application Server DoD root CAs must be in the trust store.

Finding ID
WBSP-AS-001410
Rule ID
SV-96087r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000219-AS-000147
CCI
CCI-001184
Target Key
(None)
Documentable
No
Discussion

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.

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".

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.

The WebSphere Application Server personal certificates in all keystores must be issued by an approved DoD CA.

Finding ID
WBSP-AS-001460
Rule ID
SV-96089r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000427-AS-000264
CCI
CCI-002470
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server must be configured to perform complete application deployments when using A/B clusters.

Finding ID
WBSP-AS-001470
Rule ID
SV-96091r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000225-AS-000153
CCI
CCI-001190
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application servers with an RMF categorization of high must be in a high-availability (HA) cluster.

Finding ID
WBSP-AS-001480
Rule ID
SV-96093r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000225-AS-000154
CCI
CCI-002385
Target Key
(None)
Documentable
No
Discussion

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

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.

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.

The WebSphere Application Server must not generate LTPA keys automatically.

Finding ID
WBSP-AS-001520
Rule ID
SV-96095r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000428-AS-000265
CCI
CCI-002475
Target Key
(None)
Documentable
No
Discussion

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.

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".

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.

The WebSphere Application Server must periodically regenerate LTPA keys.

Finding ID
WBSP-AS-001530
Rule ID
SV-96097r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000428-AS-000265
CCI
CCI-002475
Target Key
(None)
Documentable
No
Discussion

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

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.

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.

The WebSphere Application Server high availability applications must be installed on a cluster.

Finding ID
WBSP-AS-001570
Rule ID
SV-96099r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000435-AS-000163
CCI
CCI-002385
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server memory session settings must be defined according to application load requirements.

Finding ID
WBSP-AS-001580
Rule ID
SV-96101r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000435-AS-000163
CCI
CCI-002385
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server thread pool size must be defined according to application load requirements.

Finding ID
WBSP-AS-001590
Rule ID
SV-96103r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000435-AS-000163
CCI
CCI-002385
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server must remove all export ciphers to protect the confidentiality and integrity of transmitted information.

Finding ID
WBSP-AS-001610
Rule ID
SV-96105r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000439-AS-000274
CCI
CCI-002418
Target Key
(None)
Documentable
No
Discussion

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

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.

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.

The WebSphere Application Server distribution and consistency services (DCS) transport links must be encrypted.

Finding ID
WBSP-AS-001620
Rule ID
SV-96107r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000440-AS-000166
CCI
CCI-002420
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server plugin must be configured to use HTTPS only.

Finding ID
WBSP-AS-001630
Rule ID
SV-96109r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000440-AS-000167
CCI
CCI-002421
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server must remove organization-defined software components after updated versions have been installed.

Finding ID
WBSP-AS-001740
Rule ID
SV-96111r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000454-AS-000268
CCI
CCI-002617
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.

The WebSphere Application Server must apply the latest security fixes.

Finding ID
WBSP-AS-001750
Rule ID
SV-96113r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000456-AS-000266
CCI
CCI-002605
Target Key
(None)
Documentable
No
Discussion

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

Fix Text

Obtain WebSphere product security and patch support. Test and apply the latest applicable WebSphere security fixes.

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.

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).

Finding ID
WBSP-AS-001760
Rule ID
SV-96115r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000456-AS-000266
CCI
CCI-002605
Target Key
(None)
Documentable
No
Discussion

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.

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.

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.