Skip to content
ATO Pathways
Log In
Overview
Search
Catalogs
SCAP
OSCAL
Catalogs
Profiles
Documents
References
Knowledge Base
Platform Documentation
Compliance Dictionary
Platform Changelog
About
Catalogs
XCCDF
IBM WebSphere Traditional V9.x Security Technical Implementation Guide
IBM WebSphere Traditional V9.x Security Technical Implementation Guide
An XCCDF Benchmark
Details
Profiles
Items
Prose
76 rules organized in 76 groups
SRG-APP-000001-AS-000001
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server maximum in-memory session count must be set according to application requirements.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000295-AS-000263
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server admin console session timeout must be configured.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000016-AS-000013
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server automatic repository checkpoints must be enabled to track configuration changes.
Medium Severity
<VulnDiscussion>Without enabling repository checkpoints, you will not be able to determine the history of changes to WebSphere configuration files, and who made those changes.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000315-AS-000094
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server administrative security must be enabled.
High Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000315-AS-000095
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server bus security must be enabled.
High Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000016-AS-000013
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server security auditing must be enabled.
Medium Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000016-AS-000013
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server groups in the user registry mapped to WebSphere auditor roles must be configured in accordance with the security plan.
Medium Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000016-AS-000013
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server users in the WebSphere auditor role must be configured in accordance with the System Security Plan.
Medium Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000016-AS-000013
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server audit event type filters must be configured.
Medium Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000016-AS-000013
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server audit service provider must be enabled.
Medium Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000315-AS-000094
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server users in a local user registry group must be authorized for that group.
Medium Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000014-AS-000009
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server Quality of Protection (QoP) must be set to use TLSv1.2 or higher.
Medium Severity
<VulnDiscussion>Quality of Protection specifies the security level, ciphers, and mutual authentication settings for the Secure Socket Layer (SSL/TLS) configuration.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000014-AS-000009
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server global application security must be enabled.
High Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000014-AS-000009
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server Single Sign On (SSO) must have SSL enabled for Web and SIP Security.
High Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000015-AS-000010
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server security cookies must be set to HTTPOnly.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000033-AS-000024
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server Java 2 security must be enabled.
High Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000033-AS-000024
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server Java 2 security must not be bypassed.
High Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000033-AS-000024
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server users in the admin role must be authorized.
Medium Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000033-AS-000024
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server LDAP groups must be authorized for the WebSphere role.
Medium Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000340-AS-000185
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server users in a LDAP user registry group must be authorized for that group.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000068-AS-000035
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server management interface must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system.
Medium Severity
<VulnDiscussion>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."</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000069-AS-000036
1 Rule
<GroupDescription></GroupDescription>
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.
Medium Severity
<VulnDiscussion>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".</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000091-AS-000052
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must generate log records when successful/unsuccessful attempts to access subject privileges occur.
Low Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000357-AS-000038
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must allocate JVM log record storage capacity in accordance with organization-defined log record storage requirements.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000357-AS-000038
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must allocate audit log record storage capacity in accordance with organization-defined log record storage requirements.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000360-AS-000066
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must provide an immediate real-time alert to authorized users of all log failure events requiring real-time alerts.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000108-AS-000067
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must alert the SA and ISSO, at a minimum, in the event of a log processing failure.
Low Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000108-AS-000067
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server audit subsystem failure action must be set to Log warning.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000109-AS-000068
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must shut down by default upon log failure (unless availability is an overriding concern).
Low Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000109-AS-000070
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server high availability applications must be configured to fail over to another system in the event of log subsystem failure.
Low Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000118-AS-000078
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must be configured to protect log information from any type of unauthorized read access.
Low Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000119-AS-000079
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must protect log information from unauthorized modification.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000120-AS-000080
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must protect log information from unauthorized deletion.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000121-AS-000081
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server wsadmin file must be protected from unauthorized access.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000122-AS-000082
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server wsadmin file must be protected from unauthorized modification.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000123-AS-000083
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server wsadmin file must be protected from unauthorized deletion.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000126-AS-000085
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must be configured to encrypt log information.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000126-AS-000085
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must be configured to sign log information.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000141-AS-000095
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server process must not be started from the command line with the -password option.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000141-AS-000095
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server files must be owned by the non-root WebSphere user ID.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000141-AS-000095
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server sample applications must be removed.
Low Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000141-AS-000095
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must remove JREs left by web server and plug-in installers for web servers and plugins running in the DMZ.
Low Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000141-AS-000095
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must be run as a non-admin user.
Medium Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000141-AS-000095
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must disable JSP class reloading.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000142-AS-000014
1 Rule
<GroupDescription></GroupDescription>
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.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000148-AS-000101
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server LDAP user registry must be used.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000148-AS-000101
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server local file-based user registry must not be used.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000149-AS-000102
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server multifactor authentication for network access to privileged accounts must be used.
Medium Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000156-AS-000106
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must provide security extensions to extend the SOAP protocol and provide secure authentication when accessing sensitive data.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000156-AS-000106
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must provide security extensions to extend the SOAP protocol and provide secure authentication when accessing sensitive data.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000394-AS-000241
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must authenticate all network-connected endpoint devices before establishing any connection.
Medium Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000395-AS-000109
1 Rule
<GroupDescription></GroupDescription>
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.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000172-AS-000120
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server application security must be enabled for each security domain except for publicly available applications specified in the System Security Plan.
High Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000172-AS-000121
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server secure LDAP (LDAPS) must be used for authentication.
High Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000400-AS-000246
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must prohibit the use of cached authenticators after an organization-defined time period.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000176-AS-000125
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server default keystore passwords must be changed.
High Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000177-AS-000126
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must use signer for DoD-issued certificates.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000179-AS-000129
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must utilize FIPS 140-2-approved encryption modules when authenticating users and processes.
Medium Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000402-AS-000247
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must accept Personal Identity Verification (PIV) credentials from other federal agencies to access the management interface.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000514-AS-000137
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must use DoD-approved Signer Certificates.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000211-AS-000146
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Servers must not be in the DMZ.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000219-AS-000147
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server DoD root CAs must be in the trust store.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000427-AS-000264
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server personal certificates in all keystores must be issued by an approved DoD CA.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000225-AS-000153
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must be configured to perform complete application deployments when using A/B clusters.
Low Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000225-AS-000154
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application servers with an RMF categorization of high must be in a high-availability (HA) cluster.
Low Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000428-AS-000265
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must not generate LTPA keys automatically.
Low Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000428-AS-000265
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must periodically regenerate LTPA keys.
Low Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000435-AS-000163
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server high availability applications must be installed on a cluster.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000435-AS-000163
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server memory session settings must be defined according to application load requirements.
Low Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000435-AS-000163
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server thread pool size must be defined according to application load requirements.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000439-AS-000274
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must remove all export ciphers to protect the confidentiality and integrity of transmitted information.
Medium Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000440-AS-000166
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server distribution and consistency services (DCS) transport links must be encrypted.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000440-AS-000167
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server plugin must be configured to use HTTPS only.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000454-AS-000268
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must remove organization-defined software components after updated versions have been installed.
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000456-AS-000266
1 Rule
<GroupDescription></GroupDescription>
The WebSphere Application Server must apply the latest security fixes.
Medium Severity
<VulnDiscussion>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</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>
SRG-APP-000456-AS-000266
1 Rule
<GroupDescription></GroupDescription>
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).
Medium Severity
<VulnDiscussion>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.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>