IBM WebSphere Traditional V9.x Security Technical Implementation Guide

Version

WBSP-AS-000070

Vuln IDs

V-255820
V-81203

Rule IDs

SV-255820r960765_rule
SV-95917

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

Checks: C-59493r876749_chk

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

Fix: F-59436r876750_fix

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

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

AC-17 - Medium - CCI-000067 - V-255821 - SV-255821r960765_rule

RMF Control

AC-17

Severity

CCI

Version

WBSP-AS-000080

Vuln IDs

V-255821
V-81205

Rule IDs

SV-255821r960765_rule
SV-95919

Checks: C-59494r876752_chk

Review System Security Plan documentation. Identify groups and roles. In the administrative console, navigate to Users and Groups >> Administrative Group Roles. Check the roles for each group and compare to System Security Plan. If any group is not authorized by the ISSO/ISSM to be in an auditor role, this is a finding.

Fix: F-59437r876753_fix

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.

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

AC-17 - Medium - CCI-000067 - V-255822 - SV-255822r960765_rule

RMF Control

AC-17

Severity

CCI

Version

WBSP-AS-000090

Vuln IDs

V-255822
V-81207

Rule IDs

SV-255822r960765_rule
SV-95921

Checks: C-59495r876755_chk

Review System Security Plan documentation. Identify users and roles. In the administrative console, navigate to Users and Groups >> Administrative User Roles. Check the roles for each user. If any user is not authorized by the ISSO/ISSM to be in the role of an auditor, this is a finding.

Fix: F-59438r876756_fix

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.

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

AC-17 - Medium - CCI-000067 - V-255823 - SV-255823r960765_rule

RMF Control

AC-17

Severity

CCI

Version

WBSP-AS-000100

Vuln IDs

V-255823
V-81209

Rule IDs

SV-255823r960765_rule
SV-95923

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

Checks: C-59496r876758_chk

In the administrative console, navigate to Security >> Security auditing >> Event type Filters. Verify the following events and outcomes are enabled in the "Events and Outcomes" box. Also note the name of the filter associated with these events. This name will be referenced in STIG ID WBSP-AS-000110. AUTHN: SUCCESS,INFO,WARNING,ERROR,DENIED,REDIRECT AUTHZ: SUCCESS,INFO,WARNING,ERROR,DENIED,REDIRECT AUTHN_TERMINATE: SUCCESS,INFO,WARNING,ERROR,DENIED,REDIRECT REPOSITORY_SAVE: SUCCESS,INFO,WARNING,ERROR,DENIED,REDIRECT If these audit filters are not configured in "Events and Outcomes", this is a finding.

Fix: F-59439r876759_fix

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.

The WebSphere Application Server audit service provider must be enabled.

AC-17 - Medium - CCI-000067 - V-255824 - SV-255824r960765_rule

RMF Control

AC-17

Severity

CCI

Version

WBSP-AS-000110

Vuln IDs

V-255824
V-81211

Rule IDs

SV-255824r960765_rule
SV-95925

Checks: C-59497r876761_chk

In the administrative console, navigate to Security >> Security auditing >> Audit Service Provider [provider name]. Under "Enabled filters", determine if the filter name from select the name of the filter that was recorded from STIG ID WBSP-AS-000100. If the filter that was identified in STIG ID WBSP-AS-000100 is not enabled, this is a finding.

Fix: F-59440r876762_fix

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.

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

AC-17 - Medium - CCI-000067 - V-255825 - SV-255825r960765_rule

RMF Control

AC-17

Severity

CCI

Version

WBSP-AS-000120

Vuln IDs

V-255825
V-81197

Rule IDs

SV-255825r960765_rule
SV-95911

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

Checks: C-59498r876764_chk

Review System Security Plan documentation. Identify the required "Automatic CheckPoint Depth" setting that has been defined. From administrative console, click System administration >> Extended repository service. If "Enable automatic repository checkpoints" is not selected or if the "automatic checkpoint depth" is less than the number of saves defined in the System Security Plan, this is a finding.

Fix: F-59441r876765_fix

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.

The WebSphere Application Server administrative security must be enabled.

AC-17 - High - CCI-002314 - V-255826 - SV-255826r961278_rule

RMF Control

AC-17

Severity

CCI

CCI-002314

Version

WBSP-AS-000130

Vuln IDs

V-255826
V-81199

Rule IDs

SV-255826r961278_rule
SV-95913

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.

Checks: C-59499r876767_chk

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

Fix: F-59442r876768_fix

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

The WebSphere Application Server bus security must be enabled.

AC-17 - High - CCI-002315 - V-255827 - SV-255827r961863_rule

RMF Control

AC-17

Severity

CCI

CCI-002315

Version

WBSP-AS-000140

Vuln IDs

V-255827
V-81201

Rule IDs

SV-255827r961863_rule
SV-95915

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.

Checks: C-59500r876770_chk

Review System Security Plan documentation. Interview the system administrator. Identify the service integration buses configured on the WAS. If there are no service integration buses, this requirement is NA. From the administration console, navigate to Security >> Bus Security. For each service integration bus, if security is not enabled, this is a finding.

Fix: F-59443r876771_fix

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.

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

AC-3 - Medium - CCI-000213 - V-255828 - SV-255828r961278_rule

RMF Control

AC-3

Severity

CCI

Version

WBSP-AS-000150

Vuln IDs

V-255828
V-81213

Rule IDs

SV-255828r961278_rule
SV-95927

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

Checks: C-59501r876773_chk

If the systems user registry is managed by LDAP, this requirement is NA. Review the System Security Plan documentation. Interview the system administrator. Obtain a list of authorized users. In the administrative console, navigate to Users and Groups >> Manage Groups. Select each group. Select the "Members" tab. Validate the members of the group are authorized. If users in the group are not authorized by the ISSO/ISSM, this is a finding.

Fix: F-59444r876774_fix

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.

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

AC-17 - Medium - CCI-000068 - V-255829 - SV-255829r960759_rule

RMF Control

AC-17

Severity

CCI

CCI-000068

Version

WBSP-AS-000160

Vuln IDs

V-255829
V-81215

Rule IDs

SV-255829r960759_rule
SV-95929

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

Checks: C-59502r876776_chk

From the administrative console, navigate to Security >> SSL certificate and key management. Click "SSL configurations". Click on each SSL configuration to review. Under "Additional Properties", click "Quality of protection (QoP)" settings. If the "Protocol" field does not show "TLSv1.2 or greater", this is a finding.

Fix: F-59445r876777_fix

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.

The WebSphere Application Server global application security must be enabled.

AC-17 - High - CCI-000068 - V-255830 - SV-255830r960759_rule

RMF Control

AC-17

Severity

CCI

CCI-000068

Version

WBSP-AS-000170

Vuln IDs

V-255830
V-81217

Rule IDs

SV-255830r960759_rule
SV-95931

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

Checks: C-59503r876779_chk

From the administrative console, navigate to Security >> Global Security. If "Enable administrative security" and "Enable application security" are not selected, this is a finding.

Fix: F-59446r876780_fix

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.

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

AC-17 - High - CCI-000068 - V-255831 - SV-255831r960759_rule

RMF Control

AC-17

Severity

CCI

CCI-000068

Version

WBSP-AS-000180

Vuln IDs

V-255831
V-81219

Rule IDs

SV-255831r960759_rule
SV-95933

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

Checks: C-59504r876782_chk

From the administrative console, navigate to Security >> Global Security. Expand "Web and SIP security". Click on "Single sign-on (SSO)". If "requires SSL" is not selected, this is a finding.

Fix: F-59447r876783_fix

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.

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

AC-17 - Medium - CCI-001453 - V-255832 - SV-255832r960762_rule

RMF Control

AC-17

Severity

CCI

CCI-001453

Version

WBSP-AS-000190

Vuln IDs

V-255832
V-81221

Rule IDs

SV-255832r960762_rule
SV-95935

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.

Checks: C-59505r876785_chk

From the administrative console, navigate to Security >> Global Security. Expand "Web and SIP security". Click on "Single sign-on (SSO)". If "Set security cookies to HTTPOnly" is not selected, this is a finding.

Fix: F-59448r876786_fix

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.

The WebSphere Application Server Java 2 security must be enabled.

AC-3 - High - CCI-000213 - V-255833 - SV-255833r1137578_rule

RMF Control

AC-3

Severity

CCI

Version

WBSP-AS-000211

Vuln IDs

V-255833
V-81223

Rule IDs

SV-255833r1137578_rule
SV-95937

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.

Checks: C-59506r876788_chk

From the admin console, select Security >> Global Security >> Java 2 Security. If "Use Java 2 security to restrict application access to local resources" is not selected, this is a finding.

Fix: F-59449r876789_fix

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.

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

AC-3 - High - CCI-000213 - V-255834 - SV-255834r1137578_rule

RMF Control

AC-3

Severity

CCI

Version

WBSP-AS-000212

Vuln IDs

V-255834
V-81225

Rule IDs

SV-255834r1137578_rule
SV-95939

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.

Checks: C-59507r876791_chk

If the system is a development or test system, this requirement is NA. From the admin console, select Servers >> Server Types >> WebSphere application servers. For each application server, select Server Infrastructure >> Administration >> Custom properties. If the "com.ibm.websphere.java2secman.norethrow" resource value exists and is set to "true", this is a finding.

Fix: F-59450r876792_fix

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.

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

AC-3 - Medium - CCI-000213 - V-255835 - SV-255835r1137578_rule

RMF Control

AC-3

Severity

CCI

Version

WBSP-AS-000220

Vuln IDs

V-255835
V-81227

Rule IDs

SV-255835r1137578_rule
SV-95941

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

Checks: C-59508r876794_chk

Review System Security Plan documentation. In the administrative console, navigate to Users and Groups >> Administrative user roles. If users assigned to the admin role are not authorized by the ISSO/ISSM, this is a finding.

Fix: F-59451r876795_fix

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.

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

AC-3 - Medium - CCI-000213 - V-255836 - SV-255836r1137578_rule

RMF Control

AC-3

Severity

CCI

Version

WBSP-AS-000230

Vuln IDs

V-255836
V-81229

Rule IDs

SV-255836r1137578_rule
SV-95943

Checks: C-59509r876797_chk

Review System Security Plan documentation. Review details regarding LDAP groups that are mapped to WebSphere roles. In the administrative console, under Users and Groups >> Administrative group roles. If there is a LDAP group or groups assigned to a WebSphere role that has not been authorized by the ISSO/ISSM, this is a finding.

Fix: F-59452r876798_fix

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.

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

AC-6 - Medium - CCI-002235 - V-255837 - SV-255837r961353_rule

RMF Control

AC-6

Severity

CCI

CCI-002235

Version

WBSP-AS-000240

Vuln IDs

V-255837
V-81231

Rule IDs

SV-255837r961353_rule
SV-95945

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.

Checks: C-59510r876800_chk

If a file based or local federated repository is in use, this requirement is NA. Review System Security Plan documentation. Interview the system administrator. In the administrative console select Security >> Global Security. Under "User Account Repository", verify the "Available realm Definition" is set to "Standalone LDAP registry". Select "Configure". The properties of the LDAP repository are displayed for purposes of identifying the LDAP server. Work with the admin of LDAP repository. Identify users and groups. Validate members of groups are authorized. If the group members have not been authorized by the ISSO/ISSM, this is a finding.

Fix: F-59453r876801_fix

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

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

AC-8 - Medium - CCI-000048 - V-255838 - SV-255838r960843_rule

RMF Control

AC-8

Severity

CCI

CCI-000048

Version

WBSP-AS-000310

Vuln IDs

V-255838
V-81233

Rule IDs

SV-255838r960843_rule
SV-95947

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

Checks: C-59511r876803_chk

Point browser to the URL of the WebSphere administration console. If the Standard Mandatory DoD Notice and Consent Banner is not displayed, this is a finding.

Fix: F-59454r876804_fix

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.

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.

AC-8 - Medium - CCI-000050 - V-255839 - SV-255839r960846_rule

RMF Control

AC-8

Severity

CCI

CCI-000050

Version

WBSP-AS-000320

Vuln IDs

V-255839
V-81235

Rule IDs

SV-255839r960846_rule
SV-95949

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

Checks: C-59512r876806_chk

Point browser to the URL of the WebSphere administration console. If the Standard Mandatory DoD Notice and Consent Banner is not retained until the user acknowledges the usage conditions, this is a finding.

Fix: F-59455r876807_fix

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

AU-12 - Low - CCI-000172 - V-255840 - SV-255840r960885_rule

RMF Control

AU-12

Severity

CCI

CCI-000172

Version

WBSP-AS-000380

Vuln IDs

V-255840
V-81237

Rule IDs

SV-255840r960885_rule
SV-95951

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.

Checks: C-59513r876809_chk

In the administrative console, navigate to Security >> Security auditing >> Audit Service Provider. Click on the providers in the list. Note: names of all the filters, e.g., "DefaultAuditSpecification_1". Go back to Security >> Security auditing >> Event type Filters. Find the filters previously noted. If you do not see the filter for SECURITY_AUTHN, SECURITY_AUTHZ, SECURITY_AUTHN_TERMINATE, and ADMIN_REPOSITORY_SAVE that has INFO, ERROR, SUCCESS, DENIED, REDIRECT, and WARNING defined, this is a finding.

Fix: F-59456r876810_fix

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.

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

AU-4 - Medium - CCI-001849 - V-255841 - SV-255841r961392_rule

RMF Control

AU-4

Severity

CCI

CCI-001849

Version

WBSP-AS-000580

Vuln IDs

V-255841
V-81239

Rule IDs

SV-255841r961392_rule
SV-95953

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.

Checks: C-59514r876812_chk

Review System Security Plan documentation. Identify the JVM log size and rotation settings based on component log policy. From the administrative console, navigate to Troubleshooting >> Logs and Trace. Choose [server name]. Click on the server name to select it. Click "JVM" Logs. For "System.out" verify "File Size" is selected and "Maximum size" and "Maximum Historical Log Files" are set according to the System Security Plan. For "System.err" verify "File Size" is selected and "Maximum size" and "Maximum Historical Log Files" are set according to the System Security Plan. If log size and log history retention settings for "System.err" and "System.out" are not set as per the System Security Plan, this is a finding.

Fix: F-59457r876813_fix

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

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

AU-4 - Medium - CCI-001849 - V-255842 - SV-255842r961392_rule

RMF Control

AU-4

Severity

CCI

CCI-001849

Version

WBSP-AS-000590

Vuln IDs

V-255842
V-81241

Rule IDs

SV-255842r961392_rule
SV-95955

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.

Checks: C-59515r876815_chk

Review System Security Plan documentation. Identify the Audit Service Provider log size and rotation settings based on component log policy. From administrative console, click Security >> Security auditing >> Audit service provider. Select each [audit_service_provider_name]. If "Audit Log Size" and "Max Number of Audit Log Files" are not configured as per the System Security Plan, this is a finding.

Fix: F-59458r876816_fix

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

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

AU-5 - Medium - CCI-001858 - V-255843 - SV-255843r961401_rule

RMF Control

AU-5

Severity

CCI

CCI-001858

Version

WBSP-AS-000630

Vuln IDs

V-255843
V-81243

Rule IDs

SV-255843r961401_rule
SV-95957

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.

Checks: C-59516r876818_chk

If notifications of log processing failures are done via an alternative notification process, this is not a finding. In the administrative console, navigate to Security >> Security auditing >> Audit monitor. If "Enabled monitoring" is not checked and "Monitor notification" is not set to a name in the notifications list, this is a finding.

Fix: F-59459r876819_fix

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

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

AU-5 - Low - CCI-000139 - V-255844 - SV-255844r960912_rule

RMF Control

AU-5

Severity

CCI

CCI-000139

Version

WBSP-AS-000640

Vuln IDs

V-255844
V-81245

Rule IDs

SV-255844r960912_rule
SV-95959

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.

Checks: C-59517r876821_chk

If the SA and ISSO are notified of log processing failures via an alternative notification process, this is not a finding. In the administrative console, navigate to Security >> Security auditing >> Audit monitor. If "Enabled monitoring" is not checked and "Monitor notification" is not set to a notification in the notifications list, that includes the SA and ISSO, this is a finding.

Fix: F-59460r876822_fix

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

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

AU-5 - Medium - CCI-000139 - V-255845 - SV-255845r960912_rule

RMF Control

AU-5

Severity

CCI

CCI-000139

Version

WBSP-AS-000650

Vuln IDs

V-255845
V-81247

Rule IDs

SV-255845r960912_rule
SV-95961

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.

Checks: C-59518r876824_chk

In the administrative console, navigate to Security >> Security auditing. If "Audit subsystem failure action" is not set to "Log Warning", this is a finding.

Fix: F-59461r876825_fix

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.

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

AU-5 - Low - CCI-000140 - V-255846 - SV-255846r1043188_rule

RMF Control

AU-5

Severity

CCI

CCI-000140

Version

WBSP-AS-000660

Vuln IDs

V-255846
V-81249

Rule IDs

SV-255846r1043188_rule
SV-95963

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.

Checks: C-59519r876827_chk

If the System Security Plan documentation specifies system availability is an overriding concern, this requirement is NA. In the admin console click Security >> Security Auditing. If "Audit subsystem failure action" is not set to "Terminate", this is a finding.

Fix: F-59462r876828_fix

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

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

AU-5 - Low - CCI-000140 - V-255847 - SV-255847r1043188_rule

RMF Control

AU-5

Severity

CCI

CCI-000140

Version

WBSP-AS-000670

Vuln IDs

V-255847
V-81251

Rule IDs

SV-255847r1043188_rule
SV-95965

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.

Checks: C-59520r876830_chk

If the System Security Plan documentation does not require redundancy, this requirement is NA. Click Servers >> Clusters >> WebSphere application server clusters. Ensure you have a cluster defined for every application requiring redundancy. If there is not a cluster defined for every application requiring redundancy, this is a finding.

Fix: F-59463r876831_fix

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.

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

AU-9 - Low - CCI-000162 - V-255848 - SV-255848r960930_rule

RMF Control

AU-9

Severity

CCI

CCI-000162

Version

WBSP-AS-000740

Vuln IDs

V-255848
V-81253

Rule IDs

SV-255848r960930_rule
SV-95967

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.

Checks: C-59521r876833_chk

Review system documentation and System Security Plan. Identify the home folder and user account for the WebSphere installation. Log on to the operating system that is hosting the WebSphere application server. By default, WebSphere will be installed in the "/opt/IBM/Websphere" folder on UNIX like systems and in the "C:\Program Files\IBM\Websphere\" folder on Windows systems. On UNIX systems, verify file permissions for the "WebSphere" folder are set to "770" for the WebSphere user, group, and other. Permissions do not propagate to sub-folders. On Windows systems, verify file permissions for "WebSphere" folder allow SYSTEM, WebSphere User and Admin Group full control. Permissions do not propagate to sub-folders. If file permissions exceed these restrictions, this is a finding.

Fix: F-59464r876834_fix

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.

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

AU-9 - Medium - CCI-000163 - V-255849 - SV-255849r960933_rule

RMF Control

AU-9

Severity

CCI

CCI-000163

Version

WBSP-AS-000750

Vuln IDs

V-255849
V-81255

Rule IDs

SV-255849r960933_rule
SV-95969

Checks: C-59522r876836_chk

Review System Security Plan and the system documentation. Identify the home folder and user account for the WebSphere installation. Log on to the operating system that is hosting the WebSphere application server. By default, WebSphere will be installed in the "/opt/IBM/Websphere" folder on UNIX like systems and in the "C:\Program Files\IBM\Websphere\" folder on Windows systems. On UNIX systems, verify file permissions for the "WebSphere" folder are set to "770" for the WebSphere user, group and other. Permissions do not propagate to sub-folders. On Windows systems, verify file permissions for "WebSphere" folder allow SYSTEM, WebSphere User, and Admin Group full control. Permissions do not propagate to sub-folders. If file permissions exceed these restrictions, this is a finding.

Fix: F-59465r876837_fix

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.

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

AU-9 - Medium - CCI-000164 - V-255850 - SV-255850r960936_rule

RMF Control

AU-9

Severity

CCI

CCI-000164

Version

WBSP-AS-000760

Vuln IDs

V-255850
V-81257

Rule IDs

SV-255850r960936_rule
SV-95971

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.

Checks: C-59523r876839_chk

Review System Security Plan and the system documentation. Identify the home folder and user account for the WebSphere installation. Log on to the operating system that is hosting the WebSphere application server. By default, WebSphere will be installed in the "/opt/IBM/Websphere" folder on UNIX like systems and in the "C:\Program Files\IBM\Websphere\" folder on Windows systems. On UNIX systems, verify file permissions for the "WebSphere" folder are set to "770" for the WebSphere user, group, and other. Permissions do not propagate to sub-folders. On Windows systems, verify file permissions for "WebSphere" folder allow SYSTEM, WebSphere User and Admin Group full control. Permissions do not propagate to sub-folders. If file permissions exceed these restrictions, this is a finding.

Fix: F-59466r876840_fix

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.

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

AU-9 - Medium - CCI-001493 - V-255851 - SV-255851r960939_rule

RMF Control

AU-9

Severity

CCI

CCI-001493

Version

WBSP-AS-000770

Vuln IDs

V-255851
V-81259

Rule IDs

SV-255851r960939_rule
SV-95973

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.

Checks: C-59524r876842_chk

Review System Security Plan and the system documentation. Identify the home folder and user account for the WebSphere installation. Log on to the operating system that is hosting the WebSphere application server. By default, WebSphere will be installed in the "/opt/IBM/Websphere" folder on UNIX like systems and in the "C:\Program Files\IBM\Websphere\" folder on Windows systems. On UNIX systems, verify file permissions for the "WebSphere" folder are set to "770" for the WebSphere user, group, and other. Permissions do not propagate to sub-folders. On Windows systems, verify file permissions for "WebSphere" folder allow SYSTEM, WebSphere User, and Admin Group full control. Permissions do not propagate to sub-folders. If file permissions exceed these restrictions, this is a finding.

Fix: F-59467r876843_fix

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.

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

AU-9 - Medium - CCI-001494 - V-255852 - SV-255852r960942_rule

RMF Control

AU-9

Severity

CCI

CCI-001494

Version

WBSP-AS-000780

Vuln IDs

V-255852
V-81261

Rule IDs

SV-255852r960942_rule
SV-95975

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.

Checks: C-59525r876845_chk

Review System Security Plan and the system documentation. Identify the home folder and user account for the WebSphere installation. Log on to the operating system that is hosting the WebSphere application server. By default, WebSphere will be installed in the "/opt/IBM/Websphere" folder on UNIX like systems and in the "C:\Program Files\IBM\Websphere\" folder on Windows systems. On UNIX systems, verify file permissions for the "WebSphere" folder are set to "770" for the WebSphere user, group, and other. Permissions do not propagate to sub-folders. On Windows systems, verify file permissions for "WebSphere" folder allow SYSTEM, WebSphere User, and Admin Group full control. Permissions do not propagate to sub-folders. If file permissions exceed these restrictions, this is a finding.

Fix: F-59468r876846_fix

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.

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

AU-9 - Medium - CCI-001495 - V-255853 - SV-255853r960945_rule

RMF Control

AU-9

Severity

CCI

CCI-001495

Version

WBSP-AS-000790

Vuln IDs

V-255853
V-81263

Rule IDs

SV-255853r960945_rule
SV-95977

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.

Checks: C-59526r876848_chk

Review system documentation and security plan. Identify the home folder and user account for the WebSphere installation. Log on to the operating system that is hosting the WebSphere application server. By default, WebSphere will be installed in the "/opt/IBM/Websphere" folder on UNIX like systems and in the "C:\Program Files\IBM\Websphere\" folder on Windows systems. On UNIX systems, verify file permissions for the "WebSphere" folder are set to "770" for the WebSphere user, group, and other. Permissions do not propagate to sub-folders. On Windows systems, verify file permissions for WebSphere folder allow SYSTEM, WebSphere User, and Admin Group full control. Permissions do not propagate to sub-folders. If file permissions exceed these restrictions, this is a finding.

Fix: F-59469r876849_fix

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.

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

AU-9 - Medium - CCI-001350 - V-255854 - SV-255854r960951_rule

RMF Control

AU-9

Severity

CCI

CCI-001350

Version

WBSP-AS-000810

Vuln IDs

V-255854
V-81265

Rule IDs

SV-255854r960951_rule
SV-95979

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.

Checks: C-59527r876851_chk

Review System Security Plan documentation. If the System Security Plan does not specify the encryption of audit records, this requirement is NA. From the administrative console, click Security >> Security Auditing >> Audit record encryption configuration. If the "Enable encryption" check box is not selected, this is a finding.

Fix: F-59470r876852_fix

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.

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

AU-9 - Medium - CCI-001350 - V-255855 - SV-255855r960951_rule

RMF Control

AU-9

Severity

CCI

CCI-001350

Version

WBSP-AS-000820

Vuln IDs

V-255855
V-81267

Rule IDs

SV-255855r960951_rule
SV-95981

Checks: C-59528r876854_chk

From the administrative console, click Security >> Security Auditing >> Audit record signing configuration. If the "Enable signing" checkbox is not selected, this is a finding.

Fix: F-59471r876855_fix

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.

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

CM-7 - Medium - CCI-000381 - V-255856 - SV-255856r960963_rule

RMF Control

CM-7

Severity

CCI

Version

WBSP-AS-000910

Vuln IDs

V-255856
V-81269

Rule IDs

SV-255856r960963_rule
SV-95983

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.

Checks: C-59529r876857_chk

Review System Security Plan documentation. Interview the system administrator. Access operating system to list commands currently running. For UNIX: run "ps -ef | grep -i wsadmin.sh" For windows: from a DOS prompt as admin user run "WMIC path win32_process where "caption='wsadmin.exe'" get CommandLine" If the results show "wsadmin.sh(exe) -user <username> -password <password>", this is a finding.

Fix: F-59472r876858_fix

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

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

CM-7 - Medium - CCI-000381 - V-255857 - SV-255857r960963_rule

RMF Control

CM-7

Severity

CCI

Version

WBSP-AS-000920

Vuln IDs

V-255857
V-81271

Rule IDs

SV-255857r960963_rule
SV-95985

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.

Checks: C-59530r876860_chk

Review System Security Plan documentation. Interview the system administrator. Determine the OS user and group information associated with the WebSphere processes. Identify the paths, files, and folders associated with the WebSphere installation. These include: - <WAS_HOME>: where you installed WebSphere. <WAS_HOME> default location: For UNIX: /opt/IBM/WebSphere/AppServer For Windows: C:\Program Files\IBM\WebSphere\AppServer - <PROFILE_HOME>: where the appserver instance resides. The default location is under "<WAS_HOME>/profiles". - <OTHER_HOME>: any additional files that may reside outside of <WAS_HOME>. Examples include: - shared library .jar files - Resource Adapter .rar files - Key and trust store files (.jks and .p12) - Other files such as jdbc drivers For Linux, use the command "find <directory> -user root" to find files owned by root user. On windows use the "dir /Q /S" command from the root directories to show the owners of all files. Examine the output for files owned by the administrator or root account. If any WebSphere file or additional files as described above are owned by root or the administrator, this is a finding.

Fix: F-59473r876861_fix

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>

The WebSphere Application Server sample applications must be removed.

CM-7 - Low - CCI-000381 - V-255858 - SV-255858r960963_rule

RMF Control

CM-7

Severity

CCI

Version

WBSP-AS-000930

Vuln IDs

V-255858
V-81273

Rule IDs

SV-255858r960963_rule
SV-95987

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.

Checks: C-59531r876863_chk

Navigate to Applications >> All Applications. Review all applications installed on the application server. If the sample applications snoop, ivt, or DefaultApplication are installed on a production system, this is a finding.

Fix: F-59474r876864_fix

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

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

CM-7 - Low - CCI-000381 - V-255859 - SV-255859r960963_rule

RMF Control

CM-7

Severity

CCI

Version

WBSP-AS-000940

Vuln IDs

V-255859
V-81275

Rule IDs

SV-255859r960963_rule
SV-95989

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.

Checks: C-59532r876866_chk

This check needs to be run on the web server operating in the DMZ. Review system documentation. Identify web servers operating in DMZ. If there are no web servers configured for the DMZ, this is not applicable. From the administrative console, select Server Types >> Web Servers. Select each web server operating in the DMZ. Identify the "Web server installation location". Open a secured command shell to the web server in the DMZ. Change directory to the web server installation location. CD to the /plugins folder. If a /java directory exists in the plugins folder, this is a finding.

Fix: F-59475r876867_fix

For web servers provided with the WebSphere installation that are operating in the DMZ. Remove the /java directory from within the plugins folder.

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

CM-7 - Medium - CCI-000381 - V-255860 - SV-255860r960963_rule

RMF Control

CM-7

Severity

CCI

Version

WBSP-AS-000960

Vuln IDs

V-255860
V-81277

Rule IDs

SV-255860r960963_rule
SV-95991

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

Checks: C-59533r876869_chk

Interview systems manager. Identify the OS user ID that the WAS server runs as. Using relevant OS commands review OS processes and search for WAS processes (running as Java). Ensure they are running under the assigned non-administrative user id. For UNIX: "ps -ef|grep -i websphere" For Windows: "wmic path win32_process where "caption = 'java.exe'" get CommandLine If the WebSphere processes are running as the root or administrator user, this is a finding.

Fix: F-59476r876870_fix

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.

The WebSphere Application Server must disable JSP class reloading.

CM-7 - Medium - CCI-000381 - V-255861 - SV-255861r960963_rule

RMF Control

CM-7

Severity

CCI