{"stig":{"title":"IBM WebSphere Traditional V9.x Security Technical Implementation Guide","version":"2","release":"1"},"checks":[{"vulnId":"V-255818","ruleId":"SV-255818r960735_rule","severity":"medium","ruleTitle":"The WebSphere Application Server maximum in-memory session count must be set according to application requirements.","description":"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.\n\nApplication servers host and expose business logic and application processes.\n\nThe 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.\n\nAlthough 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.\n\nWhile the DoD will specify recommended values, the values can be adjusted to accommodate the operational requirement of a given system.","checkContent":"Review system documentation.\n\nIdentify the application session requirements.\n\nIn the administrative console page, click Servers >> Server Types >> WebSphere application servers >> [server_name] >> Session management.\n\nEnsure the Maximum in-memory session count field is set to the number of sessions allowable.\n\nIf not set according to application requirements, this is a finding.","fixText":"In the administrative console page, click Servers >> Server Types >> WebSphere application servers >> [server_name] >> Session management.\n\nEdit the Maximum in-memory session count field to be the number of sessions allowable.","ccis":["CCI-000054"]},{"vulnId":"V-255819","ruleId":"SV-255819r1043182_rule","severity":"medium","ruleTitle":"The WebSphere Application Server admin console session timeout must be configured.","description":"An attacker can take advantage of user sessions that are left open, thus bypassing the user authentication process.\n\nTo 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.\n\nSession 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.\n\nConditions 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.","checkContent":"Review System Security Plan and system configuration documentation.\n\nAccess the Deployment Manager (DMGR) operating system.\n\nLocate the deployment.xml file. The default file location where deployment.xml is installed are provided below. \n\nUNIX:\n/opt/IBM/WebSphere/Profiles/DefaultDmgr01/config/cells//applications/isclite.ear/deployments/isclite/\n\nWindows:\nC:\\Program Files\\IBM\\WebSphere\\Profiles\\DefaultDmgr01\\config\\cells\\\\applications\\isclite.ear\\deployments\\isclite\\\n\nSearch the deployment.xml file for the string, \"invalidationtimeout=\"\n\nUNIX:\ngrep -i invalidationtimeout $PATH/deployment.xml\n\nWindows:\nfindstr -I invalidationtimeout= $PATH\\deployment.xml\n\nThe value is expressed in minutes and the default value is set to \"30 minutes\". \n\nIf \"invalidationtimeout\" is not set to \"10 minutes\", this is a finding.","fixText":"Locate the deployment.xml file. The default file locations where deployment.xml is installed are provided below. \n\nUNIX:\n/opt/IBM/WebSphere/Profiles/DefaultDmgr01/config/cells//applications/isclite.ear/deployments/isclite/\n\nWindows:\nC:\\Program Files\\IBM\\WebSphere\\Profiles\\DefaultDmgr01\\config\\cells\\\\applications\\isclite.ear\\deployments\\isclite\\\n\nMake a backup copy of the deployment.xml file.\n\nEdit the deployment.xml file.\n\nModify the \"invalidationtimeout=\" value and set to \"10\".\n\nRestart the DMGR and all the JVMs.","ccis":["CCI-002361"]},{"vulnId":"V-255820","ruleId":"SV-255820r960765_rule","severity":"medium","ruleTitle":"The WebSphere Application Server security auditing must be enabled.","description":"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.\n\nSatisfies: 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","checkContent":"In the administrative console, navigate to Security >> Security auditing.\n\nIf \"Enable security auditing\" is not enabled, this is a finding.","fixText":"In the administrative console, navigate to Security >> Security auditing to enable.\n\nRestart the DMGR and all the JVMs.","ccis":["CCI-000067","CCI-000166","CCI-001312","CCI-001314","CCI-001464","CCI-002234"]},{"vulnId":"V-255821","ruleId":"SV-255821r960765_rule","severity":"medium","ruleTitle":"The WebSphere Application Server groups in the user registry mapped to WebSphere auditor roles must be configured in accordance with the security plan.","description":"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.\n\nRemote access by administrators requires that the admin activity be logged.\n\nApplication 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.\n\nSatisfies: SRG-APP-000016-AS-000013, SRG-APP-000343-AS-000030","checkContent":"Review System Security Plan documentation.\n\nIdentify groups and roles.\n\nIn the administrative console, navigate to Users and Groups >> Administrative Group Roles.\n\nCheck the roles for each group and compare to System Security Plan.\n\nIf any group is not authorized by the ISSO/ISSM to be in an auditor role, this is a finding.","fixText":"Document all groups in an Auditor role in the security plan.\n\nIn the administrative console, navigate to Users and Groups >> Administrative group roles.\n\nIf an unauthorized group is in the auditor role, remove the auditor role from the group.\n\nRestart the DMGR and all the JVMs.","ccis":["CCI-000067","CCI-002234"]},{"vulnId":"V-255822","ruleId":"SV-255822r960765_rule","severity":"medium","ruleTitle":"The WebSphere Application Server users in the WebSphere auditor role must be configured in accordance with the System Security Plan.","description":"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.\n\nRemote access by administrators requires that the admin activity be logged.\n\nApplication 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.\n\nSatisfies: SRG-APP-000016-AS-000013, SRG-APP-000343-AS-000030, SRG-APP-000090-AS-000051","checkContent":"Review System Security Plan documentation.\n\nIdentify users and roles.\n\nIn the administrative console, navigate to Users and Groups >> Administrative User Roles.\n\nCheck the roles for each user.\n\nIf any user is not authorized by the ISSO/ISSM to be in the role of an auditor, this is a finding.","fixText":"In the administrative console, navigate to Users and Groups >> Administrative User roles.\n\nIf an unauthorized user is in the auditor role, remove the user from the auditor role.\n\nRestart the DMGR and all the JVMs.","ccis":["CCI-000067","CCI-000171","CCI-002234"]},{"vulnId":"V-255823","ruleId":"SV-255823r960765_rule","severity":"medium","ruleTitle":"The WebSphere Application Server audit event type filters must be configured.","description":"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.\n\nRemote access by administrators requires that the admin activity be logged.\n\nApplication 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.\n\nSatisfies: 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","checkContent":"In the administrative console, navigate to Security >> Security auditing >> Event type Filters.\n\nVerify the following events and outcomes are enabled in the \"Events and Outcomes\" box. Also note the name of the filter associated with these events. This name will be referenced in STIG ID WBSP-AS-000110.\n\nAUTHN: \nSUCCESS,INFO,WARNING,ERROR,DENIED,REDIRECT\n\nAUTHZ: \nSUCCESS,INFO,WARNING,ERROR,DENIED,REDIRECT\n\nAUTHN_TERMINATE:\nSUCCESS,INFO,WARNING,ERROR,DENIED,REDIRECT\n\nREPOSITORY_SAVE: SUCCESS,INFO,WARNING,ERROR,DENIED,REDIRECT\n\nIf these audit filters are not configured in \"Events and Outcomes\", this is a finding.","fixText":"In the administrative console, navigate to Security >> Security auditing >> Event type Filters.\n\nClick the \"New\" button to create a new filter; give it a unique name. \n\nSelect SECURITY_AUTHN, SECURITY_AUTHZ, SECURITY_AUTHN_TERMINATE, and ADMIN_REPOSITORY_SAVE from \"Selectable events\".\n\nAdd them to the \"Enabled events\" box by clicking on the right arrow. \n\nSelect INFO, ERROR, SUCCESS, DENIED, REDIRECT, and WARNING from the \"Selectable event outcomes\" box.\n\nClick the right arrow to fill in \"Enabled events outcomes\" box.\n\nClick \"OK\". \n\nRestart the DMGR and all the JVMs.","ccis":["CCI-000067","CCI-000130","CCI-000132","CCI-000133","CCI-000134","CCI-000135","CCI-000169","CCI-000172","CCI-001462","CCI-001487","CCI-001814","CCI-002234"]},{"vulnId":"V-255824","ruleId":"SV-255824r960765_rule","severity":"medium","ruleTitle":"The WebSphere Application Server audit service provider must be enabled.","description":"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.\n\nRemote access by administrators requires that the admin activity be logged.\n\nApplication 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.\n\nSatisfies: SRG-APP-000016-AS-000013, SRG-APP-000343-AS-000030","checkContent":"In the administrative console, navigate to Security >> Security auditing >> Audit Service Provider [provider name]. \n\nUnder \"Enabled filters\", determine if the filter name from select the name of the filter that was recorded from STIG ID WBSP-AS-000100.\n\nIf the filter that was identified in STIG ID WBSP-AS-000100 is not enabled, this is a finding.","fixText":"In the administrative console, navigate to Security >> Security auditing >> Event type Filters.\n\nIdentify and record the event type filter that contains the required \"Events and Outcomes\".\n\nIn the administrative console, click on Security >> Security auditing >> Audit Service Provider [provider name]. \n\nUnder \"Selectable filters\", select the filter that was previously identified and recorded.\n\nClick the right arrow to add it to the list.\n\nClick \"OK\".\n\nClick \"Save\" to save the changes.\n\nRestart the DMGR and all the JVMs.","ccis":["CCI-000067","CCI-002234"]},{"vulnId":"V-255825","ruleId":"SV-255825r960765_rule","severity":"medium","ruleTitle":"The WebSphere Application Server automatic repository checkpoints must be enabled to track configuration changes.","description":"Without enabling repository checkpoints, you will not be able to determine the history of changes to WebSphere configuration files, and who made those changes.","checkContent":"Review System Security Plan documentation.\n\nIdentify the required \"Automatic CheckPoint Depth\" setting that has been defined.\n\nFrom administrative console, click System administration >> Extended repository service.\n\nIf \"Enable automatic repository checkpoints\" is not selected or if the \"automatic checkpoint depth\" is less than the number of saves defined in the System Security Plan, this is a finding.","fixText":"From administrative console click System administration >> Extended repository service >> Enable automatic repository checkpoints.\n\nEnter a \"checkpoint depth value\" according to the security plan.\n\nRestart the DMGR and all the JVMs.","ccis":["CCI-000067"]},{"vulnId":"V-255826","ruleId":"SV-255826r961278_rule","severity":"high","ruleTitle":"The WebSphere Application Server administrative security must be enabled.","description":"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.\n\nAs 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.","checkContent":"From the administrative console, click Security >> Global Security.\n\nIf \"Enable administrative security\" is not selected, this is a finding.","fixText":"From the administrative console, click Security >> Global Security.\n\nClick \"Enable administrative security\".\n\nClick \"Save\".\n\nRestart the DMGR and all the JVMs.","ccis":["CCI-002314"]},{"vulnId":"V-255827","ruleId":"SV-255827r961863_rule","severity":"high","ruleTitle":"The WebSphere Application Server bus security must be enabled.","description":"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.\n\nWhen a bus is created with bus security enabled, the following conditions apply:\nThe bus requires client authentication.\nThe bus enforces authorization policy.\nThe bus requires use of SSL transport chains.","checkContent":"Review System Security Plan documentation.\n\nInterview the system administrator.\n\nIdentify the service integration buses configured on the WAS.\n\nIf there are no service integration buses, this requirement is NA.\n\nFrom the administration console, navigate to Security >> Bus Security.\n\nFor each service integration bus, if security is not enabled, this is a finding.","fixText":"From the administration console, navigate to Security >> Bus Security.\n\nFor each service integration bus where security is not enabled, click on \"Disabled\".\n\nClick the check box to \"Enable bus security\".\n\nConfigure the transport settings and authorization policies according to application security access requirements specified in the security plan.","ccis":["CCI-002315","CCI-000366"]},{"vulnId":"V-255828","ruleId":"SV-255828r961278_rule","severity":"medium","ruleTitle":"The WebSphere Application Server users in a local user registry group must be authorized for that group.","description":"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.\n\nExamples 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.\n\nSatisfies: 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","checkContent":"If the systems user registry is managed by LDAP, this requirement is NA.\n\nReview the System Security Plan documentation.\n\nInterview the system administrator.\n\nObtain a list of authorized users.\n\nIn the administrative console, navigate to Users and Groups >> Manage Groups.\n\nSelect each group.\n\nSelect the \"Members\" tab.\n\nValidate the members of the group are authorized.\n\nIf users in the group are not authorized by the ISSO/ISSM, this is a finding.","fixText":"From administrative console, navigate to Users and Groups >> Administrative group roles.\n\nNote: names of the groups and the roles assigned to each group.\n\nNavigate back to User and Groups >> Manage Groups.\n\nClick on every group.\n\nFor each group, click on users.\n\nIf there is any user who does not belong to the group based on the roles assigned to the group, click on the checkbox next to the user.\n\nClick \"Remove\".\n\nRestart the DMGR and all the JVMs.","ccis":["CCI-000213","CCI-000770","CCI-001499","CCI-001813","CCI-002314"]},{"vulnId":"V-255829","ruleId":"SV-255829r960759_rule","severity":"medium","ruleTitle":"The WebSphere Application Server Quality of Protection (QoP) must be set to use TLSv1.2 or higher.","description":"Quality of Protection specifies the security level, ciphers, and mutual authentication settings for the Secure Socket Layer (SSL/TLS) configuration.","checkContent":"From the administrative console, navigate to Security >> SSL certificate and key management.\n\nClick \"SSL configurations\".\n\nClick on each SSL configuration to review.\n\nUnder \"Additional Properties\", click \"Quality of protection (QoP)\" settings.\n\nIf the \"Protocol\" field does not show \"TLSv1.2 or greater\", this is a finding.","fixText":"From the administrative console, navigate to Security >> SSL certificate and key management.\n\nClick \"SSL configurations\".\n\nClick on each SSL configuration.\n\nUnder \"Additional Properties\", click \"Quality of protection (QoP)\" settings.\n\nAt the \"Protocol\" pull-down menu, select \"TLSv1.2 or greater\".\n\nClick \"OK\".\n\nClick \"Save\".\n\nRestart the DMGR and all the JVMs.","ccis":["CCI-000068"]},{"vulnId":"V-255830","ruleId":"SV-255830r960759_rule","severity":"high","ruleTitle":"The WebSphere Application Server global application security must be enabled.","description":"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.\n\nIn 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.\n\nAs 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.\n\nSatisfies: SRG-APP-000014-AS-000009, SRG-APP-000172-AS-000120","checkContent":"From the administrative console, navigate to Security >> Global Security.\n\nIf \"Enable administrative security\" and \"Enable application security\" are not selected, this is a finding.","fixText":"From the administrative console, navigate to Security >> Global Security.\n\nClick on \"Enable administrative security\".\n\nClick on \"Enable application security\".\n\nClick \"OK\".\n\nClick \"Save\".\n\nRestart the DMGR and all the JVMs.","ccis":["CCI-000068","CCI-000197"]},{"vulnId":"V-255831","ruleId":"SV-255831r960759_rule","severity":"high","ruleTitle":"The WebSphere Application Server Single Sign On (SSO) must have SSL enabled for Web and SIP Security.","description":"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. \n\nTypes of management interfaces utilized by an application server include web-based HTTPS interfaces as well as command line-based management interfaces.\n\nSatisfies: SRG-APP-000014-AS-000009, SRG-APP-000172-AS-000120, SRG-APP-000158-AS-000108","checkContent":"From the administrative console, navigate to Security >> Global Security.\n\nExpand \"Web and SIP security\".\n\nClick on \"Single sign-on (SSO)\".\n\nIf \"requires SSL\" is not selected, this is a finding.","fixText":"From the administrative console, navigate to Security >> Global Security.\n\nExpand \"Web and SIP security\".\n\nClick on \"Single sign-on (SSO)\".\n\nSelect \"Requires SSL\".\n\nClick \"OK\".\n\nClick \"Save\".\n\nRestart the DMGR and all the JVMs.","ccis":["CCI-000068","CCI-000197","CCI-000778"]},{"vulnId":"V-255832","ruleId":"SV-255832r960762_rule","severity":"medium","ruleTitle":"The WebSphere Application Server security cookies must be set to HTTPOnly.","description":"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. \n\nIn 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.","checkContent":"From the administrative console, navigate to Security >> Global Security.\n\nExpand \"Web and SIP security\".\n\nClick on \"Single sign-on (SSO)\".\n\nIf \"Set security cookies to HTTPOnly\" is not selected, this is a finding.","fixText":"From the administrative console, navigate to Security >> Global Security.\n\nExpand \"Web and SIP security\".\n\nSelect \"Set security cookies to HTTPOnly\".\n\nClick \"OK\".\n\nClick \"Save\".\n\nRestart the DMGR and all the JVMs.","ccis":["CCI-001453"]},{"vulnId":"V-255833","ruleId":"SV-255833r1137578_rule","severity":"high","ruleTitle":"The WebSphere Application Server Java 2 security must be enabled.","description":"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:\n\n/QIBM/ProdData/Java400/jdk14/lib/security/java.policy\n/QIBM/UserData/WebASE51/ASE/instance/properties/server.policy\n/QIBM/UserData/WebASE51/ASE/instance/config/cells/cell/nodes/node/app.policy\nwhere instance is the name of your instance, cell is the name of your cell, and node is the name of your node.","checkContent":"From the admin console, select Security >> Global Security >> Java 2 Security. \n\nIf \"Use Java 2 security to restrict application access to local resources\" is not selected, this is a finding.","fixText":"From the admin console, select Security >> Global Security >> Java 2 Security.\n\nSelect the \"Use Java 2 security to restrict application access to local resources\" check box.\n\nEnsure the application security policies are defined and access permissions are granted accordingly.\n\nPolicies are created and access is granted on an application by application basis. Application access to the underlying host is based upon application access requirements.","ccis":["CCI-000213"]},{"vulnId":"V-255834","ruleId":"SV-255834r1137578_rule","severity":"high","ruleTitle":"The WebSphere Application Server Java 2 security must not be bypassed.","description":"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.","checkContent":"If the system is a development or test system, this requirement is NA.\n\nFrom the admin console, select Servers >> Server Types >> WebSphere application servers.\n\nFor each application server, select Server Infrastructure >> Administration >> Custom properties.\n\nIf the \"com.ibm.websphere.java2secman.norethrow\" resource value exists and is set to \"true\", this is a finding.","fixText":"From the admin console, select Servers >> Server Types >> WebSphere application servers.\n\nFor each application server, select Server Infrastructure >> Administration >> Custom properties.\n\nDelete the \"com.ibm.websphere.java2secman.norethrow\" resource value from production systems.","ccis":["CCI-000213"]},{"vulnId":"V-255835","ruleId":"SV-255835r1137578_rule","severity":"medium","ruleTitle":"The WebSphere Application Server users in the admin role must be authorized.","description":"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.\n\nWithout 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.\n\nSatisfies: SRG-APP-000033-AS-000024, SRG-APP-000380-AS-000088, SRG-APP-000340-AS-000185","checkContent":"Review System Security Plan documentation.\n\nIn the administrative console, navigate to Users and Groups >> Administrative user roles.\n\nIf users assigned to the admin role are not authorized by the ISSO/ISSM, this is a finding.","fixText":"Navigate to User and Groups >> Administrative user roles.\n\nIf an unauthorized user is assigned to the admin role, click on the user, remove admin rights and assign proper roles as defined in System Security Plan.\n\nDo not delete any user with the \"Primary administrative user name\" designation.\n\nClick \"OK\".\n\nClick \"Save\".\n\nRestart the DMGR and all the JVMs.","ccis":["CCI-000213","CCI-001813","CCI-002235"]},{"vulnId":"V-255836","ruleId":"SV-255836r1137578_rule","severity":"medium","ruleTitle":"The WebSphere Application Server LDAP groups must be authorized for the WebSphere role.","description":"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.\n\nWithout 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.\n\nSatisfies: SRG-APP-000033-AS-000024, SRG-APP-000267-AS-000170","checkContent":"Review System Security Plan documentation.\n\nReview details regarding LDAP groups that are mapped to WebSphere roles. \n\nIn the administrative console, under Users and Groups >> Administrative group roles.\n\nIf there is a LDAP group or groups assigned to a WebSphere role that has not been authorized by the ISSO/ISSM, this is a finding.","fixText":"Navigate to User and Groups >> Administrative group roles.\n\nIf any group is assigned roles that the group should not have, click on the group.\n\nAssign only the role(s) the group should have.\n\nClick \"OK\".\n\nClick \"Save\". \n\nRestart the DMGR and all the JVMs.","ccis":["CCI-000213","CCI-001314"]},{"vulnId":"V-255837","ruleId":"SV-255837r961353_rule","severity":"medium","ruleTitle":"The WebSphere Application Server users in a LDAP user registry group must be authorized for that group.","description":"Preventing non-privileged users from executing privileged functions mitigates the risk that unauthorized individuals or processes may gain unnecessary access to information or privileges.\n\nRestricting 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.","checkContent":"If a file based or local federated repository is in use, this requirement is NA.\n\nReview System Security Plan documentation.\n\nInterview the system administrator.\n\nIn the administrative console select Security >> Global Security.\n\nUnder \"User Account Repository\", verify the \"Available realm Definition\" is set to \"Standalone LDAP registry\".\n\nSelect \"Configure\".\n\nThe properties of the LDAP repository are displayed for purposes of identifying the LDAP server.\n\nWork with the admin of LDAP repository.\n\nIdentify users and groups.\n\nValidate members of groups are authorized.\n\nIf the group members have not been authorized by the ISSO/ISSM, this is a finding.","fixText":"In the LDAP server admin console, assign WebSphere users to the appropriate WebSphere group.","ccis":["CCI-002235"]},{"vulnId":"V-255838","ruleId":"SV-255838r960843_rule","severity":"medium","ruleTitle":"The WebSphere Application Server management interface must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system.","description":"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: \n\n(i) users are accessing a U.S. Government information system; \n(ii) system usage may be monitored, recorded, and subject to audit; \n(iii) unauthorized use of the system is prohibited and subject to criminal and civil penalties; and \n(iv) the use of the system indicates consent to monitoring and recording.\n\nSystem use notification messages can be implemented in the form of warning banners displayed when individuals log on to the information system. \n\nSystem 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. \n\nUse 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\".\n\n\"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n-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.\n-At any time, the USG may inspect and seize data stored on this IS.\n-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.\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n-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.\"","checkContent":"Point browser to the URL of the WebSphere administration console.\n\nIf the Standard Mandatory DoD Notice and Consent Banner is not displayed, this is a finding.","fixText":"Open the file ${WAS_HOME}/properties/login.info.\n\nFollow the instructions in the HTML comment section to create the pre-logon banner.\n\nEnter the Standard DoD Mandatory Notice and Consent banner into the HTML section.\n\nIf logged on to the admin console, log out and log back on to validate the changes.\n\nRestart the DMGR and all the JVMs.","ccis":["CCI-000048"]},{"vulnId":"V-255839","ruleId":"SV-255839r960846_rule","severity":"medium","ruleTitle":"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.","description":"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\".","checkContent":"Point browser to the URL of the WebSphere administration console.\n\nIf the Standard Mandatory DoD Notice and Consent Banner is not retained until the user acknowledges the usage conditions, this is a finding.","fixText":"Open the file ${WAS_HOME}/properties/login.info.\n\nFollow the instructions in the HTML comment section to create the pre-logon banner.\n\nEnter the Standard DoD Mandatory Notice and Consent banner into the HTML section.\n\nIf logged on to the admin console, log out and log back on to validate the changes.\n\nRestart the DMGR and all the JVMs.","ccis":["CCI-000050"]},{"vulnId":"V-255840","ruleId":"SV-255840r960885_rule","severity":"low","ruleTitle":"The WebSphere Application Server must generate log records when successful/unsuccessful attempts to access subject privileges occur.","description":"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.\n\nApplication 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.","checkContent":"In the administrative console, navigate to Security >> Security auditing >> Audit Service Provider.\n\nClick on the providers in the list.\n\nNote: names of all the filters, e.g., \"DefaultAuditSpecification_1\".\n\nGo back to Security >> Security auditing >> Event type Filters.\n\nFind the filters previously noted.\n\nIf you do not see the filter for SECURITY_AUTHN, SECURITY_AUTHZ, SECURITY_AUTHN_TERMINATE, and ADMIN_REPOSITORY_SAVE that has INFO, ERROR, SUCCESS, DENIED, REDIRECT, and WARNING defined, this is a finding.","fixText":"In the administrative console, navigate to Security >> Security auditing >> Audit Service Provider.\n\nClick on the providers in the list.\n\nNote the names of all the filters, e.g., \"DefaultAuditSpecification_1\".\n\nGo back to Security >> Security auditing >> Event type Filters.\n\nFind the filters previously noted.\n\nIf you do not see that the provider filter for SECURITY_AUTHN, SECURITY_AUTHZ, SECURITY_AUTHN_TERMINATE, and ADMIN_REPOSITORY_SAVE that has INFO, ERROR, SUCCESS, DENIED, REDIRECT, and WARNING defined, click the \"New\" button to create a new filter.\n\nGive it a unique name.\n\nSelect \"SECURITY_AUTHN\" and \"ADMIN_REPOSITORY_SAVE\" from the \"Events to associate with audit filter\" field.\n\nClick the right arrow to fill in \"Enabled events\" field.\n\nFrom \"Event outcomes to associate with an audit filter\" field, select INFO, ERROR, SUCCESS, DENIED, REDIRECT, and WARNING.\n\nClick the right arrow to fill in \"Enabled event outcomes\" field.\n\nClick \"OK\".\n\nGo back to Security >> Security auditing >> Audit Service Provider >> [provider].\n\nUnder \"Selectable filters\", select the new filter just created.\n\nClick the right arrow to add it to the list.\n\nClick \"OK\".\n\nClick \"Save\".\n\nRestart the DMGR and all the JVMs.","ccis":["CCI-000172"]},{"vulnId":"V-255841","ruleId":"SV-255841r961392_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must allocate JVM log record storage capacity in accordance with organization-defined log record storage requirements.","description":"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. \n\nThe 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.\n\nIf adequate online log storage capacity is not maintained, intrusion monitoring, security investigations, and forensic analysis can be negatively affected.\n\nIt 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.","checkContent":"Review System Security Plan documentation.\n\nIdentify the JVM log size and rotation settings based on component log policy.\n\nFrom the administrative console, navigate to Troubleshooting >> Logs and Trace.\n\nChoose [server name].\n\nClick on the server name to select it.\n\nClick \"JVM\" Logs.\n\nFor \"System.out\" verify \"File Size\" is selected and \"Maximum size\" and \"Maximum Historical Log Files\" are set according to the System Security Plan. \n\nFor \"System.err\" verify \"File Size\" is selected and \"Maximum size\" and \"Maximum Historical Log Files\" are set according to the System Security Plan. \n\nIf log size and log history retention settings for \"System.err\" and \"System.out\" are not set as per the System Security Plan, this is a finding.","fixText":"Identify JVM log size and history retention based on component log policy.\n\nDocument those values in the System Security Plan.\n\nFrom the administrative console, navigate to Troubleshooting >> Logs and Trace.\n\nSelect each [server name].\n\nClick \"JVM\" Logs. \n\nUnder \"System.out\", \"Log Rotation\", select \"File size\" in the \"Maximum Size\" entry field, enter the maximum log size based on policy.\n\nUnder \"System.err\", \"Log Rotation\", select \"File Size\" in the \"Maximum Size\" entry field, enter the maximum log size based on policy.\n\nClick \"OK\".\n\nClick \"Save\".","ccis":["CCI-001849"]},{"vulnId":"V-255842","ruleId":"SV-255842r961392_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must allocate audit log record storage capacity in accordance with organization-defined log record storage requirements.","description":"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.\n\nIf adequate online log storage capacity is not maintained, intrusion monitoring, security investigations, and forensic analysis can be negatively affected.\n\nIt 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.","checkContent":"Review System Security Plan documentation.\n\nIdentify the Audit Service Provider log size and rotation settings based on component log policy.\n\nFrom administrative console, click Security >> Security auditing >> Audit service provider.\n\nSelect each [audit_service_provider_name].\n\nIf \"Audit Log Size\" and \"Max Number of Audit Log Files\" are not configured as per the System Security Plan, this is a finding.","fixText":"Identify Audit Service Provider log size and history retention based on component log policy.\n\nDocument those values in the System Security Plan.\n\nFrom administrative console, click Security >> Security auditing >>Related Items>> Audit service provider >> [audit_service_provider_name].\n\nUnder Audit log file size specify the size of the file in MB as defined by your policy.\n\nUnder \"Maximum number of audit logs files\", specify the maximum number of logs you want to keep on the file system as defined by your policy.\n\nClick \"OK\".\n\nClick \"Save\".","ccis":["CCI-001849"]},{"vulnId":"V-255843","ruleId":"SV-255843r961401_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must provide an immediate real-time alert to authorized users of all log failure events requiring real-time alerts.","description":"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.","checkContent":"If notifications of log processing failures are done via an alternative notification process, this is not a finding.\n\nIn the administrative console, navigate to Security >> Security auditing >> Audit monitor.\n\nIf \"Enabled monitoring\" is not checked and \"Monitor notification\" is not set to a name in the notifications list, this is a finding.","fixText":"Establish and utilize a notification process for WebSphere log events or configure WebSphere to send log events alerts via email.\n\nIn the administrative console, navigate to Security >> Security auditing >> Audit monitor.\n\nSelect a \"Monitor\" notification from the dropdown box or create a new notification.\n\nClick on \"New\".\n\nSpecify a unique name for the new notification.\n\nClick \"Message log\" checkbox.\n\nSelect \"Email sent to notification list\".\n\nEnter emails in the \"Email address to add\" field.\n\nEnter the mail server address in the \"Outgoing mail (STMP) server\" field.\n\nClick \">\" to put email in \"List of email addresses\" field.\n\nClick \"OK\".\n\nSelect the \"Enable monitoring\" check box to turn on audit failure notifications.\n\nSelect the notification configuration to be used from the \"Monitor notification\" dropdown menu.\n\nClick \"OK\".\n\nClick \"Save\".","ccis":["CCI-001858"]},{"vulnId":"V-255844","ruleId":"SV-255844r960912_rule","severity":"low","ruleTitle":"The WebSphere Application Server must alert the SA and ISSO, at a minimum, in the event of a log processing failure.","description":"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.\n\nLog 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.","checkContent":"If the SA and ISSO are notified of log processing failures via an alternative notification process, this is not a finding.\n\nIn the administrative console, navigate to Security >> Security auditing >> Audit monitor.\n\nIf \"Enabled monitoring\" is not checked and \"Monitor notification\" is not set to a notification in the notifications list, that includes the SA and ISSO, this is a finding.","fixText":"Establish and utilize a notification process for WebSphere log events or configure WebSphere to send log event alerts via email.\n\nIn the administrative console, navigate to Security >> Security auditing >> Audit monitor.\n\nClick on \"New\" button.\n\nSpecify a unique name for the new notification name.\n\nClick \"Message log\" checkbox.\n\nSelect \"Email sent to notification list\".\n\nEnter SA and ISSO emails in the \"Email address to add\" field.\n\nEnter the mail server address in the \"Outgoing mail (STMP) server\" field.\n\nClick \">\" to put email in \"List of email addresses\" field.\n\nClick \"OK\".\n\nSelect the \"Enable monitoring\" check box to turn on audit failure notifications.\n\nSelect the notification configuration to be used from the \"Monitor notification\" dropdown menu.\n\nClick \"OK\".\n\nClick \"Save\".","ccis":["CCI-000139"]},{"vulnId":"V-255845","ruleId":"SV-255845r960912_rule","severity":"medium","ruleTitle":"The WebSphere Application Server audit subsystem failure action must be set to Log warning.","description":"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.\n\nLog 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.","checkContent":"In the administrative console, navigate to Security >> Security auditing.\n\nIf \"Audit subsystem failure action\" is not set to \"Log Warning\", this is a finding.","fixText":"In the administrative console, navigate to Security >> Security auditing.\n\nClick the \"Audit subsystem failure action\" dropdown box.\n\nSelect \"Log Warning\".\n\nClick \"Apply\".\n\nClick \"Save\" to save the configuration.\n\nRestart the DMGR and all JVMs.","ccis":["CCI-000139"]},{"vulnId":"V-255846","ruleId":"SV-255846r1043188_rule","severity":"low","ruleTitle":"The WebSphere Application Server must shut down by default upon log failure (unless availability is an overriding concern).","description":"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.\n\nWhen availability is an overriding concern, other approved actions in response to a log failure include: \n\n(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.\n\n(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.\n\nIf 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.","checkContent":"If the System Security Plan documentation specifies system availability is an overriding concern, this requirement is NA.\n\nIn the admin console click Security >> Security Auditing.\n\nIf \"Audit subsystem failure action\" is not set to \"Terminate\", this is a finding.","fixText":"In the admin console click Security >> Security Auditing.\n\nSet \"Audit subsystem failure action\" to \"Terminate\".\n\nRestart the DMGR and all JVMs.","ccis":["CCI-000140"]},{"vulnId":"V-255847","ruleId":"SV-255847r1043188_rule","severity":"low","ruleTitle":"The WebSphere Application Server high availability applications must be configured to fail over to another system in the event of log subsystem failure.","description":"This requirement is dependent upon system MAC and availability. If the system MAC and availability do not specify redundancy requirements, this requirement is NA.\n\nIt 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.\n\nApplication 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.","checkContent":"If the System Security Plan documentation does not require redundancy, this requirement is NA.\n\nClick Servers >> Clusters >> WebSphere application server clusters.\n\nEnsure you have a cluster defined for every application requiring redundancy.\n\nIf there is not a cluster defined for every application requiring redundancy, this is a finding.","fixText":"In the admin console, Click Servers >> Clusters >> WebSphere application server clusters.\n\nDefine a cluster for every high availability application as outlined in the System Security Plan documentation.\n\nRefer to vendor documentation for steps on creating a fail over cluster.","ccis":["CCI-000140"]},{"vulnId":"V-255848","ruleId":"SV-255848r960930_rule","severity":"low","ruleTitle":"The WebSphere Application Server must be configured to protect log information from any type of unauthorized read access.","description":"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.","checkContent":"Review system documentation and System Security Plan.\n\nIdentify the home folder and user account for the WebSphere installation.\n\nLog on to the operating system that is hosting the WebSphere application server. By default, WebSphere will be installed in the \"/opt/IBM/Websphere\" folder on UNIX like systems and in the \"C:\\Program Files\\IBM\\Websphere\\\" folder on Windows systems.\n\nOn UNIX systems, verify file permissions for the \"WebSphere\" folder are set to \"770\" for the WebSphere user, group, and other. Permissions do not propagate to sub-folders.\n\nOn Windows systems, verify file permissions for \"WebSphere\" folder allow SYSTEM, WebSphere User and Admin Group full control. Permissions do not propagate to sub-folders.\n\nIf file permissions exceed these restrictions, this is a finding.","fixText":"On the system hosting the WebSphere application server, log on to the operating system with admin rights.\n\nNavigate to the WebSphere folder, change permissions on the folder. Do not propagate permissions to sub-folders.\n\nFor UNIX systems: set \"WebSphere\" folder permissions to \"770\". \n\nFor Windows systems: set \"WebSphere\" folder permission to allow full control for SYSTEM, WebSphere user and Admin Group. Do not propagate permissions to sub-folders.","ccis":["CCI-000162"]},{"vulnId":"V-255849","ruleId":"SV-255849r960933_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must protect log information from unauthorized modification.","description":"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.","checkContent":"Review System Security Plan and the system documentation.\n\nIdentify the home folder and user account for the WebSphere installation.\n\nLog on to the operating system that is hosting the WebSphere application server. By default, WebSphere will be installed in the \"/opt/IBM/Websphere\" folder on UNIX like systems and in the \"C:\\Program Files\\IBM\\Websphere\\\" folder on Windows systems.\n\nOn UNIX systems, verify file permissions for the \"WebSphere\" folder are set to \"770\" for the WebSphere user, group and other. Permissions do not propagate to sub-folders.\n\nOn Windows systems, verify file permissions for \"WebSphere\" folder allow SYSTEM, WebSphere User, and Admin Group full control. Permissions do not propagate to sub-folders.\n\nIf file permissions exceed these restrictions, this is a finding.","fixText":"On the system hosting the WebSphere application server, log on to the operating system with admin rights.\n\nNavigate to the \"WebSphere\" folder, change permissions on the folder. Do not propagate permissions to sub-folders.\n\nFor UNIX systems: set \"WebSphere folder\" permissions to \"770\".\n\nFor Windows systems: set \"WebSphere folder\" permission to allow full control for SYSTEM, WebSphere user, and Admin Group. Do not propagate permissions to sub-folders.","ccis":["CCI-000163"]},{"vulnId":"V-255850","ruleId":"SV-255850r960936_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must protect log information from unauthorized deletion.","description":"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.","checkContent":"Review System Security Plan and the system documentation.\n\nIdentify the home folder and user account for the WebSphere installation.\n\nLog on to the operating system that is hosting the WebSphere application server. By default, WebSphere will be installed in the \"/opt/IBM/Websphere\" folder on UNIX like systems and in the \"C:\\Program Files\\IBM\\Websphere\\\" folder on Windows systems.\n\nOn UNIX systems, verify file permissions for the \"WebSphere\" folder are set to \"770\" for the WebSphere user, group, and other. Permissions do not propagate to sub-folders.\n\nOn Windows systems, verify file permissions for \"WebSphere\" folder allow SYSTEM, WebSphere User and Admin Group full control. Permissions do not propagate to sub-folders.\n\nIf file permissions exceed these restrictions, this is a finding.","fixText":"On the system hosting the WebSphere application server, log on to the operating system with admin rights.\n\nNavigate to the WebSphere folder, change permissions on the folder. Do not propagate permissions to sub-folders.\n\nFor UNIX systems: set \"WebSphere\" folder permissions to \"770\".\n\nFor Windows systems: set \"WebSphere\" folder permission to allow full control for SYSTEM, WebSphere user, and Admin Group. Do not propagate permissions to sub-folders.","ccis":["CCI-000164"]},{"vulnId":"V-255851","ruleId":"SV-255851r960939_rule","severity":"medium","ruleTitle":"The WebSphere Application Server wsadmin file must be protected from unauthorized access.","description":"Protecting log data also includes identifying and protecting the tools used to view and manipulate log data. \n\nDepending 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. \n\nIt is, therefore, imperative that access to log tools be controlled and protected from unauthorized access. \n\nApplication 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.","checkContent":"Review System Security Plan and the system documentation.\n\nIdentify the home folder and user account for the WebSphere installation.\n\nLog on to the operating system that is hosting the WebSphere application server. By default, WebSphere will be installed in the \"/opt/IBM/Websphere\" folder on UNIX like systems and in the \"C:\\Program Files\\IBM\\Websphere\\\" folder on Windows systems.\n\nOn UNIX systems, verify file permissions for the \"WebSphere\" folder are set to \"770\" for the WebSphere user, group, and other. Permissions do not propagate to sub-folders.\n\nOn Windows systems, verify file permissions for \"WebSphere\" folder allow SYSTEM, WebSphere User, and Admin Group full control. Permissions do not propagate to sub-folders.\n\nIf file permissions exceed these restrictions, this is a finding.","fixText":"On the system hosting the WebSphere application server, log on to the operating system with admin rights.\n\nNavigate to the \"WebSphere\" folder, and change permissions on the folder. Do not propagate permissions to sub-folders.\n\nFor UNIX systems: set the \"WebSphere\" folder permissions to \"770\".\n\nFor Windows systems: set the \"WebSphere\" folder permission to allow full control for SYSTEM, WebSphere user, and Admin Group. Do not propagate permissions to sub-folders.","ccis":["CCI-001493"]},{"vulnId":"V-255852","ruleId":"SV-255852r960942_rule","severity":"medium","ruleTitle":"The WebSphere Application Server wsadmin file must be protected from unauthorized modification.","description":"Protecting log data also includes identifying and protecting the tools used to view and manipulate log data. \n\nDepending 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. \n\nIt 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. \n\nApplication 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.","checkContent":"Review System Security Plan and the system documentation.\n\nIdentify the home folder and user account for the WebSphere installation.\n\nLog on to the operating system that is hosting the WebSphere application server. By default, WebSphere will be installed in the \"/opt/IBM/Websphere\" folder on UNIX like systems and in the \"C:\\Program Files\\IBM\\Websphere\\\" folder on Windows systems.\n\nOn UNIX systems, verify file permissions for the \"WebSphere\" folder are set to \"770\" for the WebSphere user, group, and other. Permissions do not propagate to sub-folders.\n\nOn Windows systems, verify file permissions for \"WebSphere\" folder allow SYSTEM, WebSphere User, and Admin Group full control. Permissions do not propagate to sub-folders.\n\nIf file permissions exceed these restrictions, this is a finding.","fixText":"On the system hosting the WebSphere Application Server, log on to the operating system with admin rights.\n\nNavigate to the \"WebSphere\" folder.\n\nChange the permissions on the folder. Do not propagate permissions to sub-folders.\n\nFor UNIX systems: set the \"WebSphere\" folder permissions to \"770\".\n\nFor Windows systems: set the \"WebSphere\" folder permission to allow full control for SYSTEM, WebSphere user, and Admin Group. Do not propagate permissions to sub-folders.","ccis":["CCI-001494"]},{"vulnId":"V-255853","ruleId":"SV-255853r960945_rule","severity":"medium","ruleTitle":"The WebSphere Application Server wsadmin file must be protected from unauthorized deletion.","description":"Protecting log data also includes identifying and protecting the tools used to view and manipulate log data. \n\nDepending 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. \n\nIt 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. \n\nApplication 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.","checkContent":"Review system documentation and security plan.\n\nIdentify the home folder and user account for the WebSphere installation.\n\nLog on to the operating system that is hosting the WebSphere application server. By default, WebSphere will be installed in the \"/opt/IBM/Websphere\" folder on UNIX like systems and in the \"C:\\Program Files\\IBM\\Websphere\\\" folder on Windows systems.\n\nOn UNIX systems, verify file permissions for the \"WebSphere\" folder are set to \"770\" for the WebSphere user, group, and other. Permissions do not propagate to sub-folders.\n\nOn Windows systems, verify file permissions for WebSphere folder allow SYSTEM, WebSphere User, and Admin Group full control. Permissions do not propagate to sub-folders.\n\nIf file permissions exceed these restrictions, this is a finding.","fixText":"On the system hosting the WebSphere application server, log on to the operating system with admin rights.\n\nNavigate to the \"WebSphere\" folder, change permissions on the folder. Do not propagate permissions to sub-folders.\n\nFor UNIX systems: set the \"WebSphere\" folder permissions to \"770\".\n\nFor Windows systems: set \"WebSphere\" folder permission to allow full control for SYSTEM, WebSphere user, and Admin Group. Do not propagate permissions to sub-folders.","ccis":["CCI-001495"]},{"vulnId":"V-255854","ruleId":"SV-255854r960951_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must be configured to encrypt log information.","description":"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.","checkContent":"Review System Security Plan documentation.\n\nIf the System Security Plan does not specify the encryption of audit records, this requirement is NA.\n\nFrom the administrative console, click Security >> Security Auditing >> Audit record encryption configuration.\n\nIf the \"Enable encryption\" check box is not selected, this is a finding.","fixText":"From the administrative console, click Security >> Security Auditing >> Audit record encryption configuration.\n\nSelect the \"Enable encryption\" checkbox.\n\nSelect the keystore that contains the encrypting certificate from the drop-down menu or click \"New\" to create a new keystore.\n\nIf you are using an existing certificate to encrypt your audit records, ensure the Certificate in the keystore is selected and specify the intended certificate in the \"Certificate alias\" drop-down menu.\n\nIf you are generating a new certificate to encrypt your audit records, do NOT use the \"Create a new certificate in the selected keystore\" option, this will generate a SHA-1 signed certificate, which is not allowed.\n\nInstead, select Security >> SSL Certificate and key management >> KeyStores and Certificates.\n\nSelect the keystore that is associated with the server hosting the audit logs.\n\nSelect \"Personal Certificates\".\n\nSelect \"Create\".\n\nSelect either a CA-Signed or Chained Certificate based on your requirements.\n\nFill in the information required to generate the certificate.\n\nRestart the DMGR and all the JVMs.","ccis":["CCI-001350"]},{"vulnId":"V-255855","ruleId":"SV-255855r960951_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must be configured to sign log information.","description":"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.","checkContent":"From the administrative console, click Security >> Security Auditing >> Audit record signing configuration.\n\nIf the \"Enable signing\" checkbox is not selected, this is a finding.","fixText":"From the administrative console, click Security >> Security Auditing >> Audit record signing configuration.\n\nSelect the \"Enable signing\" checkbox.\n\nSelect the keystore that contains the encrypting certificate from the drop-down menu.\n\nIf you are using an existing certificate to sign your audit records, ensure the Certificate in keystore is selected and specify the intended certificate in the \"Certificate alias\" drop-down menu.\n\nIf you are generating a new certificate to sign your audit records, do NOT use the \"Create a new certificate in the selected keystore\" option, this will generate a SHA-1 signed certificate, which is not allowed.\n\nInstead, select Security >> SSL Certificate and key management >> KeyStores and Certificates.\n\nSelect the keystore that is associated with the server hosting the audit logs.\n\nSelect \"Personal Certificates\".\n\nSelect \"Create\".\n\nSelect either a CA-Signed or Chained Certificate based on your requirements.\n\nFill in the information required to generate the certificate.\n\nRestart the DMGR and all the JVMs.","ccis":["CCI-001350"]},{"vulnId":"V-255856","ruleId":"SV-255856r960963_rule","severity":"medium","ruleTitle":"The WebSphere Application Server process must not be started from the command line with the -password option.","description":"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.","checkContent":"Review System Security Plan documentation.\n\nInterview the system administrator.\n\nAccess operating system to list commands currently running.\n\nFor UNIX: run \"ps -ef | grep -i wsadmin.sh\"\n\nFor windows: from a DOS prompt as admin user run \"WMIC path win32_process where \"caption='wsadmin.exe'\" get CommandLine\"\n\nIf the results show \"wsadmin.sh(exe) -user -password \", this is a finding.","fixText":"When starting WebSphere commands, such as wsadmin, stopManager, stopNode, stopServer, or syncNode; do not use the \"-password \" option.\n\nUse the interactive mode instead; you will be prompted for user id and password.\n\nFor scripts, you may configure user id and password in the \"connector properties\" files. These files are under \"Profile_Root/Properties\" folder.\n\n- soap.client.props: for default SOAP\n- sas.client.props : for RMI and JSR160RMI connectors\n- ipc.client.props: for IPC connector","ccis":["CCI-000381"]},{"vulnId":"V-255857","ruleId":"SV-255857r960963_rule","severity":"medium","ruleTitle":"The WebSphere Application Server files must be owned by the non-root WebSphere user ID.","description":"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.\n\nSpecifying 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.\n\nUse the underlying OS file permissions to ensure that access to the WebSphere files are restricted to only those users who require access.","checkContent":"Review System Security Plan documentation.\n\nInterview the system administrator.\n\nDetermine the OS user and group information associated with the WebSphere processes.\n\nIdentify the paths, files, and folders associated with the WebSphere installation.\n\nThese include:\n- : where you installed WebSphere. \n\n default location:\n\nFor UNIX: /opt/IBM/WebSphere/AppServer\nFor Windows: C:\\Program Files\\IBM\\WebSphere\\AppServer\n\n- : where the appserver instance resides. The default location is under \"/profiles\".\n\n- : any additional files that may reside outside of . Examples include:\n- shared library .jar files\n- Resource Adapter .rar files\n- Key and trust store files (.jks and .p12)\n- Other files such as jdbc drivers\n\nFor Linux, use the command \"find -user root\" to find files owned by root user.\n\nOn windows use the \"dir /Q /S\" command from the root directories to show the owners of all files.\n\nExamine the output for files owned by the administrator or root account.\n\nIf any WebSphere file or additional files as described above are owned by root or the administrator, this is a finding.","fixText":"Note: executing this fix without proper planning regarding file ownership can render your installation inoperable. See vulnerability discussion before executing this fix.\n\nEnsure all WebSphere related files and folders are owned by the WebSphere OS user.\n\nEnsure OS group membership is restricted.\n\nFile ownership changes for UNIX systems:\nchown -R \nchown -R , \nchown -R , may be zero or more directories for other files\n\nGroup ownership changes for UNIX systems:\nchgrp -R \nchgrp -R ,\nchgrp -R , where may be zero or more root directories for other files\n\nFile ownership changes for Windows systems:\n\"takeown /r /u /f \", where the is , , or ","ccis":["CCI-000381"]},{"vulnId":"V-255858","ruleId":"SV-255858r960963_rule","severity":"low","ruleTitle":"The WebSphere Application Server sample applications must be removed.","description":"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. \n\nDo not install the samples during the profile creation or uninstall the sample programs.","checkContent":"Navigate to Applications >> All Applications.\n\nReview all applications installed on the application server.\n\nIf the sample applications snoop, ivt, or DefaultApplication are installed on a production system, this is a finding.","fixText":"Navigate to Applications >> All Applications.\n\nClick on the corresponding application checkbox.\n\nSelect \"Remove\".\n\nClick \"OK\".\n\nClick \"Save\".","ccis":["CCI-000381"]},{"vulnId":"V-255859","ruleId":"SV-255859r960963_rule","severity":"low","ruleTitle":"The WebSphere Application Server must remove JREs left by web server and plug-in installers for web servers and plugins running in the DMZ.","description":"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. \n\nWhen 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.\n\nHaving a functioning JRE in the DMZ provides attackers who have breached into the DMZ with additional tools to carry out further attacks.","checkContent":"This check needs to be run on the web server operating in the DMZ.\n\nReview system documentation.\n\nIdentify web servers operating in DMZ.\n\nIf there are no web servers configured for the DMZ, this is not applicable.\n\nFrom the administrative console, select Server Types >> Web Servers.\n\nSelect each web server operating in the DMZ.\n\nIdentify the \"Web server installation location\". \n\nOpen a secured command shell to the web server in the DMZ.\n\nChange directory to the web server installation location.\n\nCD to the /plugins folder. \n\nIf a /java directory exists in the plugins folder, this is a finding.","fixText":"For web servers provided with the WebSphere installation that are operating in the DMZ.\n\nRemove the /java directory from within the plugins folder.","ccis":["CCI-000381"]},{"vulnId":"V-255860","ruleId":"SV-255860r960963_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must be run as a non-admin user.","description":"Running WebSphere as an admin user gives attackers immediate admin privileges in the event the WebSphere processes are compromised.\n \nBest practice is to operate the WebSphere server with an account that has limited OS privileges.\n\nTo configure system startup: https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/trun_processrestart.html","checkContent":"Interview systems manager.\n\nIdentify the OS user ID that the WAS server runs as.\n\nUsing relevant OS commands review OS processes and search for WAS processes (running as Java).\n\nEnsure they are running under the assigned non-administrative user id.\n\nFor UNIX: \"ps -ef|grep -i websphere\"\n\nFor Windows: \"wmic path win32_process where \"caption = 'java.exe'\" get CommandLine\n\nIf the WebSphere processes are running as the root or administrator user, this is a finding.","fixText":"Ensure that WAS processes are started via the specified non-privileged OS user ID when running commands such as startManager, startNode, and startServer.\n\nIf startManager and startNode are in the system startup scripts, ensure that they are not started as the root user or admin user for Windows systems. \n\nFor example, in the UNIX system, the inittab entry may look like: \"was:235:respawn:/usr/WebSphere/AppServer/bin/rc.was >/dev/console 2>&1\".\n\nEnsure the user is not a root user and is instead a regular OS user.","ccis":["CCI-000381"]},{"vulnId":"V-255861","ruleId":"SV-255861r960963_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must disable JSP class reloading.","description":"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.","checkContent":"From admin console, navigate to: Applications >> All applications >> [application name] >> JSP and JSP options.\n\nIf \"JSP enable class reloading\" is checked, this is a finding.","fixText":"To disable JSP reloading:\n\nFrom the admin console, navigate to: Applications >> All applications >> [application name] >> JSP and JSP options.\n\nUncheck \"JSP enable class reloading\".","ccis":["CCI-000381"]},{"vulnId":"V-255862","ruleId":"SV-255862r1043177_rule","severity":"medium","ruleTitle":"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.","description":"Some networking protocols may not meet organizational security requirements to protect data and components.\n\nApplication 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.","checkContent":"In the administrative console, click Servers >> All Servers.\n\nSelect each [server_name].\n\nSelect >> Ports.\n\nConfirm server ports are registered with PPSM.\n\nNavigate to System Administration >> Deployment Manager >> Ports.\n\nConfirm ports are registered with PPSM.\n\nNavigate to System Administration >> node agents.\n\nFor each [node agent], select >> Ports.\n\nConfirm ports are registered with PPSM.\n\nIf any of available ports are not registered with PPSM, or if those ports to be connected through the firewall are not approved by PPSM, this is a finding.","fixText":"Ensure all available ports are registered with PPSM.","ccis":["CCI-000382"]},{"vulnId":"V-255863","ruleId":"SV-255863r1051118_rule","severity":"medium","ruleTitle":"The WebSphere Application Server LDAP user registry must be used.","description":"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.\n\nTo ensure support to the enterprise, the authentication must utilize an enterprise solution.","checkContent":"In the administrative console, click Security >> Global security.\n\nIf the \"Available realm definitions\" drop down box under the \"User account repository\" section is not set to \"Standalone LDAP registry\", this is a finding.","fixText":"In the administrative console, click Security >> Global security.\n\nUnder \"User account repository\", click the \"Available realm definitions\" drop-down list.\n\nSelect \"Standalone LDAP\" registry.\n\nClick \"Configure\".\n\nProvide the Primary Administrative user name, type of LDAP server, hostname for the LDAP server, define the Base distinguished name.\n\nClick \"OK\".\n\nOn \"Global security\" panel, click \"Set as current\".\n\nClick \"Apply\".\n\nClick \"Save\".\n\nRecycle and synchronize the JVMS.","ccis":["CCI-000764"]},{"vulnId":"V-255864","ruleId":"SV-255864r1051118_rule","severity":"medium","ruleTitle":"The WebSphere Application Server local file-based user registry must not be used.","description":"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.","checkContent":"Navigate to Security >> Global Security.\n\nUnder \"User Account Repository\" if the \"Federated Repositories\" is chosen, click on \"Configure\".\n\nUnder \"Repositories in the realm\", if \"o=defaultWIMFileBasedRealm\" appears in the \"Base Entry\" column, this is a finding.","fixText":"Navigate to Security >> Global Security.\n\nUnder \"User Account Repository\", select \"Stand alone LDAP\" from the \"Available realm definitions\" drop-down.\n\nClick on \"Configure\".\n\nSelect an existing user from the LDAP directory to be the primary WebSphere admin user.\n\nIdentify the type of LDAP server; specify an IP or DNS name for the LDAP Server, and the port used to connect to the LDAP server.\n\nSpecify BASE DN.\n\nSpecify the BIND DN.\n\nSpecify the BIND Password.\n\nSelect the \"SSL enabled\" check box to use secure LDAP.\n\nClick \"Apply\".\n\nClick \"Save\".\n\nGo to Global Security.\n\nSelect \"Standalone LDAP registry\" from the \"Available realm definitions\" drop-down.\n\nClick \"Set as current\".\n\nClick \"Apply\".\n\nClick \"Save\".\n\nRestart the dmgr and synchronize the JVMs.","ccis":["CCI-000764"]},{"vulnId":"V-255865","ruleId":"SV-255865r960972_rule","severity":"medium","ruleTitle":"The WebSphere Application Server multifactor authentication for network access to privileged accounts must be used.","description":"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.\n\nMultifactor authentication is defined as: using two or more factors to achieve authentication. \n\nFactors include: \n(i) something a user knows (e.g., password/PIN); \n(ii) something a user has (e.g., cryptographic identification device, token); or \n(iii) something a user is (e.g., biometric). A CAC or PKI Hardware Token meets this definition.\n\nA 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.\n\nWhen accessing the application server via a network connection, administrative access to the application server must be PKI Hardware Token enabled.\n\nSatisfies: 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","checkContent":"Check that the admin console is enabled for client certificate logon.\n\nIn the Deployment Manager, check the file on: /profiles//config/cells//applications/isclite.ear/deployments/isclite/isclite.war/WEB-INF/web.xml.\n\nIf the \"XML element FORM\" is present, this is a finding.","fixText":"From the admin console, select System Administration >> Deployment Manager >> Java and Process Management >> Process definition >> Java Virtual Machine >> Custom Properties.\n\nSelect \"New\".\n\nInsert the following case sensitive value into the \"Name\" field: \"adminconsole.certLogin\".\n\nSelect \"Value\".\n\nEnter \"true\".\n\nClick \"Apply\".\n\nClick \"Save\".\n\nSelect Security >> SSL Certificate and Key management >> SSL Configurations >> Select CellDefaultSSLSettings >> Quality of Protection (QOP) settings.\n\nIn the \"Client Authentication\" drop-box, make sure \"Supported\" or \"Required\" is selected. \n\nClick \"Apply\".\n\nClick \"Save\".\n\nSave a backup copy and edit the \"Web.xml\" file as follows: /profiles//config/cells//applications/isclite.ear/deployments/isclite/isclite.war/WEB-INF/web.xml:\n--- Change: \n< security-constraint>\n\nProtected Area\n/\n--- So it becomes:\n< security-constraint>\n\nProtected Area\n/\n/logon.jsp\n/logonError.jsp\n--- Add these security constraints if not already present:\n\n\nfree pages\n/*.jsp\n/css/*\n/images/*\n/j_security_check\n\n \n--- Change:\nFORM\nto\nCLIENT-CERT\n\nSave the \"web.xml\" file.\n\nStop and restart the Deployment Manager. \n\nLog on to the admin console using your certificate.","ccis":["CCI-000187","CCI-000765","CCI-000767","CCI-001184","CCI-001953","CCI-001954","CCI-002009","CCI-002010","CCI-002011"]},{"vulnId":"V-255866","ruleId":"SV-255866r960993_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must provide security extensions to extend the SOAP protocol and provide secure authentication when accessing sensitive data.","description":"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. \n\nMany 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.","checkContent":"Review System Security Plan documentation.\n\nInterview the system administrator.\n\nIdentify any application web service providers and the secure authentication requirements for each service provider. \n\nFrom admin console, navigate to Applications >> All applications.\n\nClick on each application that is a web service provider where the security plan specifies security extensions are to be applied. \n\nNavigate to \"Service provider policy sets and bindings\".\n\nVerify that any web service providers that are required to have security extensions applied as per the security plan have a policy attached.\n\nIf \"Attached policy set\" column displays none, but the System Security Plan specifies security extensions as required, this is a finding.","fixText":"To attach policy sets for your service providers: \nFrom admin console, navigate to Applications >> All applications >> [application]. \n\nFor each application that is a web service provider and requires secure authentication, click on \"Service provider policy sets and bindings.\"\n\nClick button on the \"Select\" column to select a resource. \n\nClick on \"Attach Policy Set\" drop down.\n\nSelect policy set that best matches the provider environment.\n\nClick button on the \"Select\" column to select the same resource.\n\nClick on the \"Assign binding\" drop down.\n\nSelect a binding that best matches the environment.\n\nClick \"Save\".\n\nRestart DMGR and resync the JVMs.","ccis":["CCI-001941"]},{"vulnId":"V-255867","ruleId":"SV-255867r960993_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must provide security extensions to extend the SOAP protocol and provide secure authentication when accessing sensitive data.","description":"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. \n\nMany 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.","checkContent":"Review System Security Plan documentation.\n\nInterview the system administrator.\n\nIdentify any application web service clients.\n\nIdentify the secure authentication requirements for each client.\n\nFrom admin console, navigate to Applications >> All applications.\n\nClick on each application that is a web service client where the security plan specifies security extensions are to be applied.\n\nNavigate to \"Service client policy sets and bindings\".\n\nVerify that any web service clients that are required to have security extensions applied as per the security plan have a policy attached.\n\nIf \"Attached policy set\" column displays none, but the System Security Plan specifies security extensions as required, this is a finding.","fixText":"To attach policy sets for your service clients: \nFrom admin console, navigate to Applications >> All applications >> [application]. \n\nFor each application that is a web service client and requires secure authentication, click on \"Service client policy sets and bindings.\"\n\nClick button on the \"Select\" column to select a resource. \n\nClick on \"Attach Client Policy Set\" drop down.\n\nSelect policy set that best matches the environment.\n\nClick button on the \"Select\" column to select the same resource.\n\nClick on the \"Assign binding\" drop down.\n\nSelect a binding that best matches the environment.\n\nClick \"Save\".\n\nRestart DMGR and resync the JVMs.","ccis":["CCI-001941"]},{"vulnId":"V-255868","ruleId":"SV-255868r961863_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must authenticate all network-connected endpoint devices before establishing any connection.","description":"Device authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device.\n\nDevice authentication is accomplished via the use of certificates and protocols such as SSL mutual authentication.\n\nDevice 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.\n\nNote: 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= is used.\n\nhttps://www.ibm.com/support/knowledgecenter/prodconn_1.0.0/com.ibm.scenarios.wmqwassecure.doc/topics/implementing.htm?cp=SSEQTP_8.0.0\n\nSatisfies: SRG-APP-000394-AS-000241, SRG-APP-000177-AS-000126","checkContent":"Review System Security Plan documentation.\n\nIdentify mutual authentication connection requirements.\n\nFrom the admin console, navigate to Security >> SSL Certificate and Key Management >> SSL Configuration.\n\nSelect each [NodeDefaultSSLSettings] then go to Quality of Protection (QoP) Settings.\n\nIf \"Client authentication\" is not set according to the security plan, this is a finding.","fixText":"From the admin console, navigate to Security >> SSL Certificate and Key Management >> SSL Configuration.\n\nFor each [NodeDefaultSSLSettings] select Quality of Protection (QoP) Settings.\n\nSet \"Client authentication\" according to the security plan.","ccis":["CCI-000187","CCI-001958","CCI-000366"]},{"vulnId":"V-255869","ruleId":"SV-255869r961863_rule","severity":"medium","ruleTitle":"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.","description":"Device authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device.\n\nBidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk.\n\nDevice 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.\n\nBecause 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.\n\nNote: 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= is used.","checkContent":"Review System Security Plan documentation.\n\nIdentify mutual authentication connection requirements.\n\nFrom the admin console, navigate to Security >> SSL Certificate and Key Management >> SSL Configuration.\n\nSelect each [NodeDefaultSSLSettings] then go to Quality of Protection (QoP) Settings.\n\nIf \"Client authentication\" is not set according to the security plan, this is a finding.\n\nNote: 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= is used.","fixText":"From the admin console, navigate to Security >> SSL Certificate and Key Management >> SSL Configuration.\n\nFor each [NodeDefaultSSLSettings] select Quality of Protection (QoP) Settings.\n\nSet \"Client authentication\" according to the security plan.","ccis":["CCI-001967","CCI-000366"]},{"vulnId":"V-255870","ruleId":"SV-255870r961029_rule","severity":"high","ruleTitle":"The WebSphere Application Server application security must be enabled for each security domain except for publicly available applications specified in the System Security Plan.","description":"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.","checkContent":"Review System Security Plan documentation.\n\nIdentify any publicly available applications. These are applications available to the public that do not require authentication to access (e.g., recruiting websites).\n\nIf such applications exist on the system and are specifically allowed according to the security plan, this requirement is NA for those applications only.\n\nNavigate to security >> security domains.\n\nClick through each security domain.\n\nIf \"Customize for this domain\" is checked for Application Security under the Security Attributes, but \"Enable application security\" is not checked, this is a finding.","fixText":"Navigate to security >> security domains.\n\nClick through each security domain.\n\nIf \"Customize for this domain\" is checked for Application Security under the Security Attributes, but \"Enable application security\" is not checked, check \"Enable application security\".\n\nExpand \"show\" to find all affected nodes and servers.\n\nClick \"OK\".\n\nClick \"Save\".\n\nSynchronize the changes.\n\nRestart all affected nodes and servers.","ccis":["CCI-000197"]},{"vulnId":"V-255871","ruleId":"SV-255871r961029_rule","severity":"high","ruleTitle":"The WebSphere Application Server secure LDAP (LDAPS) must be used for authentication.","description":"Passwords need to be protected at all times, and encryption is the standard method for protecting passwords during transmission. \n\nApplication 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. \n\nTo 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.\n\nSatisfies: SRG-APP-000172-AS-000121, SRG-APP-000172-AS-000120","checkContent":"In the administrative console, click Security >> Global security.\n\nUnder \"User account repository\", click \"Configure\" for the \"Standalone LDAP registry\", on \"Standalone LDAP registry\" panel.\n\nIf the \"SSL\" flag is not enabled, this is a finding.","fixText":"In the administrative console, click Security >> Global security.\n\nUnder User account repository, click the \"Available realm definitions\" drop-down list.\n\nSelect Standalone LDAP registry.\n\nClick \"Configure\".\n\nClick \"SSL enabled\".\n\nClick \"OK\".\n\nOn Global security panel, click \"Set as current\".\n\nClick \"Apply\".\n\nClick \"Save\".\n\nTo ensure an error-free operation for this step, you need to first extract to a file the Signer certificate of the LDAP and send that file to the WebSphere Application Server machine. You can then add the certificate to the trust store being defined for the LDAP. In this way, you are assured that the remaining actions for this step will be successful.","ccis":["CCI-000197"]},{"vulnId":"V-255872","ruleId":"SV-255872r961521_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must prohibit the use of cached authenticators after an organization-defined time period.","description":"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.","checkContent":"Review System Security Plan documentation.\n\nIdentify the cache timeout parameters for authentication.\n\nStandard value for admin timeout is 10 minutes; however, the ISSO may allow a case by case exception based on operational requirements.\n\nFrom the admin console, navigate to Security >> Global Security >> Authentication cache settings.\n\nIf \"Enable authentication cache\" check box is set and \"Cache timeout\" is larger than the parameters specified in the security plan, this is a finding.","fixText":"From the admin console, navigate to Security >> Global Security >> Authentication.\n\nClick on \"Authentication cache\" settings.\n\nEnter the settings for \"Cache timeout\" in accordance with the parameters defined in the Systems Security Plan.","ccis":["CCI-002007"]},{"vulnId":"V-255873","ruleId":"SV-255873r961041_rule","severity":"high","ruleTitle":"The WebSphere Application Server default keystore passwords must be changed.","description":"The cornerstone of the PKI is the private key used to encrypt or digitally sign information. \n\nIf 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. \n\nBoth 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.","checkContent":"Review System Security Plan documentation.\n\nInterview the system administrator.\n\nIdentify installation folders and DMGR info.\n\nAccess the DMGR system via the OS.\n\nStop the DMGR processes. This will shut down the application server so plan outages accordingly. \n\nThe default file paths and DefaultMgr installation names are provided below, adjust paths, and dmgr name if your installation differs from the default.\n\nFor UNIX systems:\ncd /opt/IBM/Websphere/Profiles//logs/dmgr/\n\n-stopManager.sh -user [admin user name] - password [admin user password]\n-archive the SystemOut*.log files. (Copy to another location)\n-startManager.sh\n-grep -i cwpki0041w SystemOut.log\n\nFor Windows:\ncd C:\\program files\\IBM\\Websphere\\Profiles\\\\logs\\dmgr\\\n\n-stopManager.exe -user [admin user name] - password [admin user password]\n-archive the SystemOut*.log files. (Copy to another location)\n-startManager.exe\n-findstr -I cwpki0041w systemout.log\n\nIf the results include: \n\"CWPKI0041W: One or more keystores are using the default password\", this is a finding.","fixText":"Navigate to Security >> SSL Certificate and Key Management >> Key stores and certificates.\n\nSelect a keystore from the list.\n\nClick \"Change Password\".\n\nEnter the new password and password confirmation.\n\nClick \"OK\".\n\nRepeat for every keystore in the list.\n\nSynchronize changes to all nodes.","ccis":["CCI-000186"]},{"vulnId":"V-255874","ruleId":"SV-255874r961044_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must use signer for DoD-issued certificates.","description":"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.\n\nApplication servers must provide the capability to utilize and meet requirements of the DoD Enterprise PKI infrastructure for application authentication.","checkContent":"Navigate to Security >> SSl certificate and key management >> SSL Configurations >> CellDefaultSSLSettings >> KeyStores and certificates.\n\nClick on cell default trust store.\n\nClick on \"Signer Certificates\".\n\nIf no DoD root or intermediate certificates are present, this is a finding.","fixText":"Obtain the signer certificate either as Base 64 encoded ASCII file, or as binary DER data.\n\nNavigate to Security >> SSl certificate and key management >> SSL Configurations >> CellDefaultSSLSettings >> key stores and certificates.\n\nClick on cell default trust store.\n\nClick on \"Signer Certificates\".\n\nClick \"Add\".\n\nEnter a new alias for the signer, and the location of the file that stores signer certificate.\n\nFor \"Data type\", choose the type appropriate for the file, either Base64-encoded ASCII data file, or binary DER data.\n\nClick \"OK\".","ccis":["CCI-000187"]},{"vulnId":"V-255875","ruleId":"SV-255875r1193273_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must utilize FIPS 140-2-approved encryption modules when authenticating users and processes.","description":"Encryption is only as good as the encryption modules in use. Unapproved cryptographic module algorithms cannot be verified or be relied upon to provide confidentiality or integrity, and DOD data may be compromised due to weak algorithms. The use of TLS provides confidentiality of data in transit between the application server and client. FIPS 140-2-approved TLS versions include TLS V1.0 or greater. \n\nTLS must be enabled and non-FIPS-approved SSL versions must be disabled. NIST SP 800-52 specifies the preferred configurations for government systems.","checkContent":"Note: If FIPS 140-3 is configured in WBSP-AS-001770, this is not applicable.\n\nFrom the administrative console, click Security >> SSL certificate and key management >> Manage FIPS.\n\nIf \"Enable FIPS 140-2\" is not selected, this is a finding.","fixText":"From administrative console, click Security >> SSL certificate and key management >> Manage FIPS.\n\nCheck \"Enable FIPS 140-2\".\n\nClick \"Save\".\n\nSynchronize with the nodes.\n\nRestart all the JVMs.","ccis":["CCI-000803","CCI-001188","CCI-002418","CCI-002421","CCI-002422","CCI-002450"]},{"vulnId":"V-255876","ruleId":"SV-255876r961527_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must accept Personal Identity Verification (PIV) credentials from other federal agencies to access the management interface.","description":"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.\n\nAccess may be denied to authorized users if federal agency PIV credentials are not accepted to access the management interface.","checkContent":"Check that the admin console is enabled for client certificate logon.\n\nIn the Deployment Manager, check the file on: /profiles//config/cells//applications/isclite.ear/deployments/isclite/isclite.war/WEB-INF/web.xml.\n\nIf the XML element \"FORM\" is present, this is a finding.","fixText":"From the admin console, select System Administration >> Deployment Manager >> Java and Process Management >> Process definition >> Java Virtual Machine >> Custom Properties.\n\nSelect \"New\".\n\nInsert the following case sensitive value into the \"Name\" field: \"adminconsole.certLogin\"\n\nSelect \"Value\".\n\nEnter \"true\".\n\nClick \"Apply\".\n\nClick \"Save\".\n\nSelect Security >> SSL Certificate and Key management >> SSL Configurations >> Select CellDefaultSSLSettings >> Quality of Protection (QOP) settings.\n\nIn the \"Client Authentication\" drop box, make sure \"Supported\" or \"Required\" is selected. \n\nClick \"Apply\".\n\nClick \"Save\".\n\nSave a backup copy and edit the Web.xml file as follows: /profiles//config/cells//applications/isclite.ear/deployments/isclite/isclite.war/WEB-INF/web.xml:\n--- Change: \n< security-constraint>\n\nProtected Area\n/\n--- So it becomes:\n< security-constraint>\n\nProtected Area\n/\n/logon.jsp\n/logonError.jsp\n--- Add these security constraints if not already present:\n\n\nfree pages\n/*.jsp\n/css/*\n/images/*\n/j_security_check\n\n \n--- Change:\nFORM\nto\nCLIENT-CERT\n\nSave the \"web.xml\" file.\n\nStop and restart the Deployment Manager. \n\nLog on to the admin console using your certificate.","ccis":["CCI-002009"]},{"vulnId":"V-255877","ruleId":"SV-255877r1137585_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must use DoD-approved Signer Certificates.","description":"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.","checkContent":"From administrative console, navigate to Security >> SSL Certificates and Key Management >> KeyStores and Certificates.\n\nFor each keystore, click on \"Signer Certificates\".\n\nIf any of the certificates are not issued by an approved DoD CA, this is a finding.","fixText":"Utilize DoD certificates that have been issued by a DoD PKI CA.\n\nTo replace a non-DoD PKI-established certificate:\nFrom the administrative console, navigate to Security >> SSL Certificates and Key Management >> KeyStores and Certificates.\n\nFor each keystore that requires the change:\nImport a new certificate by clicking \"Import\".\n\nClick \"keystore\" file.\n\nEnter the location of the new certificate.\n\nSpecify the type of keystore and keystore password.\n\nSpecify alias information.\n\nClick \"Apply\". \n\nAfter the certificate is imported, click on \"Replace\" to replace the original certificate with the new certificate.","ccis":["CCI-002450"]},{"vulnId":"V-255878","ruleId":"SV-255878r1137579_rule","severity":"medium","ruleTitle":"The WebSphere Application Servers must not be in the DMZ.","description":"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.\n\nApplication 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.\n\nThe 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.","checkContent":"Review System Security Plan and system architecture documentation.\n\nInterview the system administrator.\n\nIdentify any DMZ networks.\n\nIf there are no DMZ networks in the application server's architecture, this requirement is NA.\n\nIn the administrative console, click Servers >> Server Types >> WebSphere application servers.\n\nFor each application server, review the \"hostname\" field and determine if the application server has a DMZ network IP address. \n\nIf any application server is hosted in the DMZ network, this is a finding.","fixText":"If any application server host is installed in the DMZ, reassign IP address to a secured network and reconfigure the application server.","ccis":["CCI-001082"]},{"vulnId":"V-255879","ruleId":"SV-255879r1043178_rule","severity":"medium","ruleTitle":"The WebSphere Application Server DoD root CAs must be in the trust store.","description":"This control focuses on communications protection at the session, versus packet level.\n\nAt 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.\n\nApplication servers must provide the capability to perform mutual authentication. Mutual authentication is when both the client and the server authenticate each other.","checkContent":"Review System Security Plan documentation for location of the trust store used to store the signers of the administrators certificates. By default this is \"cellDefaultTrustStore\".\n\nNavigate to Security >> SSL certificate and key management >> Keystore and certificates.\n\nClick on the trust store used to store the signers of the administrators' certificates (root CA). (The default is cellDefaultTrustStore).\n\nClick on \"Signer Certificates\".\n\nIf there are no DoD signer certificates, this is a finding.","fixText":"Navigate to Security >> SSL certificate and key management >> Keystore and certificates.\n\nClick on the trust store used to store the signers of the administrators' certificates. (The default is cellDefaultTrustStore). \n\nClick on \"Signer Certificates\".\n\nClick \"Add\".\n\nFollow the instructions to import the signer from a file.\n\nClick \"OK\".","ccis":["CCI-001184"]},{"vulnId":"V-255880","ruleId":"SV-255880r961596_rule","severity":"medium","ruleTitle":"The WebSphere Application Server personal certificates in all keystores must be issued by an approved DoD CA.","description":"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.\n\nThe 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.","checkContent":"Review System Security Plan documentation for a list of DoD-approved CAs. \n\nFrom administrative console, navigate to Security >> SSL Certificates and Key Management >> KeyStores and Certificates.\n\nFor each keystore, click on \"Personal Certificates\".\n\nIf any of the certificates are not issued by an approved DoD CA, this is a finding.","fixText":"Utilize DoD certificates that have been issued by an approved DoD PKI CA.\n\nTo replace a non-DoD PKI-established certificate:\nFrom the administrative console, navigate to Security >> SSL Certificates and Key Management >> KeyStores and Certificates.\n\nFor each keystores that requires the change:\nImport a new certificate by clicking \"Import\".\n\nClick \"keystore\" file.\n\nEnter the location of the new certificate.\n\nSpecify the type of keystore and keystore password.\n\nSpecify alias information.\n\nClick \"Apply\".\n\nAfter the certificate is imported, click on \"Replace\" to replace the original certificate with the new certificate.","ccis":["CCI-002470"]},{"vulnId":"V-255881","ruleId":"SV-255881r961122_rule","severity":"low","ruleTitle":"The WebSphere Application Server must be configured to perform complete application deployments when using A/B clusters.","description":"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.\n\nWhen 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.\n\nThe 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.","checkContent":"Review System Security Plan documentation to determine if the server is configured to use A/B clusters.\n\nIf the System Security Plan does not specify utilizing A/B clusters, the requirement is NA.\n\nFrom the administration console, select WebSphere application server clusters.\n\nSelect each cluster name.\n\nSelect cluster members.\n\nIf the weight of any cluster member is \"0\", this is a finding.","fixText":"From the administration console, select WebSphere application server clusters.\n\nSelect each cluster name.\n\nSelect cluster members >> Details.\n\nSet all cluster members configured weight to a non-zero value.","ccis":["CCI-001190"]},{"vulnId":"V-255882","ruleId":"SV-255882r961122_rule","severity":"low","ruleTitle":"The WebSphere Application servers with an RMF categorization of high must be in a high-availability (HA) cluster.","description":"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.\n\nFailure 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.\n\nClustering of multiple application servers is a common approach to providing fail-safe application availability when system MAC and confidentiality levels require redundancy.\n\nSatisfies: SRG-APP-000225-AS-000154, SRG-APP-000435-AS-000069","checkContent":"Review Systems Security Plan and identify system categorization.\n\nIf the system is not categorized as HIGH, this requirement is NA.\n\nIn the administrative console, click Servers >> Clusters >> WebSphere application server clusters.\n\nEnsure you have a cluster defined, if not this is a finding.","fixText":"In the administrative console, click Servers >> Clusters >> WebSphere application server clusters >> New.\n\nSpecify a name for the cluster.\n\nClick \"Next\".\n\nSpecify the name of the first cluster member.\n\nSelect the node on which you want this cluster member to reside, leave remaining fields as default.\n\nClick \"Next\".\n\nCreate additional cluster members as needed (give unique name for each member and click \"Add Member\"), when finished adding members click \"Next\".\n\nClick \"Finish\" to create the cluster.\n\nClick \"Save\".\n\nRefer to vendor documentation that provides direction on the creation of clusters for specific details.\n\nRestart DMGR and sync all JVMs.","ccis":["CCI-001190","CCI-002385"]},{"vulnId":"V-255883","ruleId":"SV-255883r1067567_rule","severity":"low","ruleTitle":"The WebSphere Application Server must not generate LTPA keys automatically.","description":"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.","checkContent":"If LTPA is not utilized, this is not applicable.\n\nRequest the documented process to manually regenerate the LTPA keys.\n\nThe time period for regeneration must be defined, documented, and accepted by the ISSO but must be performed at least annually.\n\nNavigate to Security >> SSL Certificate and Key Management >> Key set groups >> Cell LTPAKeySetGroup.\n\nIf automatically generate keys is checked, this is a finding.","fixText":"Navigate to Security >> SSL Certificate and Key Management >> Key set groups >> Cell LTPAKeySetGroup.\n\nUncheck automatically generate keys.\n\nClick \"OK\".\n\nClick \"Save\".\n\nRestart the \"Deployment Manager\".","ccis":["CCI-002475"]},{"vulnId":"V-255884","ruleId":"SV-255884r1067567_rule","severity":"low","ruleTitle":"The WebSphere Application Server must periodically regenerate LTPA keys.","description":"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.\n\nNote: 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","checkContent":"If LTPA is not utilized, this is not applicable.\n\nRequest the documented process to manually regenerate the LTPA keys.\n\nThe time period for regeneration must be defined, documented and accepted by the ISSO but must be performed at least annually. \n\nReview documented process for LTPA key regeneration.\n\nIf there is no process to regenerate LTPA keys periodically, this is a finding.","fixText":"These steps must be documented and then executed during the down time scheduled for periodic LTPA key regeneration.\n\nThe time period must be defined, documented and accepted by the ISSO but must be performed at least annually.\n\nNavigate to Security >> SSL Certificate and Key Management >> Key set groups.\n\nCheck \"CellLTPAKeySetGroup\".\n\nClick \"Generate Keys\".\n\nClick \"Save\".\n\nThen synchronize the changes to all nodes.","ccis":["CCI-002475"]},{"vulnId":"V-255885","ruleId":"SV-255885r961620_rule","severity":"medium","ruleTitle":"The WebSphere Application Server high availability applications must be installed on a cluster.","description":"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.\n\nThere 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.","checkContent":"Review Systems Security Plan and identify system categorization.\n\nIf the system is not categorized as HIGH, this requirement is NA.\n\nIdentify HA applications installed on the server.\n\nVerify applications defined as requiring HA protections are running on a cluster. \n\nFrom the admin console, navigate to Application >> All Applications >> [application name] >> Target specific application status.\n\nIf the target application has been designated as an HA application but is not running on a cluster, this is a finding.","fixText":"To create a cluster, navigate to Servers >> Clusters >> WebSphere Application Server Clusters >> New and follow the wizard.\n\nAfter cluster creation, re-install your application to the cluster.\n\nRefer to product documentation for specific details on how to create and manage WebSphere clusters.","ccis":["CCI-002385"]},{"vulnId":"V-255886","ruleId":"SV-255886r961620_rule","severity":"low","ruleTitle":"The WebSphere Application Server memory session settings must be defined according to application load requirements.","description":"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.\n\nThere 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.","checkContent":"Review System Security Plan documentation.\n\nIdentify the application load requirements defined by system owner.\n\nRegular application user session timeout values are defined at the DoD level at 20 minutes.\n\nAn ISSO risk acceptance is required to deviate from that value.\n\nIf session timeout values are not set to \"20\" and an ISSO risk acceptance is provided, this is not a finding.\n\nFrom the admin console, navigate to Servers >> all servers >> [web application server] >> Session management.\n\nFor every [web application server], verify maximum in-memory session count.\n\nVerify \"allow overflow\" and \"session timeout\" are set according to application load requirements.\n\nIf they are not set according to application load requirements, this is a finding.","fixText":"From the admin console navigate to Servers >> all servers >> [web application server] >> Session management.\n\nFor every [web application server], set the \"Maximum in-memory session count\", \"allow overflow\", and \"session timeout\" values according to your organizational requirements.","ccis":["CCI-002385"]},{"vulnId":"V-255887","ruleId":"SV-255887r961620_rule","severity":"medium","ruleTitle":"The WebSphere Application Server thread pool size must be defined according to application load requirements.","description":"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.","checkContent":"Review System Security Plan documentation.\n\nIdentify the application thread pool size requirements defined by system owner. \n\nFrom the admin console navigate to Servers >> all servers >> [server name] >> ThreadPools.\n\nVerify thread pool size according to specifications in documentation.\n\nIf the maximum size for each threadpool is set too large, and not set according to application requirements, this is a finding.","fixText":"Perform loading for your application to determine the required thread pool sizes.\n\nTo set thread pool size: \nFrom the admin console >> Servers >> all servers >> [server name] >> Additional Properties >> Select Thread Pools.\n\nSet the thread pool size for each threadpool.","ccis":["CCI-002385"]},{"vulnId":"V-255888","ruleId":"SV-255888r961632_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must remove all export ciphers to protect the confidentiality and integrity of transmitted information.","description":"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","checkContent":"From the administrative console, navigate to Security >> SSL certificate and key management >> SSL configurations >> [Name] >> for each SSL Configuration\n\nSelect \"Quality of protection (QoP) settings\".\n\nUnder \"Cipher suite\" settings, if any of the ciphers contained in the \"Selected ciphers\" box\" contain \"EXPORT\" in their name, this is a finding.","fixText":"From the administrative console, navigate to Security >> SSL certificate and key management >> SSL configurations >> [Name] >> for each SSL configuration\n\nSelect \"Quality of protection (QoP) settings\" under \"Cipher suite\" settings.\n\nIdentify any ciphers that include \"EXPORT\" in their name.\n\nRemove the cipher by selecting the cipher.\n\nClick \"Remove\" button.\n\nClick \"OK\".\n\nRecycle the DMGR and sync the JVMs.","ccis":["CCI-002418"]},{"vulnId":"V-255889","ruleId":"SV-255889r961863_rule","severity":"medium","ruleTitle":"The WebSphere Application Server distribution and consistency services (DCS) transport links must be encrypted.","description":"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. \n\nCore 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.\n\nBe aware that DCS always authenticates messages when global security is enabled. Once the transport is encrypted, you then have a highly secure channel.\n\nOnce 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.","checkContent":"From the admin console navigate to Servers >> Core groups.\n\nFor every Core Group listed, select the Core Group [CoreGroup Name]. \n\nUnder \"Transport Type\", select the \"Channel Framework\" button.\n\nIf the \"transport chain\" drop down box is not set to \"DCS-Secure\", this is a finding.","fixText":"From the admin console navigate to Core groups >> for every Core Group listed.\n\nSelect the [Core Group Name].\n\nUnder \"Transport\" type, select \"CHANNEL_FRAMEWORK\" button.\n\nIn the \"Transport chain\" drop down box set to \"DCS-SECURE\".\n\nClick \"Save\".\n\nSync the configuration.","ccis":["CCI-002420","CCI-000366"]},{"vulnId":"V-255890","ruleId":"SV-255890r1137581_rule","severity":"medium","ruleTitle":"The WebSphere Application Server plugin must be configured to use HTTPS only.","description":"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.","checkContent":"From the admin console, navigate to Servers >> Server Types >> WebSphere Application Servers >> select each server (server name) >> Web Container Settings >> Web container transport chains. \n\nVerify both \"WCInboundDefault\" and the \"HttpQueueInboundDefault\" transport chains are disabled.\n\nIf they are not disabled, this is a finding.","fixText":"From the admin console, navigate to Servers >> Server Types >> WebSphere Application Servers >> select each server (server name) >> Web Container Settings >> Web container transport chains. \n\nSelect the \"WCInboundDefault\" and the \"HttpQueueInboundDefault\" transport chains and disable them.\n\nClick \"Apply\".\n\nClick \"Save\".\n\nRestart the DMGR and resynch the JVMs.","ccis":["CCI-002421"]},{"vulnId":"V-255891","ruleId":"SV-255891r961677_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must remove organization-defined software components after updated versions have been installed.","description":"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.","checkContent":"Review System Security Plan and system documentation to locate the \"IBM InstallationManager\" folder.\n\nDefault locations are:\nUNIX:\n/opt/InstallationManager\n\nWindows:\nC:\\Program Files\\InstallationManager\n\nUNIX:\n/eclipse/tools/imcl -c\n\nSelect \"P\" preferences.\nSelect \"3\" Files for rollback.\n\nWindows:\n\\eclipse\\tools\\imcl.exe -c\n\nSelect \"P\" preferences.\nSelect \"3\" Files for rollback.\n\nIf \"Save files for rollback\" is checked, this is a finding.","fixText":"Review System Security Plan and system documentation to locate the \"IBM InstallationManager\" folder.\n\nDefault locations are:\nUNIX:\n/opt/InstallationManager\n\nWindows:\nC:\\Program Files\\InstallationManager\n\nUNIX:\n/eclipse/tools/imcl -c\n\nSelect \"P\" preferences. \nSelect \"3\" Files for rollback.\nEnter \"1\" to deselect.\nEnter \"A\" for apply.\nEnter \"R\" to return to Main Menu.\n\nWindows:\n\\eclipse\\tools\\imcl.exe -c\n\nSelect \"P\" preferences.\nSelect \"3\" Files for rollback.\nEnter \"1\" to deselect.\nEnter \"A\" for apply.\nEnter \"R\" to return to Main Menu.","ccis":["CCI-002617"]},{"vulnId":"V-255892","ruleId":"SV-255892r1137612_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must apply the latest security fixes.","description":"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","checkContent":"Use the admin console to determine the WebSphere version.\n\nReview patch level and fix pack.\n\nIf the most recent patches/fix packs have not been applied, this is a finding.","fixText":"Obtain WebSphere product security and patch support.\n\nTest and apply the latest applicable WebSphere security fixes.","ccis":["CCI-002605"]},{"vulnId":"V-255893","ruleId":"SV-255893r1137612_rule","severity":"medium","ruleTitle":"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).","description":"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.","checkContent":"From the admin console, click on \"welcome\".\n\nUnder Suite Name, locate \"WebSphere Application Server\".\n\nView the \"version\". \n\nAccess IBM support website: https://www.ibm.com/support\n\nIdentify the most recent patch/fix version available for the WebSphere Traditional Application Server (not the Liberty version).\n\nIf the most recent patches/fix packs have not been applied, this is a finding.","fixText":"Sign up to receive WebSphere security bulletins at the IBM website.\n\nMonitor IAVMs, CTOs, and DTMs for update notices affecting WebSphere.\n\nObtain WebSphere product security and patch support.\n\nTest and apply the latest applicable WebSphere security fixes.","ccis":["CCI-002605"]},{"vulnId":"V-283677","ruleId":"SV-283677r1193276_rule","severity":"medium","ruleTitle":"The WebSphere Application Server must use FIPS 140-3-approved encryption modules when authenticating users and processes.","description":"Encryption is only as good as the encryption modules in use. Unapproved cryptographic module algorithms cannot be verified and cannot be relied upon to provide confidentiality or integrity, and DOD data may be compromised due to weak algorithms. The use of TLS provides confidentiality of data in transit between the application server and client. FIPS 140-3-approved TLS versions include TLS V1.0 or greater. \n\nTLS must be enabled and non-FIPS-approved SSL versions must be disabled. NIST SP 800-52 specifies the preferred configurations for government systems.","checkContent":"Note: If FIPS 140-2 is configured in WBSP-AS-001290, this is not applicable. This is allowed until 21 September 2026. If FIPS 140-2 is still in use after this date, this is a finding.\n\nFrom administrative console, click Security >> SSL certificate and key management >> Manage FIPS.\n\nIf \"Enable FIPS 140-3\" is not selected, this is a finding.","fixText":"Implementation for Cell Profile (Network Deployment):\n\n1. Back up the existing configuration:\n\nbackupConfig.sh \n\n2. Stop all servers except the deployment manager:\n\n- Stop all node agents and application servers.\n- Keep only the deployment manager running.\n\n3. Enable FIPS 140-3.\n\nOption A - Using Administrative Console:\n1. Click Security >> SSL certificate and key management >> Manage FIPS.\n\n\n2. Select \"Enable FIPS 140-3\".\n3. Click \"Apply\".\n\nOption B - Using Admin Command:\nAdminTask.enableFips('[-enableFips true -fipsLevel FIPS140-3 ]')\n\n1. Stop the deployment manager.\n\n2. Restart the deployment manager.\n\n3. Synchronize nodes. On each node, run:\n\nsyncNode.sh \n\n4. Start node agents and servers\n\nImplementation for Standalone Profile:\n1. Back up the existing configuration:\n\nbackupConfig.sh \n\n2. Enable FIPS 140-3.\n\nOption A - Using Administrative Console:\n1. Click Security >> SSL certificate and key management >> Manage FIPS.\n\n2. Select \"Enable FIPS 140-3\".\n\n3. Click \"Apply\".\n\nOption B - Using Admin Command:\nAdminTask.enableFips('[-enableFips true -fipsLevel FIPS140-3 ]')\n\nFor both methods, restart the application server.","ccis":["CCI-000803","CCI-001188","CCI-002418","CCI-002421","CCI-002422","CCI-002450"]}]}