Oracle WebLogic Server 12c Security Technical Implementation Guide

V1R5 2018-08-30       U_Oracle_WebLogic_Server_12c_STIG_V1R5_Manual-xccdf.xml
V1R4 2018-01-02       U_Oracle_WebLogic_Server_12c_STIG_V1R4_Manual-xccdf.xml
Developed by Oracle in coordination with DISA for use in the DoD.
Comparison
All 72
No Change 72
Updated 0
Added 0
Removed 0
V-56205 No Change
Findings ID: WBLC-01-000009 Rule ID: SV-70459r1_rule Severity: medium CCI: CCI-000068

Discussion

Remote management access is accomplished by leveraging common communication protocols and establishing a remote connection to the application server via a network for the purposes of managing the application server. If cryptography is not used, then the session data traversing the remote connection could be intercepted and compromised.

Types of management interfaces utilized by an application server include web-based HTTPS interfaces as well as command line-based management interfaces. All application server management interfaces must utilize cryptographic encryption.

Checks

1. Access AC
2. From 'Domain Structure', select 'Environment' -> 'Servers'
3. From the list of servers, select one which needs check for SSL configuration verification
4. From 'Configuration' tab -> 'General' tab, ensure 'Listen Port Enabled' checkbox is deselected
5. Ensure 'SSL Listen Port Enabled' checkbox is selected and a valid port number is in 'SSL Listen Port' field, e.g., 7002
6. From 'Configuration' tab -> 'Keystores' tab, ensure 'Custom Identity and Java Standard Trust' is selected in 'Keystores' section
7. Repeat steps 3-6 for all servers requiring SSL configuration checking

If 'Listen Port Enabled' is selected, this is a finding.

If 'SSL Listen Port Enabled' is not selected, this is a finding.

If the keystore is not using the 'Custom Identity and Java Standard Trust' setting, this is a finding.

Fix

1. Obtain an identity (private key and digital certificates) and trust (certificates of trusted certificate authorities) to configure on the server
2. Create Identity keystore and load private key and certificate using ImportPrivateKey java utility, example:
$ java utils.ImportPrivateKey -certfile <cert_file> -keyfile <private_key_file> [-keyfilepass <private_key_password>] -keystore <keystore> -storepass <storepass> [-storetype <storetype>] -alias <alias> [-keypass <keypass>]
3. Access AC
4. Utilize 'Change Center' to create a new change session
5. From 'Domain Structure', select 'Environment' -> 'Servers'
6. From the list of servers, select one which needs SSL set up
7. From 'Configuration' tab -> 'General' tab, deselect 'Listen Port Enabled' checkbox
8. Select 'SSL Listen Port Enabled' checkbox and enter a valid port number in 'SSL Listen Port' field, e.g., 7002
9. From 'Configuration' tab -> 'Keystores' tab, click 'Change' button in 'Keystores' section
10. From dropdown, select 'Custom Identity and Java Standard Trust' and click 'Save'
11. Enter the fully qualified path to Identity keystore, from step 2, in 'Custom Identity Keystore' field
12. Enter 'JKS' in the 'Custom Identity Keystore Type' field
13. Enter the Identity keystore password in 'Custom Identity Keystore Passphrase' and 'Confirm Custom Identity Keystore Passphrase' fields
14. Enter the Java Standard Trust keystore (cacerts) password in 'Java Standard Trust Keystore Passphrase' and 'Confirm Java Standard Trust Keystore Passphrase' fields
15. Leave all other fields blank and click 'Save'
16. From 'Configuration' tab -> 'SSL' tab, enter values from step 2 into corresponding fields, as follows:
- Enter <alias> into 'Private Key Alias'
- Enter <private_key_password> into 'Private Key Passphrase'
- Enter <private_key_password> into 'Confirm Private Key Passphrase'
17. Click 'Save', and from 'Change Center' click 'Activate Changes' to enable configuration changes
18. Repeat steps 4-17 for all servers requiring SSL configuration
19. From 'Domain Structure', select 'Environment' -> 'Servers', click 'Control' tab
20. Select checkbox for all servers configured in previous steps and click 'Restart SSL'
V-56207 No Change
Findings ID: WBLC-01-000010 Rule ID: SV-70461r1_rule Severity: medium CCI: CCI-001453

Discussion

Encryption is critical for protection of remote access sessions. If encryption is not being used for integrity, malicious users may gain the ability to modify the application server configuration. The use of cryptography for ensuring integrity of remote access sessions mitigates that risk.

Application servers utilize a web management interface and scripted commands when allowing remote access. Web access requires the use of SSL 3.0 or TLS 1.0 and scripted access requires using ssh or some other form of approved cryptography. Application servers must have a capability to enable a secure remote admin capability.

Checks

1. Access AC
2. From 'Domain Structure', select 'Environment' -> 'Servers'
3. From the list of servers, select one which needs check for SSL configuration verification
4. From 'Configuration' tab -> 'General' tab, ensure 'Listen Port Enabled' checkbox is deselected
5. Ensure 'SSL Listen Port Enabled' checkbox is selected and a valid port number is in 'SSL Listen Port' field, e.g., 7002
6. From 'Configuration' tab -> 'Keystores' tab, ensure 'Custom Identity and Java Standard Trust' is selected in 'Keystores' section
7. Repeat steps 3-6 for all servers requiring SSL configuration checking

If 'Listen Port Enabled' is selected, this is a finding.

If 'SSL Listen Port Enabled' is not selected, this is a finding.

If the keystore is not using the 'Custom Identity and Java Standard Trust' setting, this is a finding.

Fix

1. Obtain an identity (private key and digital certificates) and trust (certificates of trusted certificate authorities) to configure on the server
2. Create Identity keystore and load private key and certificate using ImportPrivateKey java utility, example:
$ java utils.ImportPrivateKey -certfile <cert_file> -keyfile <private_key_file> [-keyfilepass <private_key_password>] -keystore <keystore> -storepass <storepass> [-storetype <storetype>] -alias <alias> [-keypass <keypass>]
3. Access AC
4. Utilize 'Change Center' to create a new change session
5. From 'Domain Structure', select 'Environment' -> 'Servers'
6. From the list of servers, select one which needs SSL set up
7. From 'Configuration' tab -> 'General' tab, deselect 'Listen Port Enabled' checkbox
8. Select 'SSL Listen Port Enabled' checkbox and enter a valid port number in 'SSL Listen Port' field, e.g., 7002
9. From 'Configuration' tab -> 'Keystores' tab, click 'Change' button in 'Keystores' section
10. From dropdown, select 'Custom Identity and Java Standard Trust' and click 'Save'
11. Enter the fully qualified path to Identity keystore, from step 2, in 'Custom Identity Keystore' field
12. Enter 'JKS' in the 'Custom Identity Keystore Type' field
13. Enter the Identity keystore password in 'Custom Identity Keystore Passphrase' and 'Confirm Custom Identity Keystore Passphrase' fields
14. Enter the Java Standard Trust keystore (cacerts) password in 'Java Standard Trust Keystore Passphrase' and 'Confirm Java Standard Trust Keystore Passphrase' fields
15. Leave all other fields blank and click 'Save'
16. From 'Configuration' tab -> 'SSL' tab, enter values from step 2 into corresponding fields, as follows:
- Enter <alias> into 'Private Key Alias'
- Enter <private_key_password> into 'Private Key Passphrase'
- Enter <private_key_password> into 'Confirm Private Key Passphrase'
17. Click 'Save', and from 'Change Center' click 'Activate Changes' to enable configuration changes
18. Repeat steps 4-17 for all servers requiring SSL configuration
19. From 'Domain Structure', select 'Environment' -> 'Servers', click 'Control' tab
20. Select checkbox for all servers configured in previous steps and click 'Restart SSL'
V-56209 No Change
Findings ID: WBLC-01-000011 Rule ID: SV-70463r1_rule Severity: medium CCI: CCI-000067

Discussion

Remote network access is accomplished by leveraging common communication protocols and establishing a remote connection.

Application servers provide remote management access and need to provide the ability to facilitate the monitoring and control of remote user sessions. This includes the capability to directly trigger actions based on user activity or pass information to a separate application or entity that can then perform automated tasks based on the information.

Examples of automated mechanisms include but are not limited to: automated monitoring of log activity associated with remote access or process monitoring tools.

The application server must employ mechanisms that allow for monitoring and control of web-based and command line-based administrative remote sessions.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'JDBC Data Sources'
3. From the list of data sources, select the one named 'opss-audit-DBDS', which connects to the IAU_APPEND schema of the audit database. Note the value in the 'JNDI name' field.
4. To verify, select 'Configuration' tab -> 'Connection Pool' tab
5. Ensure the 'URL' and 'Properties' fields contain the correct connection values for the IAU_APPEND schema
6. To test, select 'Monitoring' tab, select a server from the list and click 'Test Data Source'. Ensure test was successful. Repeat for each server in the list.
7. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Security' -> 'Security Provider Configuration'
8. Beneath 'Audit Service' section, click 'Configure' button
9. Ensure 'Data Source JNDI Name' value matches the JNDI Name value from data source in step 3 above
10. Repeat steps 2-6 for data source named 'wls-wldf-storeDS' and WLS schema

If the data is not being stored for access by an external monitoring tool, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Services' -> 'Data Sources'
3. Utilize 'Change Center' to create a new change session
4. Click 'New' data source to create a new data source for the audit data store using schema IAU_APPEND
5. Enter database details and JNDI name, click through wizard
6. Select all servers and clusters available as targets to deploy this data source to
7. Finish creating the data source and record the JNDI name
8. Access EM
9. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Security' -> 'Security Provider Configuration'
10. Beneath 'Audit Service' section, click 'Configure' button
11. Set the values for the IAU_APPEND schema and save configuration
12. Repeat steps 2-7 for data source named 'wls-wldf-storeDS' and WLS schema
V-56211 No Change
Findings ID: WBLC-01-000013 Rule ID: SV-70465r1_rule Severity: medium CCI: CCI-001454

Discussion

Auditing must be utilized in order to track system activity, assist in diagnosing system issues and provide evidence needed for forensic investigations post security incident.

Remote access by administrators requires that the admin activity be audited.

Application servers provide a web- and command line-based remote management capability for managing the application server. Application servers must ensure that all actions related to administrative functionality such as application server configuration are logged.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Security' -> 'Audit Policy'
3. Select 'Oracle Platform Security Services' from the 'Audit Component Name' dropdown
4. Beneath 'Audit Policy Settings' section, ensure that the value 'Custom' is set in the 'Audit Level' dropdown
5. Beneath 'Audit Policy Settings' section, ensure that every checkbox is selected under the 'Select For Audit' column of the policy category table

If all auditable events for the 'Oracle Platform Security Services' audit component are not selected, then this is a finding.

Fix

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Security' -> 'Audit Policy'
3. Select 'Oracle Platform Security Services' from the 'Audit Component Name' dropdown
4. Beneath 'Audit Policy Settings' section, select 'Custom' from the 'Audit Level' dropdown
5. Once it is enabled, click the 'Audit All Events' button and ensure every checkbox is selected under the 'Select For Audit' column of the policy category table. Click 'Apply'
V-56213 No Change
Findings ID: WBLC-01-000014 Rule ID: SV-70467r2_rule Severity: medium CCI: CCI-001436

Discussion

Some networking protocols may not meet organizational security requirements to protect data and components.

Application servers natively host a number of various features such as management interfaces, httpd servers, and message queues. These features all run on TCPIP ports. This creates the potential that the vendor may choose to utilize port numbers or network services that have been deemed unusable by the organization. The application server must have the capability to both reconfigure and disable the assigned ports without adversely impacting application server operation capabilities. For a list of approved ports and protocols, reference the DoD ports and protocols web site at https://iase.disa.mil/ppsm/Pages/index.aspx.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Monitoring' -> 'Port Usage'
3. In the results table, ensure values in the 'Port in Use' column match approved ports
4. In the results table, ensure values in the 'Protocol' column match approved protocols

If ports or protocols are in use that the organization deems nonsecure, this is a finding.

Fix

1. Access AC
2. To change port or protocol values, from 'Domain Structure', select 'Environment' -> 'Servers'
3. From the list of servers, select one which needs modification
4. Utilize 'Change Center' to create a new change session
5. To modify port assignment, from 'Configuration' tab -> 'General' tab, reassign the port for this server by changing the 'SSL Listen Port' field and click 'Save'
6. To modify protocol configuration, select 'Protocols' tab
7. Use the subtabs 'HTTP', 'jCOM', and 'IIOP' to configure these protocols
8. Use the 'Channels' subtab to create/modify channels which configure other protocols
9. Repeat steps 3-8 for all servers requiring modification
10. Review the 'Port Usage' table in EM again to ensure port has been reassigned
V-56215 No Change
Findings ID: WBLC-01-000018 Rule ID: SV-70469r1_rule Severity: medium CCI: CCI-000018

Discussion

Application servers require user accounts for server management purposes, and if the creation of new accounts is not logged, there is limited or no capability to track or alarm on account creation. This could result in the circumvention of the normal account creation process and introduce a persistent threat. Therefore, an audit trail that documents the creation of application user accounts must exist.

An application server could possibly provide the capability to utilize either a local or centralized user registry. A centralized, enterprise user registry such as AD or LDAP is more likely to already contain provisions for automated account management, whereas a localized user registry will rely upon either the underlying OS or built-in application server user management capabilities. Either way, application servers must create a log entry when accounts are created.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Auditing' tab
5. Ensure the list of 'Auditing Providers' contains at least one Auditing Provider
6. From 'Domain Structure', select the top-level domain link
7. Click 'Advanced' near the bottom of the page
8. Ensure 'Configuration Audit Type' is set to 'Change Log and Audit'

If the 'Configuration Audit Type' is not set to 'Change Log and Audit', this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Auditing' tab
5. Utilize 'Change Center' to create a new change session
6. Click 'New'. Enter a value in 'Name' field and select an auditing provider type (ex: DefaultAuditor) in the 'Type' dropdown. Click 'OK'.
7. From 'Domain Structure', select the top-level domain link
8. Click 'Advanced' near the bottom of the page
9. Set 'Configuration Audit Type' dropdown to 'Change Log and Audit'
10. Click 'Save', and from 'Change Center' click 'Activate Changes' to enable configuration changes
V-56217 No Change
Findings ID: WBLC-01-000019 Rule ID: SV-70471r1_rule Severity: medium CCI: CCI-001403

Discussion

Once an attacker establishes initial access to a system, they often attempt to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply modify an existing account.

Application servers have the capability to contain user information in a local user store, or they can leverage a centralized authentication mechanism like LDAP. Either way, the mechanism used by the application server must automatically log when user accounts are modified.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Auditing' tab
5. Ensure the list of 'Auditing Providers' contains at least one Auditing Provider
6. From 'Domain Structure', select the top-level domain link
7. Click 'Advanced' near the bottom of the page
8. Ensure 'Configuration Audit Type' is set to 'Change Log and Audit'

If the 'Configuration Audit Type' is not set to 'Change Log and Audit', this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Auditing' tab
5. Utilize 'Change Center' to create a new change session
6. Click 'New'. Enter a value in 'Name' field and select an auditing provider type (ex: DefaultAuditor) in the 'Type' dropdown. Click 'OK'.
7. From 'Domain Structure', select the top-level domain link
8. Click 'Advanced' near the bottom of the page
9. Set 'Configuration Audit Type' dropdown to 'Change Log and Audit'
10. Click 'Save', and from 'Change Center' click 'Activate Changes' to enable configuration changes
V-56219 No Change
Findings ID: WBLC-01-000030 Rule ID: SV-70473r1_rule Severity: medium CCI: CCI-000040

Discussion

In order to be able to provide a forensic history of activity, the application server must ensure users who are granted a privileged role or those who utilize a separate distinct account when accessing privileged functions or data have their actions logged.

If privileged activity is not logged, no forensic logs can be used to establish accountability for privileged actions that occur on the system.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Security' -> 'Audit Policy'
3. Select 'Oracle Platform Security Services' from the 'Audit Component Name' dropdown
4. Beneath 'Audit Policy Settings' section, ensure that the comma-delimited list of privileged users (e.g., WebLogic, etc.) is set in the 'Users to Always Audit' field

If all privileged users are not listed in the 'Users to Always Audit' field, this is a finding.

Fix

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Security' -> 'Audit Policy'
3. Select 'Oracle Platform Security Services' from the 'Audit Component Name' dropdown
4. Beneath 'Audit Policy Settings' section, enter the comma-delimited list of privileged users (e.g., WebLogic, etc.) in the 'Users to Always Audit' field. Click 'Apply'
V-56221 No Change
Findings ID: WBLC-01-000032 Rule ID: SV-70475r1_rule Severity: medium CCI: CCI-000044

Discussion

Anytime an authentication method is exposed so as to allow for the login to an application, there is a risk that attempts will be made to obtain unauthorized access.

By limiting the number of failed login attempts that occur within a particular time period, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. Limits are imposed by locking the account once the number of failed attempts has been exceeded.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Configuration' tab -> 'User Lockout' tab
5. Ensure the following field values are set:
'Lockout Threshold' = 3
'Lockout Duration' = 15
'Lockout Reset Duration' = 15

If 'Lockout Threshold' is not set to 3 or 'Lockout Duration' is not set to 15 or 'Lockout Reset Duration' is not set to 15, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Configuration' tab -> 'User Lockout' tab
5. Utilize 'Change Center' to create a new change session
6. Set the following values in the fields as shown:
'Lockout Threshold' = 3
'Lockout Duration' = 15
'Lockout Reset Duration' = 15
7. Click 'Save', and from 'Change Center' click 'Activate Changes' to enable configuration changes
V-56223 No Change
Findings ID: WBLC-01-000033 Rule ID: SV-70477r1_rule Severity: medium CCI: CCI-001452

Discussion

By limiting the number of failed login attempts, the risk of unauthorized system access via automated user password guessing, otherwise known as brute-forcing, is reduced. Best practice requires a time period be applied in which the number of failed attempts is counted (Example: 5 failed attempts within 5 minutes). Limits are imposed by locking the account.

Application servers provide a management capability that allows a user to login via a web interface or a command shell. Application servers also utilize either a local user store or a centralized user store such as an LDAP server. As such, the authentication method employed by the application server must be able to limit the number of consecutive invalid access attempts within the specified time period regardless of access method or user store utilized.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Configuration' tab -> 'User Lockout' tab
5. Ensure the following field values are set:
'Lockout Threshold' = 3
'Lockout Duration' = 15
'Lockout Reset Duration' = 15

If 'Lockout Threshold' is not set to 3 or 'Lockout Duration' is not set to 15 or 'Lockout Reset Duration' is not set to 15, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Configuration' tab -> 'User Lockout' tab
5. Utilize 'Change Center' to create a new change session
6. Set the following values in the fields as shown:
'Lockout Threshold' = 3
'Lockout Duration' = 15
'Lockout Reset Duration' = 15
7. Click 'Save', and from 'Change Center' click 'Activate Changes' to enable configuration changes
V-56225 No Change
Findings ID: WBLC-01-000034 Rule ID: SV-70479r1_rule Severity: medium CCI: CCI-000047

Discussion

Anytime an authentication method is exposed so as to allow for the utilization of an application interface, there is a risk that attempts will be made to obtain unauthorized access.

By locking the account when the pre-defined number of failed login attempts has been exceeded, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced.

Specifying a time period in which the account is to remain locked serves to obstruct the operation of automated password guessing tools while allowing a valid user to reinitiate login attempts after the expiration of the time period without administrative assistance.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Configuration' tab -> 'User Lockout' tab
5. Ensure the following field values are set:
'Lockout Threshold' = 3
'Lockout Duration' = 15
'Lockout Reset Duration' = 15

If 'Lockout Threshold' is not set to 3 or 'Lockout Duration' is not set to 15 or 'Lockout Reset Duration' is not set to 15, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Configuration' tab -> 'User Lockout' tab
5. Utilize 'Change Center' to create a new change session
6. Set the following values in the fields as shown:
'Lockout Threshold' = 3
'Lockout Duration' = 15
'Lockout Reset Duration' = 15
7. Click 'Save', and from 'Change Center' click 'Activate Changes' to enable configuration changes
V-56227 No Change
Findings ID: WBLC-02-000062 Rule ID: SV-70481r1_rule Severity: medium CCI: CCI-000166

Discussion

Non-repudiation of actions taken is required in order to maintain application integrity. Examples of particular actions taken by individuals include creating information, sending a message, approving information (e.g., indicating concurrence or signing a contract), and receiving a message.

Non-repudiation protects individuals against later claims by an author of not having authored a particular document, a sender of not having transmitted a message, a receiver of not having received a message, or a signatory of not having signed a document.

Typical application server actions requiring non-repudiation will be related to application deployment among developer/users and administrative actions taken by admin personnel.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Security' -> 'Audit Policy'
3. Select 'Oracle Platform Security Services' from the 'Audit Component Name' dropdown
4. Beneath 'Audit Policy Settings' section, ensure that the value 'Custom' is set in the 'Audit Level' dropdown
5. Beneath 'Audit Policy Settings' section, ensure that every checkbox is selected under the 'Select For Audit' column of the policy category table
6. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Logs' -> 'View Log Messages'
7. Within the 'Search' panel, expand 'Selected Targets'
8. Click 'Target Log Files' icon for any of the managed server or 'Application Deployment' type targets (not AdminServer)
9. From the list of log files, select '<server-name>.log', 'access.log' or '<server-name>-diagnostic.log' and click 'View Log File' button
10. User or process associated with audit event will be displayed in 'User' column
11. If 'User' column does not appear, use 'View' button -> 'Columns' list to add 'User' field, or select individual message in log message table and view the message detail (beneath the table)
12. Repeat steps 6-11 for each target

If the user is not part of the audit events, this is a finding.

Fix

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Security' -> 'Audit Policy'
3. Select 'Oracle Platform Security Services' from the 'Audit Component Name' dropdown
4. Beneath 'Audit Policy Settings' section, select 'Custom' from the 'Audit Level' dropdown
5. Once it is enabled, click the 'Audit All Events' button and ensure every checkbox is selected under the 'Select For Audit' column of the policy category table. Click 'Apply'
6. If managed server or deployments do not appear in the list of log files, the 'JRF Template' must be applied to the server/cluster
7. Access EM
8. Select the server or cluster from the navigation tree
9. If the 'Apply JRF Template' button appears, click this button and wait for the confirmation message that the template has been successfully applied
10. Again, select the server or cluster from the navigation tree
11. Click the 'Shut Down...' button, and click 'Shutdown' in the confirmation popup. Wait for server or cluster to shut down
12. Click the 'Start Up' button for the server or cluster to start up again
V-56229 No Change
Findings ID: WBLC-02-000065 Rule ID: SV-70483r1_rule Severity: low CCI: CCI-000174

Discussion

Audit generation and audit records can be generated from various components within the application server. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (e.g., auditable events, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked).

The events occurring must be time-correlated in order to conduct accurate forensic analysis. In addition, the correlation must meet a certain tolerance criteria. For instance, DoD may define that the time stamps of different audited events must not differ by any amount greater than ten seconds. It is also acceptable for the application server to utilize an external auditing tool that provides this capability.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'JDBC Data Sources'
3. From the list of data sources, select the one named 'opss-audit-DBDS', which connects to the IAU_APPEND schema of the audit database. Note the value in the 'JNDI name' field.
4. To verify, select 'Configuration' tab -> 'Connection Pool' tab
5. Ensure the 'URL' and 'Properties' fields contain the correct connection values for the IAU_APPEND schema
6. To test, select 'Monitoring' tab, select a server from the list and click 'Test Data Source'. Ensure test was successful. Repeat for each server in the list
7. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Security' -> 'Security Provider Configuration'
8. Beneath 'Audit Service' section, click 'Configure' button
9. Ensure 'Data Source JNDI Name' value matches the JNDI Name value from data source in step 3 above
10. Repeat steps 2-6 for data source named 'wls-wldf-storeDS' and WLS schema
11. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Logs' -> 'View Log Messages'
12. Within the 'Search' panel, expand 'Selected Targets'
13. Use the list of targets to navigate and drill into the log files across the domain

If any of the targets are not being logged, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Services' -> 'Data Sources'
3. Utilize 'Change Center' to create a new change session
4. Click 'New' data source to create a new data source for the audit data store using schema IAU_APPEND
5. Enter database details and JNDI name, click through wizard
6. Select all servers and clusters available as targets to deploy this data source to
7. Finish creating the data source and record the JNDI name
8. Access EM
9. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Security' -> 'Security Provider Configuration'
10. Beneath 'Audit Service' section, click 'Configure' button
11. Set the values for the IAU_APPEND schema and save configuration
12. Repeat steps 2-7 for data source named 'wls-wldf-storeDS' and WLS schema
V-56231 No Change
Findings ID: WBLC-02-000069 Rule ID: SV-70485r1_rule Severity: low CCI: CCI-000172

Discussion

Audit records can be generated from various components within the application server. The list of audited events is the set of events for which audits are to be generated.

This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (e.g., auditable events, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked).

The DoD-required auditable events are events that assist in intrusion detection and forensic analysis. Failure to capture them increases the likelihood that an adversary can breach the system without detection.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Logs' -> 'View Log Messages'
3. Within the 'Search' panel, expand 'Selected Targets'
4. Click 'Target Log Files' icon for 'AdminServer' target
5. From the list of log files, select 'access.log' and click 'View Log File' button
6. All HTTPD, JVM, AS process event and other logging of the AdminServer will be displayed
7. Repeat for each managed server

If there are no events being logged for any of the managed servers or the AdminServer, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Environment' -> 'Servers'
3. From the list of servers, select one which needs logging enabled
4. Utilize 'Change Center' to create a new change session
5. From 'Logging' tab -> 'HTTP' tab, select 'HTTP access log file enabled' checkbox. Click 'Save'
6. From 'Logging' tab -> 'General' tab, set the 'Log file name' field to 'logs/<server-name>.log. Click 'Save'
7. From 'Change Center' click 'Activate Changes' to enable configuration changes
8. Access EM
9. Expand the domain from the navigation tree, and select the server which needs JVM logging configured
10. Use the dropdown to select 'WebLogic Server' -> 'Logs' -> 'Log Configuration'
11. Select the 'Log Levels' tab, and within the table, expand 'Root Logger' node
12. Set 'Oracle Diagnostic Logging Level' value to 'WARNING' and click 'Apply'
V-56233 No Change
Findings ID: WBLC-02-000073 Rule ID: SV-70487r1_rule Severity: low CCI: CCI-000130

Discussion

Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.

Application servers must log all relevant log data that pertains to application server functionality. Examples of relevant data include, but are not limited to Java Virtual Machine (JVM) activity, HTTPD/Web server activity and application server-related system process activity.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Logs' -> 'View Log Messages'
3. Within the 'Search' panel, expand 'Selected Targets'
4. Click 'Target Log Files' icon for 'AdminServer' target
5. From the list of log files, select 'access.log' and click 'View Log File' button
6. All HTTPD logging of the AdminServer will be displayed
7. Repeat for each managed server

If any managed server or the AdminServer does not have HTTPD events within the access.log file, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Environment' -> 'Servers'
3. From the list of servers, select one which needs HTTPD logging enabled
4. Utilize 'Change Center' to create a new change session
5. From 'Logging' tab -> 'HTTP' tab, select 'HTTP access log file enabled' checkbox
6. Click 'Save', and from 'Change Center' click 'Activate Changes' to enable configuration changes
V-56235 No Change
Findings ID: WBLC-02-000074 Rule ID: SV-70489r1_rule Severity: low CCI: CCI-000130

Discussion

Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.

Application servers must log all relevant log data that pertains to application server functionality. Examples of relevant data include, but are not limited to, Java Virtual Machine (JVM) activity, HTTPD activity and application server-related system process activity.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Logs' -> 'View Log Messages'
3. Within the 'Search' panel, expand 'Selected Targets'
4. Click 'Target Log Files' icon for 'AdminServer' target
5. From the list of log files, select '<server-name>-diagnostic.log' and click 'View Log File' button
6. All JVM logging of the AdminServer will be displayed
7. Repeat for each managed server

If there are no JVM-related events for the managed servers or the AdminServer, this is a finding.

Fix

1. Access EM
2. Expand the domain from the navigation tree, and select the server which needs JVM logging configured
3. Use the dropdown to select 'WebLogic Server' -> 'Logs' -> 'Log Configuration'
4. Select the 'Log Levels' tab, and within the table, expand 'Root Logger' node
5. Set 'Oracle Diagnostic Logging Level' value to 'WARNING' and click 'Apply'
V-56237 No Change
Findings ID: WBLC-02-000075 Rule ID: SV-70491r1_rule Severity: low CCI: CCI-000130

Discussion

Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.

Application servers must log all relevant log data that pertains to application server functionality. Examples of relevant data include, but are not limited to, Java Virtual Machine (JVM) activity, HTTPD activity and application server-related system process activity.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Logs' -> 'View Log Messages'
3. Within the 'Search' panel, expand 'Selected Targets'
4. Click 'Target Log Files' icon for 'AdminServer' target
5. From the list of log files, select '<server-name>.log' and click 'View Log File' button
6. All AS process logging of the AdminServer will be displayed
7. Repeat for each managed server

If the managed servers or AdminServer does not have process events, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Environment' -> 'Servers'
3. From the list of servers, select one which needs AS process logging configured
4. Utilize 'Change Center' to create a new change session
5. From 'Logging' tab -> 'General' tab, set the 'Log file name' field to 'logs/<server-name>.log
6. Click 'Save', and from 'Change Center' click 'Activate Changes' to enable configuration changes
V-56239 No Change
Findings ID: WBLC-02-000076 Rule ID: SV-70493r1_rule Severity: low CCI: CCI-000131

Discussion

Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.

In addition to logging event information, application servers must also log the corresponding dates and times of these events. Examples of event data include, but are not limited to, Java Virtual Machine (JVM) activity, HTTPD activity and application server-related system process activity.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Logs' -> 'View Log Messages'
3. Within the 'Search' panel, expand 'Selected Targets'
4. Click 'Target Log Files' icon for any of the managed server or 'Application Deployment' type targets (not AdminServer)
5. From the list of log files, select '<server-name>.log', 'access.log' or '<server-name>-diagnostic.log' and click 'View Log File' button
6. Time stamp of audit event will be displayed in 'Time' column
7. If 'Time' column does not appear, use 'View' button -> 'Columns' list to add 'Time' field, or select individual message in log message table and view the message detail (beneath the table)
8. Repeat for each target

If any of the targets generate audit records without date and time data, this is a finding.

Fix

1. If managed server or deployments do not appear in the list of log files, the 'JRF Template' must be applied to the server/cluster
2. Access EM
3. Select the server or cluster from the navigation tree
4. If the 'Apply JRF Template' button appears, click this button and wait for the confirmation message that the template has been successfully applied
5. Again, select the server or cluster from the navigation tree
6. Click the 'Shut Down...' button, and click 'Shutdown' in the confirmation popup. Wait for server or cluster to shut down.
7. Click the 'Start Up' button for the server or cluster to start up again
V-56241 No Change
Findings ID: WBLC-02-000077 Rule ID: SV-70495r1_rule Severity: low CCI: CCI-000132

Discussion

Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.

Without sufficient information establishing where the audit events occurred, investigation into the cause of events is severely hindered.

In addition to logging relevant data, application servers must also log information to indicate the location of these events. Examples of relevant data include, but are not limited to, Java Virtual Machine (JVM) activity, HTTPD activity and application server-related system process activity.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Logs' -> 'View Log Messages'
3. Within the 'Search' panel, expand 'Selected Targets'
4. Click 'Target Log Files' icon for any of the managed server or 'Application Deployment' type targets (not AdminServer)
5. From the list of log files, select '<server-name>.log', 'access.log' or '<server-name>-diagnostic.log' and click 'View Log File' button
6. Select any record which appears in the log message table
7. Location of audit event will be displayed in 'Component' and 'Module' fields of the message detail (beneath the table)
8. Repeat for each target

If any of the targets generate audit records without sufficient information to establish where the event occurred, this is a finding.

Fix

1. If managed server or deployments do not appear in the list of log files, the 'JRF Template' must be applied to the server/cluster
2. Access EM
3. Select the server or cluster from the navigation tree
4. If the 'Apply JRF Template' button appears, click this button and wait for the confirmation message that the template has been successfully applied
5. Again, select the server or cluster from the navigation tree
6. Click the 'Shut Down...' button, and click 'Shutdown' in the confirmation popup. Wait for server or cluster to shut down.
7. Click the 'Start Up' button for the server or cluster to start up again
V-56243 No Change
Findings ID: WBLC-02-000078 Rule ID: SV-70497r1_rule Severity: low CCI: CCI-000133

Discussion

Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes, but is not limited to, time stamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, filenames involved, access control or flow control rules invoked.

Without information establishing the source of activity, the value of audit records from a forensics perspective is questionable.

Examples of activity sources include, but are not limited to, application process sources such as one process affecting another process, user-related activity, and activity resulting from remote network system access (IP addresses).

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Logs' -> 'View Log Messages'
3. Within the 'Search' panel, expand 'Selected Targets'
4. Click 'Target Log Files' icon for any of the managed server or 'Application Deployment' type targets (not AdminServer)
5. From the list of log files, select '<server-name>.log', 'access.log' or '<server-name>-diagnostic.log' and click 'View Log File' button
6. Select any record which appears in the log message table
7. Source of audit event will be displayed in 'Host', 'Host IP Address', 'Thread ID', 'REMOTE_HOST' fields of the message detail (beneath the table), depending on which logfile and target type is selected
8. Repeat for each target

If any of the targets generate audit records without sufficient information to establish the source of the events, this is a finding.

Fix

1. If managed server or deployments do not appear in the list of log files, the 'JRF Template' must be applied to the server/cluster
2. Access EM
3. Select the server or cluster from the navigation tree
4. If the 'Apply JRF Template' button appears, click this button and wait for the confirmation message that the template has been successfully applied
5. Again, select the server or cluster from the navigation tree
6. Click the 'Shut Down...' button, and click 'Shutdown' in the confirmation popup. Wait for server or cluster to shut down.
7. Click the 'Start Up' button for the server or cluster to start up again
V-56245 No Change
Findings ID: WBLC-02-000079 Rule ID: SV-70499r1_rule Severity: low CCI: CCI-000134

Discussion

Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes, but is not limited to, time stamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, filenames involved, access control or flow control rules invoked.

Success and failure indicators ascertain the outcome of a particular application server event of function. As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Logs' -> 'View Log Messages'
3. Within the 'Search' panel, expand 'Selected Targets'
4. Click 'Target Log Files' icon for any of the managed server or 'Application Deployment' type targets (not AdminServer)
5. From the list of log files, select '<server-name>.log', 'access.log' or '<server-name>-diagnostic.log' and click 'View Log File' button
6. Outcome of audit event will be displayed in 'Message Type' column. 'Error' or 'Exception' indicates failures, others message types indicate success
7. If 'Message Type' column does not appear, use 'View' button -> 'Columns' list to add 'Message Type' field, or select individual message in log message table and view the message detail (beneath the table)
8. Repeat for each target

If any of the targets generate audit records without sufficient information to establish the outcome of the event, this is a finding.

Fix

1. If managed server or deployments do not appear in the list of log files, the 'JRF Template' must be applied to the server/cluster
2. Access EM
3. Select the server or cluster from the navigation tree
4. If the 'Apply JRF Template' button appears, click this button and wait for the confirmation message that the template has been successfully applied
5. Again, select the server or cluster from the navigation tree
6. Click the 'Shut Down...' button, and click 'Shutdown' in the confirmation popup. Wait for server or cluster to shut down.
7. Click the 'Start Up' button for the server or cluster to start up again
V-56247 No Change
Findings ID: WBLC-02-000080 Rule ID: SV-70501r1_rule Severity: medium CCI: CCI-001487

Discussion

Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control, includes: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.

Application servers have differing levels of logging capabilities which can be specified by setting a verbosity level. The application server must, at a minimum, be capable of establishing the identity of any user or process that is associated with any particular event.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Logs' -> 'View Log Messages'
3. Within the 'Search' panel, expand 'Selected Targets'
4. Click 'Target Log Files' icon for any of the managed server or 'Application Deployment' type targets (not AdminServer)
5. From the list of log files, select '<server-name>.log', 'access.log' or '<server-name>-diagnostic.log' and click 'View Log File' button
6. User or process associated with audit event will be displayed in 'User' column
7. If 'User' column does not appear, use 'View' button -> 'Columns' list to add 'User' field, or select individual message in log message table and view the message detail (beneath the table)
8. Repeat for each target

If any of the targets generate audit records without sufficient information to establish the identity of any user/subject or process, this is a finding.

Fix

1. If managed server or deployments do not appear in the list of log files, the 'JRF Template' must be applied to the server/cluster
2. Access EM
3. Select the server or cluster from the navigation tree
4. If the 'Apply JRF Template' button appears, click this button and wait for the confirmation message that the template has been successfully applied
5. Again, select the server or cluster from the navigation tree
6. Click the 'Shut Down...' button, and click 'Shutdown' in the confirmation popup. Wait for server or cluster to shut down
7. Click the 'Start Up' button for the server or cluster to start up again
V-56249 No Change
Findings ID: WBLC-02-000081 Rule ID: SV-70503r1_rule Severity: medium CCI: CCI-000136

Discussion

Information system auditing capability is critical for accurate forensic analysis. Audit record content that may be necessary to satisfy the requirement of this control includes, but is not limited to, time stamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, filenames involved, access control or flow control rules invoked.

Centralized management of audit records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. Application servers and their related components are required to be capable of writing logs to centralized audit log servers.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'JDBC Data Sources'
3. From the list of data sources, select the one named 'opss-audit-DBDS', which connects to the IAU_APPEND schema of the audit database. Note the value in the 'JNDI name' field
4. To verify, select 'Configuration' tab -> 'Connection Pool' tab
5. Ensure the 'URL' and 'Properties' fields contain the correct connection values for the IAU_APPEND schema
6. To test, select 'Monitoring' tab, select a server from the list and click 'Test Data Source'. Ensure test was successful. Repeat for each server in the list
7. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Security' -> 'Security Provider Configuration'
8. Beneath 'Audit Service' section, click 'Configure' button
9. Ensure 'Data Source JNDI Name' value matches the JNDI Name value from data source in step 3 above
10. Repeat steps 2-6 for data source named 'wls-wldf-storeDS' and WLS schema

If the location for audit data is not an audit log server, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Services' -> 'Data Sources'
3. Utilize 'Change Center' to create a new change session
4. Click 'New' data source to create a new data source for the audit data store using schema IAU_APPEND
5. Enter database details and JNDI name, click through wizard
6. Select all servers and clusters available as targets to deploy this data source to
7. Finish creating the data source and record the JNDI name
8. Access EM
9. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Security' -> 'Security Provider Configuration'
10. Beneath 'Audit Service' section, click 'Configure' button
11. Set the values for the IAU_APPEND schema and save configuration
12. Repeat steps 2-7 for data source named 'wls-wldf-storeDS' and WLS schema
V-56251 No Change
Findings ID: WBLC-02-000083 Rule ID: SV-70505r1_rule Severity: low CCI: CCI-000144

Discussion

It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Notification of the failure event will allow administrators to take actions so that logs are not lost.

Checks

1. Access AC
2. From 'Domain Structure', select 'Diagnostics' -> 'Diagnostic Modules'
3. Select 'Module-HealthState' from 'Diagnostic System Modules' list
4. Select 'Configuration' tab -> 'Watches and Notifications' tab. Select the 'Watches' tab from the bottom of page
5. Ensure 'ServerHealthWatch' row has 'Enabled' column value set to 'true'
6. Select 'Configuration' tab -> 'Watches and Notifications' tab. Select the 'Notifications' tab from the bottom of page
7. Ensure 'ServerHealthNotification' row has 'Enable Notification' column value set to 'true'

If 'ServerHealthNotification' row has 'Enable Notification' column value is not set to 'true', this is a finding.

Fix

1. Access AC
2. Utilize 'Change Center' to create a new change session
3. From 'Domain Structure', select 'Diagnostics' -> 'Diagnostic Modules'
4. If 'Module-HealthState' does not exist, click 'New' button. Enter 'Module-HealthState' in 'Name' field and click 'OK' button.
5. Select 'Module-HealthState' from 'Diagnostic System Modules' list
6. Select 'Configuration' tab -> 'Watches and Notifications' tab. Select the 'Watches' tab from the bottom of page
7. Click 'New' button. Set the following values in the fields as shown:
'Watch Name' = 'ServerHealthWatch'
'Watch Type' = 'Collected Metrics'
'Enable Watch' = selected
8. Click 'Next'
9. Click 'Add Expressions'
10. Set 'MBean Server location' dropdown value to 'ServerRuntime'. Click 'Next'
11. Set 'MBean Type' dropdown value to 'weblogic.management.runtime.ServerRuntimeMBean'. Click 'Next'
12. Set 'Instance' dropdown value to a WebLogic Server instance to be monitored. Click 'Next'
13. Select 'Enter an Attribute Expression' radio button, enter following value in 'Attribute Expression' field: HealthState.State
14. Set 'Operator' dropdown value to '>='. Set 'Value' field to '3'. Click 'Finish'
15. Repeat steps 9-14 for all WebLogic Server instances to be monitored. Click 'Finish'
16. Continuing from step 6 above, select the 'Notifications' tab from the bottom of page
17. Click 'New' button. Set 'Type' dropdown value to 'SMTP (E-Mail)'. Click 'Next'. Set the following values in the fields as shown:
'Notification Name' = 'ServerHealthNotification'
'Enable Notification' = selected
18. Click 'Next'
19. Select an existing 'Mail Session Name', or click 'Create a New Mail Session' button to create one (JNDI name and Java mail settings must be known)
20. In 'E-Mail Recipients' text area, add list of administrator email addresses, and customize 'E-Mail Subject' and 'E-Mail Body' fields as needed. Click 'Finish'
21. Return to the 'Watches' tab from the bottom of page. Select 'ServerHealthWatch' Select 'Notifications' tab
22. Use shuttle list to set 'ServerHealthNotification' into the 'Chosen' table. Click 'Save'
V-56253 No Change
Findings ID: WBLC-02-000084 Rule ID: SV-70507r1_rule Severity: low CCI: CCI-000139

Discussion

Audit processing failures include, but are not limited to, failures in the application server log capturing mechanisms or audit 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 that alert to designated individuals in the event there is an application server audit processing failure.

Checks

1. Access AC
2. From 'Domain Structure', select 'Diagnostics' -> 'Diagnostic Modules'
3. Select 'Module-HealthState' from 'Diagnostic System Modules' list
4. Select 'Configuration' tab -> 'Watches and Notifications' tab. Select the 'Watches' tab from the bottom of page
5. Ensure 'ServerHealthWatch' row has 'Enabled' column value set to 'true'
6. Select 'Configuration' tab -> 'Watches and Notifications' tab. Select the 'Notifications' tab from the bottom of page
7. Ensure 'ServerHealthNotification' row has 'Enable Notification' column value set to 'true'

If 'ServerHealthNotification' row has 'Enable Notification' column value is not set to 'true', this is a finding.

Fix

1. Access AC
2. Utilize 'Change Center' to create a new change session
3. From 'Domain Structure', select 'Diagnostics' -> 'Diagnostic Modules'
4. If 'Module-HealthState' does not exist, click 'New' button. Enter 'Module-HealthState' in 'Name' field and click 'OK' button
5. Select 'Module-HealthState' from 'Diagnostic System Modules' list
6. Select 'Configuration' tab -> 'Watches and Notifications' tab. Select the 'Watches' tab from the bottom of page
7. Click 'New' button. Set the following values in the fields as shown:
'Watch Name' = 'ServerHealthWatch'
'Watch Type' = 'Collected Metrics'
'Enable Watch' = selected
8. Click 'Next'
9. Click 'Add Expressions'
10. Set 'MBean Server location' dropdown value to 'ServerRuntime'. Click 'Next'
11. Set 'MBean Type' dropdown value to 'weblogic.management.runtime.ServerRuntimeMBean'. Click 'Next'
12. Set 'Instance' dropdown value to a WebLogic Server instance to be monitored. Click 'Next'
13. Select 'Enter an Attribute Expression' radio button, enter following value in 'Attribute Expression' field: HealthState.State
14. Set 'Operator' dropdown value to '>='. Set 'Value' field to '3'. Click 'Finish'
15. Repeat steps 9-14 for all WebLogic Server instances to be monitored. Click 'Finish'
16. Continuing from step 6 above, select the 'Notifications' tab from the bottom of page
17. Click 'New' button. Set 'Type' dropdown value to 'SMTP (E-Mail)'. Click 'Next'. Set the following values in the fields as shown:
'Notification Name' = 'ServerHealthNotification'
'Enable Notification' = selected
18. Click 'Next'
19. Select an existing 'Mail Session Name', or click 'Create a New Mail Session' button to create one (JNDI name and Java mail settings must be known)
20. In 'E-Mail Recipients' text area, add list of administrator email addresses, and customize 'E-Mail Subject' and 'E-Mail Body' fields as needed. Click 'Finish'
21. Return to the 'Watches' tab from the bottom of page. Select 'ServerHealthWatch'. Select 'Notifications' tab
22. Use shuttle list to set 'ServerHealthNotification' into the 'Chosen' table. Click 'Save'
V-56255 No Change
Findings ID: WBLC-02-000086 Rule ID: SV-70509r1_rule Severity: low CCI: CCI-000140

Discussion

Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. To ensure flexibility and ease of use, application servers must be capable of notifying a group of administrative personnel upon detection of an application audit log processing failure.

Checks

1. Access AC
2. From 'Domain Structure', select 'Diagnostics' -> 'Diagnostic Modules'
3. Select 'Module-HealthState' from 'Diagnostic System Modules' list
4. Select 'Configuration' tab -> 'Watches and Notifications' tab. Select the 'Watches' tab from the bottom of page
5. Ensure 'ServerHealthWatch' row has 'Enabled' column value set to 'true'
6. Select 'Configuration' tab -> 'Watches and Notifications' tab. Select the 'Notifications' tab from the bottom of page
7. Ensure 'ServerHealthNotification' row has 'Enable Notification' column value set to 'true'

If 'ServerHealthNotification' row has 'Enable Notification' column value not set to 'true', this is a finding.

Fix

1. Access AC
2. Utilize 'Change Center' to create a new change session
3. From 'Domain Structure', select 'Diagnostics' -> 'Diagnostic Modules'
4. If 'Module-HealthState' does not exist, click 'New' button. Enter 'Module-HealthState' in 'Name' field and click 'OK' button
5. Select 'Module-HealthState' from 'Diagnostic System Modules' list
6. Select 'Configuration' tab -> 'Watches and Notifications' tab. Select the 'Watches' tab from the bottom of page
7. Click 'New' button. Set the following values in the fields as shown:
'Watch Name' = 'ServerHealthWatch'
'Watch Type' = 'Collected Metrics'
'Enable Watch' = selected
8. Click 'Next'
9. Click 'Add Expressions'
10. Set 'MBean Server location' dropdown value to 'ServerRuntime'. Click 'Next'
11. Set 'MBean Type' dropdown value to 'weblogic.management.runtime.ServerRuntimeMBean'. Click 'Next'
12. Set 'Instance' dropdown value to a WebLogic Server instance to be monitored. Click 'Next'
13. Select 'Enter an Attribute Expression' radio button, enter following value in 'Attribute Expression' field: HealthState.State
14. Set 'Operator' dropdown value to '>='. Set 'Value' field to '3'. Click 'Finish'
15. Repeat steps 9-14 for all WebLogic Server instances to be monitored. Click 'Finish'
16. Continuing from step 6 above, select the 'Notifications' tab from the bottom of page
17. Click 'New' button. Set 'Type' dropdown value to 'SMTP (E-Mail)'. Click 'Next'. Set the following values in the fields as shown:
'Notification Name' = 'ServerHealthNotification'
'Enable Notification' = selected
18. Click 'Next'
19. Select an existing 'Mail Session Name', or click 'Create a New Mail Session' button to create one (JNDI name and Java mail settings must be known)
20. In 'E-Mail Recipients' text area, add list of administrator email addresses, and customize 'E-Mail Subject' and 'E-Mail Body' fields as needed. Click 'Finish'
21. Return to the 'Watches' tab from the bottom of page. Select 'ServerHealthWatch'. Select 'Notifications' tab
22. Use shuttle list to set 'ServerHealthNotification' into the 'Chosen' table. Click 'Save'
V-56257 No Change
Findings ID: WBLC-02-000093 Rule ID: SV-70511r1_rule Severity: low CCI: CCI-000159

Discussion

Without the use of an approved and synchronized time source, configured on the systems, events cannot be accurately correlated and analyzed to determine what is transpiring within the application server.

If an event has been triggered on the network, and the application server is not configured with the correct time, the event may be seen as insignificant, when in reality the events are related and may have a larger impact across the network. Synchronization of system clocks is needed in order to correctly correlate the timing of events that occur across multiple systems. Determining the correct time a particular event occurred on a system, via time stamps, is critical when conducting forensic analysis and investigating system events.
Application servers must utilize the internal system clock when generating time stamps and audit records.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Security' -> 'Security Provider Configuration'
3. Beneath 'Audit Service' section, click 'Configure' button
4. Ensure the 'Timezone Settings' radio button is set to 'UTC' so audit logs will be time stamped in Coordinated Universal Time regardless of the time zone of the underlying physical or virtual machine
5. The time stamp will be recorded according to the operating system's set time

If the 'Timezone Settings' radio button is not set to 'UTC', this is a finding.

Fix

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Security' -> 'Security Provider Configuration'
3. Beneath 'Audit Service' section, click 'Configure' button
4. Set the 'Timezone Settings' radio button to 'UTC' so audit logs will be time stamped in Coordinated Universal Time regardless of the time zone of the underlying physical or virtual machine
5. The time stamp will be recorded according to the operating system's set time
6. Click 'Apply' and restart the servers in the WebLogic domain
V-56259 No Change
Findings ID: WBLC-02-000094 Rule ID: SV-70513r1_rule Severity: low CCI: CCI-000160

Discussion

Determining the correct time a particular application event occurred on a system is critical when conducting forensic analysis and investigating system events.

Synchronization of system clocks is needed in order to correctly correlate the timing of events that occur across multiple systems. To meet that requirement the organization will define an authoritative time source and frequency to which each system will synchronize its internal clock.

Application servers must defer accurate timekeeping services to the operating system upon which the application server is installed.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Security' -> 'Security Provider Configuration'
3. Beneath 'Audit Service' section, click 'Configure' button
4. Ensure the 'Timezone Settings' radio button is set to 'UTC' so audit logs will be time stamped in Coordinated Universal Time regardless of the time zone of the underlying physical or virtual machine
5. The time stamp will be recorded according to the operating system's set time

If the 'Timezone Settings' radio button is not set to 'UTC', this is a finding.

Fix

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Security' -> 'Security Provider Configuration'
3. Beneath 'Audit Service' section, click 'Configure' button
4. Set the 'Timezone Settings' radio button to 'UTC' so audit logs will be time stamped in Coordinated Universal Time regardless of the time zone of the underlying physical or virtual machine
5. The time stamp will be recorded according to the operating system's set time
6. Click 'Apply' and restart the servers in the WebLogic domain
V-56261 No Change
Findings ID: WBLC-02-000095 Rule ID: SV-70515r1_rule Severity: low CCI: CCI-000162

Discussion

If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult, if not impossible, to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage.

Application servers contain admin interfaces that allow reading and manipulation of audit records. Therefore, these interfaces should not allow for unfettered access to those records. Application servers also write audit data to log files which are stored on the OS, so appropriate file permissions must also be used to restrict access.

Audit information includes all information (e.g., audit records, audit settings, transaction logs, and audit reports) needed to successfully audit information system activity. Application servers must protect audit information from unauthorized read access.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Users and Groups' tab -> 'Users' tab
5. From 'Users' table, select a user that must not have audit read access
6. From users settings page, select 'Groups' tab
7. Ensure the 'Chosen' table does not contain any of the following roles - 'Admin', 'Deployer', 'Monitor', 'Operator'
8. Repeat steps 5-7 for all users that must not have audit read access

If any users that should not have access to read audit information contain any of the roles of 'Admin', 'Deployer', 'Monitor' or 'Operator', this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Users and Groups' tab -> 'Users' tab
5. From 'Users' table, select a user that must not have audit read access
6. From users settings page, select 'Groups' tab
7. From the 'Chosen' table, use the shuttle buttons to remove all of the following roles - 'Admin', 'Deployer', 'Monitor', 'Operator'
8. Click 'Save'
9. Repeat steps 5-8 for all users that must not have audit read access
V-56263 No Change
Findings ID: WBLC-02-000098 Rule ID: SV-70517r1_rule Severity: medium CCI: CCI-001493

Discussion

Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data.

Depending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data.

It is, therefore, imperative that access to audit tools be controlled and protected from unauthorized access.

Application servers provide a web and/or a command line-based management functionality for managing the application server audit capabilities. In addition, subsets of audit 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 audit tools, any file system-based tools are protected as well.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Users and Groups' tab -> 'Users' tab
5. From 'Users' table, select a user that must not have audit tool configuration access
6. From users settings page, select 'Groups' tab
7. Ensure the 'Chosen' table does not contain the role - 'Admin'
8. Repeat steps 5-7 for all users that must not have audit tool configuration access

If any users that should not have access to the audit tools contains the role of 'Admin', this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Users and Groups' tab -> 'Users' tab
5. From 'Users' table, select a user that must not have audit tool configuration access
6. From users settings page, select 'Groups' tab
7. From the 'Chosen' table, use the shuttle buttons to remove the role - 'Admin'
8. Click 'Save'
9. Repeat steps 5-8 for all users that must not have audit tool configuration access
V-56265 No Change
Findings ID: WBLC-02-000099 Rule ID: SV-70519r1_rule Severity: medium CCI: CCI-001494

Discussion

Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data.

Depending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data.

It is, therefore, imperative that access to audit tools be controlled and protected from unauthorized modification. If an attacker were to modify audit tools, he could also manipulate logs to hide evidence of malicious activity.

Application servers provide a web- and/or a command line-based management functionality for managing the application server audit capabilities. In addition, subsets of audit 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 audit tools, any file system-based tools are protected as well.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Users and Groups' tab -> 'Users' tab
5. From 'Users' table, select a user that must not have audit tool configuration access
6. From users settings page, select 'Groups' tab
7. Ensure the 'Chosen' table does not contain the role - 'Admin'
8. Repeat steps 5-7 for all users that must not have audit tool configuration access

If any users that should not have access to the audit tools contains the role of 'Admin', this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Users and Groups' tab -> 'Users' tab
5. From 'Users' table, select a user that must not have audit tool configuration access
6. From users settings page, select 'Groups' tab
7. From the 'Chosen' table, use the shuttle buttons to remove the role - 'Admin'
8. Click 'Save'
9. Repeat steps 5-8 for all users that must not have audit tool configuration access
V-56267 No Change
Findings ID: WBLC-02-000100 Rule ID: SV-70521r1_rule Severity: medium CCI: CCI-001495

Discussion

Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data.

Depending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data.

It is, therefore, imperative that access to audit tools be controlled and protected from unauthorized modification. If an attacker were to delete audit tools the application server administrators would have no way of managing or viewing the logs.

Application servers provide a web- and/or a command line-based management functionality for managing the application server audit capabilities. In addition, subsets of audit 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 audit tools, any file system-based tools are protected from unauthorized deletion as well.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Users and Groups' tab -> 'Users' tab
5. From 'Users' table, select a user that must not have audit tool configuration access
6. From users settings page, select 'Groups' tab
7. Ensure the 'Chosen' table does not contain the role - 'Admin'
8. Repeat steps 5-7 for all users that must not have audit tool configuration access

If any users that should not have access to the audit tools contains the role of 'Admin', this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Users and Groups' tab -> 'Users' tab
5. From 'Users' table, select a user that must not have audit tool configuration access
6. From users settings page, select 'Groups' tab
7. From the 'Chosen' table, use the shuttle buttons to remove the role - 'Admin'
8. Click 'Save'
9. Repeat steps 5-8 for all users that must not have audit tool configuration access
V-56269 No Change
Findings ID: WBLC-03-000125 Rule ID: SV-70523r1_rule Severity: medium CCI: CCI-001499

Discussion

Application servers have the ability to specify that the hosted applications utilize shared libraries. The application server must have a capability to divide roles based upon duties wherein one project user (such as a developer) cannot modify the shared library code of another project user. The application server must also be able to specify that non-privileged users cannot modify any shared library code at all.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Users and Groups' tab -> 'Users' tab
5. From 'Users' table, select a user that must not have shared library modification access
6. From users settings page, select 'Groups' tab
7. Ensure the 'Chosen' table does not contain the roles - 'Admin', 'Deployer'
8. Repeat steps 5-7 for all users that must not have shared library modification access

If any users that are not permitted to change the software resident within software libraries (including privileged programs) have the role of 'Admin' or 'Deployer', this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Users and Groups' tab -> 'Users' tab
5. From 'Users' table, select a user that must not have shared library modification access
6. From users settings page, select 'Groups' tab
7. From the 'Chosen' table, use the shuttle buttons to remove the role - 'Admin', 'Deployer'
8. Click 'Save'
9. Repeat steps 5-8 for all users that must not have shared library modification access
V-56271 No Change
Findings ID: WBLC-03-000127 Rule ID: SV-70525r1_rule Severity: medium CCI: CCI-000381

Discussion

Application servers provide a myriad of differing processes, features and functionalities. Some of these processes may be deemed to be unnecessary or too insecure 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.

Checks

1. Access AC
2. From 'Domain Structure', select 'Deployments'
3. Select a deployment of type 'Web Application' from list of deployments
4. Select 'Configuration' tab -> 'General' tab
5. Ensure 'JSP Page Check' field value is set to '-1', which indicates JSP reloading is disabled within this deployment. Repeat steps 3-5 for all 'Web Application' type deployments
6. For every WebLogic resource within the domain, the 'Configuration' tab and associated subtabs provide the ability to disable or deactivate functionality and services that are deemed to be non-essential to the server mission or can adversely impact server performance

If the 'JSP Page Check' field is not set to '-1' or other services or functionality deemed to be non-essential to the server mission is not set to '-1', this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Deployments'
3. Select a deployment of type 'Web Application' from list of deployments
4. Select 'Configuration' tab -> 'General' tab
5. Utilize 'Change Center' to create a new change session
6. Set 'JSP Page Check' field value to '-1', which indicates JSP reloading is disabled within this deployment. Click 'Save'. Repeat steps 3-6 for all 'Web Application' type deployments.
7. For every WebLogic resource within the domain, the 'Configuration' tab and associated subtabs provide the ability to disable or deactivate functionality and services that are deemed to be non-essential to the server mission or can adversely impact server performance
V-56273 No Change
Findings ID: WBLC-03-000128 Rule ID: SV-70527r2_rule Severity: medium CCI: CCI-000382

Discussion

Application servers provide numerous processes, features, and functionalities that utilize TCP/IP ports. Some of these processes may be deemed to be unnecessary or too insecure to run on a production system. The application server must provide the capability to disable or deactivate network-related services that are deemed to be non-essential to the server mission, for example, disabling a protocol or feature that opens a listening port that is prohibited by DoD ports and protocols. For a list of approved ports and protocols reference the DoD ports and protocols web site at https://iase.disa.mil/ppsm/Pages/index.aspx.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Monitoring' -> 'Port Usage'
3. In the results table, ensure values in the 'Port in Use' column match approved ports
4. In the results table, ensure values in the 'Protocol' column match approved protocols

If any ports listed in the 'Port in Use' column is an unauthorized port or any protocols listed in the 'Protocol' column is an unauthorized protocol, this is a finding.

Fix

1. Access AC
2. To change port or protocol values, from 'Domain Structure', select 'Environment' -> 'Servers'
3. From the list of servers, select one which needs modification
4. Utilize 'Change Center' to create a new change session
5. To modify port assignment, from 'Configuration' tab -> 'General' tab, reassign the port for this server by changing the 'SSL Listen Port' field and click 'Save'
6. To modify protocol configuration, select 'Protocols' tab
7. Use the subtabs 'HTTP', 'jCOM' and 'IIOP' to configure these protocols
8. Use the 'Channels' subtab to create/modify channels which configure other protocols
9. Repeat steps 3-8 for all servers requiring modification
10. Review the 'Port Usage' table in EM again to ensure port has been reassigned
V-56275 No Change
Findings ID: WBLC-03-000129 Rule ID: SV-70529r1_rule Severity: low CCI: CCI-000386

Discussion

The application server must provide a capability to halt or otherwise disable the automatic execution of deployed applications until such time that the application is considered part of the established application server baseline. Deployment to the application server should not provide a means for automatic application start-up should the application server itself encounter a restart condition.

Checks

1. Access AC
2. From 'Domain Structure', select the top-level domain
3. Select 'Configuration' tab -> 'General' tab
4. Ensure 'Production Mode' checkbox is selected

If the 'Production Mode' checkbox is not selected, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select the top-level domain
3. Select 'Configuration' tab -> 'General' tab
4. Check 'Production Mode' checkbox. Click 'Save'
5. Restart all servers
V-56277 No Change
Findings ID: WBLC-05-000150 Rule ID: SV-70531r1_rule Severity: high CCI: CCI-000764

Discussion

To assure accountability and prevent unauthorized access, application server users must be uniquely identified and authenticated.

The application server must uniquely identify and authenticate application server users or processes acting on behalf of users. This is typically accomplished via the use of a user store which is either local (OS-based) or centralized (LDAP) in nature.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Authentication' tab
5. Ensure the list of 'Authentication Providers' contains at least one non-Default Authentication Provider
6. If the Authentication Provider is perimeter-based, ensure the list contains at least one non-Default IdentityAsserter

If the list of 'Authentication Providers' does not contain at least one non-Default Authentication Provider, this is a finding.

If the Authentication Provider is perimeter-based and the list of 'Authentication Providers' does not contain at least one non-Default IdentityAsserter, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Authentication' tab
5. Utilize 'Change Center' to create a new change session
6. Click 'New'. Enter a value in 'Name' field and select a valid authentication provider type (e.g., LDAPAuthenticator) in the 'Type' dropdown. Click 'OK'
7. From the list, select the newly created authentication provider and select the 'Configuration' tab -> 'Provider Specific' tab
8. Set all provider specific values to configure the new authentication provider. Click 'Save'
9. Continuing from step 4, if the new authentication provider is perimeter-based, click 'New'. Enter a value in 'Name' field and select a valid authentication provider type (e.g., SAML2IdentityAsserter) in the 'Type' dropdown. Click 'OK'
10. From the list, select the newly created authentication identity asserter and select the 'Configuration' tab -> 'Provider Specific' tab
11. Set all provider-specific values to configure the new authentication identity asserter. Click 'Save'
V-56279 No Change
Findings ID: WBLC-05-000153 Rule ID: SV-70533r1_rule Severity: high CCI: CCI-000770

Discussion

To assure individual accountability and prevent unauthorized access, application server users (and any processes acting on behalf of application server users) must be individually identified and authenticated.

A group authenticator is a generic account used by multiple individuals. Use of a group authenticator alone does not uniquely identify individual users.

Application servers must ensure that individual users are authenticated prior to authenticating via role or group authentication. This is to ensure that there is non-repudiation for actions taken.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Authentication' tab
5. Ensure the list of 'Authentication Providers' contains at least one non-Default Authentication Provider
6. If the Authentication Provider is perimeter-based, ensure the list contains at least one non-Default IdentityAsserter

If the list of 'Authentication Providers' does not contain at least one non-Default Authentication Provider, this is a finding.

If the Authentication Provider is perimeter-based and the list of 'Authentication Providers' does not contain at least one non-Default IdentityAsserter, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Authentication' tab
5. Utilize 'Change Center' to create a new change session
6. Click 'New'. Enter a value in 'Name' field and select a valid authentication provider type (e.g., LDAPAuthenticator) in the 'Type' dropdown. Click 'OK'
7. From the list, select the newly created authentication provider and select the 'Configuration' tab -> 'Provider Specific' tab
8. Set all provider specific values to configure the new authentication provider. Click 'Save'
9. Continuing from step 4, if the new authentication provider is perimeter-based, click 'New'. Enter a value in 'Name' field and select a valid authentication provider type (e.g., SAML2IdentityAsserter) in the 'Type' dropdown. Click 'OK'
10. From the list, select the newly created authentication identity asserter and select the 'Configuration' tab -> 'Provider Specific' tab
11. Set all provider specific values to configure the new authentication identity asserter. Click 'Save'
V-56281 No Change
Findings ID: WBLC-05-000160 Rule ID: SV-70535r1_rule Severity: medium CCI: CCI-000205

Discussion

Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password length is one of several factors that helps to determine strength and how long it takes to crack a password. The shorter the password is, the lower the number of possible combinations that need to be tested before the password is compromised.

Application servers either provide a local user store, or they integrate with enterprise user stores like LDAP. When the application server provides the user store and enforces authentication, the application server must enforce minimum password length.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Password Validation' subtab
5. Select 'SystemPasswordValidator'
6. Select 'Configuration' tab -> 'Provider Specific' subtab
7. Ensure 'Minimum Password Length' field value is set to '15'

If the 'Minimum Password Length' field is not set to '15', this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Password Validation' subtab
5. Select 'SystemPasswordValidator'
6. Select 'Configuration' tab -> 'Provider Specific' subtab
7. Utilize 'Change Center' to create a new change session
8. Set 'Minimum Password Length' field value to '15'. Click 'Save'
V-56283 No Change
Findings ID: WBLC-05-000162 Rule ID: SV-70537r1_rule Severity: medium CCI: CCI-000192

Discussion

Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Use of a complex password helps to increase the time and resources required to compromise the password.

Application servers either provide a local user store, or they integrate with enterprise user stores like LDAP. When the application server provides the user store and enforces authentication, the application server must enforce the organization's password complexity requirements, which includes the requirement to use a specific number of upper-case characters.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Password Validation' subtab
5. Select 'SystemPasswordValidator'
6. Select 'Configuration' tab -> 'Provider Specific' subtab
7. Ensure 'Minimum Number of Upper Case Characters' field value is set to '1' or higher

If the 'Minimum Number of Upper Case Characters' field value is not set to '1' or higher, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Password Validation' subtab
5. Select 'SystemPasswordValidator'
6. Select 'Configuration' tab -> 'Provider Specific' subtab
7. Utilize 'Change Center' to create a new change session
8. Set 'Minimum Number of Upper Case Characters' field value to '1' or higher. Click 'Save'
V-56285 No Change
Findings ID: WBLC-05-000163 Rule ID: SV-70539r1_rule Severity: medium CCI: CCI-000193

Discussion

Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Use of a complex password helps to increase the time and resources required to compromise the password.

Application servers either provide a local user store, or they integrate with enterprise user stores like LDAP. When the application server provides the user store and enforces authentication, the application server must enforce the organization's password complexity requirements, which include the requirement to use a specific number of lower-case characters.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Password Validation' subtab
5. Select 'SystemPasswordValidator'
6. Select 'Configuration' tab -> 'Provider Specific' subtab
7. Ensure 'Minimum Number of Lower Case Characters' field value is set to '1' or higher

If the 'Minimum Number of Lower Case Characters' field value is not set to '1' or higher, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Password Validation' subtab
5. Select 'SystemPasswordValidator'
6. Select 'Configuration' tab -> 'Provider Specific' subtab
7. Utilize 'Change Center' to create a new change session
8. Set 'Minimum Number of Lower Case Characters' field value to '1' or higher. Click 'Save'
V-56287 No Change
Findings ID: WBLC-05-000164 Rule ID: SV-70541r1_rule Severity: medium CCI: CCI-000194

Discussion

Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Use of a complex password helps to increase the time and resources required to compromise the password.

Application servers provide either 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 enforce the organization's password complexity requirements that include the requirement to use a specific number of numeric characters when passwords are created or changed.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Password Validation' subtab
5. Select 'SystemPasswordValidator'
6. Select 'Configuration' tab -> 'Provider Specific' subtab
7. Ensure 'Minimum Number of Numeric Characters' field value is set to '1' or higher

If the 'Minimum Number of Numeric Characters' field value is not set to '1' or higher, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Password Validation' subtab
5. Select 'SystemPasswordValidator'
6. Select 'Configuration' tab -> 'Provider Specific' subtab
7. Utilize 'Change Center' to create a new change session
8. Set 'Minimum Number of Numeric Characters' field value to '1' or higher. Click 'Save'
V-56289 No Change
Findings ID: WBLC-05-000165 Rule ID: SV-70543r1_rule Severity: medium CCI: CCI-001619

Discussion

Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Use of a complex password helps to increase the time and resources required to compromise the password.

Application servers either provide a local user store, or they integrate with enterprise user stores like LDAP. When the application server provides the user store and enforces authentication, the application server must enforce the organization's password complexity requirements that include the requirement to use a specific number of special characters.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Password Validation' subtab
5. Select 'SystemPasswordValidator'
6. Select 'Configuration' tab -> 'Provider Specific' subtab
7. Ensure 'Minimum Number of Non-Alphanumeric Characters' field value is set to '1' or higher

If the 'Minimum Number of Non-Alphanumeric Characters' field value is not set to '1' or higher, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Password Validation' subtab
5. Select 'SystemPasswordValidator'
6. Select 'Configuration' tab -> 'Provider Specific' subtab
7. Utilize 'Change Center' to create a new change session
8. Set 'Minimum Number of Non-Alphanumeric Characters' field value to '1' or higher. Click 'Save'
V-56291 No Change
Findings ID: WBLC-05-000168 Rule ID: SV-70545r1_rule Severity: high CCI: CCI-000197

Discussion

Passwords need to be protected at all times, and encryption is the standard method for protecting passwords during transmission.

Application servers have the capability to utilize either certificates (tokens) or user IDs and passwords in order to authenticate. When the application server transmits or receives passwords, the passwords must be encrypted.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Authentication' tab
5. Ensure the list of 'Authentication Providers' contains at least one non-Default Authentication Provider
6. If the Authentication Provider is perimeter-based, ensure the list contains at least one non-Default IdentityAsserter

If the list of 'Authentication Providers' does not contain at least one non-Default Authentication Provider, this is a finding.

If the Authentication Provider is perimeter-based and the list of 'Authentication Providers' does not contain at least one non-Default IdentityAsserter, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Authentication' tab
5. Utilize 'Change Center' to create a new change session
6. Click 'New'. Enter a value in 'Name' field and select a valid authentication provider type (e.g., LDAPAuthenticator) in the 'Type' dropdown. Click 'OK'
7. From the list, select the newly created authentication provider and select the 'Configuration' tab -> 'Provider Specific' tab
8. Set all provider-specific values to configure the new authentication provider. Click 'Save'
9. Continuing from step 4, if the new authentication provider is perimeter-based, click 'New'. Enter a value in 'Name' field and select a valid authentication provider type (e.g., SAML2IdentityAsserter) in the 'Type' dropdown. Click 'OK'
10. From the list, select the newly created authentication identity asserter and select the 'Configuration' tab -> 'Provider Specific' tab
11. Set all provider-specific values to configure the new authentication identity asserter. Click 'Save'
V-56293 No Change
Findings ID: WBLC-05-000169 Rule ID: SV-70547r1_rule Severity: high CCI: CCI-000197

Discussion

Passwords need to be protected at all times, and encryption is the standard method for protecting passwords during transmission.

Application servers have the capability to utilize LDAP directories for authentication. If LDAP connections are not protected during transmission, sensitive authentication credentials can be stolen. When the application server utilizes LDAP, the LDAP traffic must be encrypted.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Monitoring' -> 'Port Usage'
3. In the results table, ensure the 'Protocol' column does not contain the value 'LDAP' (only 'LDAPS')

If LDAP is being used and the 'Protocol' column contains the value 'LDAP', this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Environment' -> 'Servers'
3. From the list of servers, select one which is assigned 'LDAP' protocol
4. Utilize 'Change Center' to create a new change session
5. From 'Configuration' tab -> 'General' tab, deselect the 'Listen Port Enabled' checkbox
6. Select the 'SSL Listen Port Enabled checkbox
7. Enter a valid port value in the 'SSL Listen Port' field and click 'Save'
8. Review the 'Port Usage' table in EM again to ensure the 'Protocol' column does not contain the value 'LDAP'
V-56295 No Change
Findings ID: WBLC-05-000172 Rule ID: SV-70549r1_rule Severity: medium CCI: CCI-000185

Discussion

A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC.

When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a Certification Authority (CA). A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA.

Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted.

Status information for certification paths includes, certificate revocation lists or online certificate status protocol responses.

Checks

1. Access AC
2. From 'Domain Structure', select 'Environment' -> 'Servers'
3. From the list of servers, select one which needs check for SSL configuration verification
4. From 'Configuration' tab -> 'General' tab, ensure 'Listen Port Enabled' checkbox is deselected
5. Ensure 'SSL Listen Port Enabled' checkbox is selected and a valid port number is in 'SSL Listen Port' field, e.g., 7002
6. From 'Configuration' tab -> 'Keystores' tab, ensure 'Custom Identity and Java Standard Trust' is selected in 'Keystores' section
7. Repeat steps 3-6 for all servers requiring SSL configuration checking

If any servers utilizing PKI-based authentication does not have the 'SSL Listen Port Enabled' selected or 'Custom Identity and Java Standard Trust' is not selected for the keystores, this is a finding.

Fix

1. Obtain an identity (private key and digital certificates) and trust (certificates of trusted certificate authorities) to configure on the server
2. Create Identity keystore and load private key and certificate using ImportPrivateKey java utility, example:
$ java utils.ImportPrivateKey -certfile <cert_file> -keyfile <private_key_file> [-keyfilepass <private_key_password>] -keystore <keystore> -storepass <storepass> [-storetype <storetype>] -alias <alias> [-keypass <keypass>]
3. Access AC
4. Utilize 'Change Center' to create a new change session
5. From 'Domain Structure', select 'Environment' -> 'Servers'
6. From the list of servers, select one which needs SSL set up
7. From 'Configuration' tab -> 'General' tab, deselect 'Listen Port Enabled' checkbox
8. Select 'SSL Listen Port Enabled' checkbox and enter a valid port number in 'SSL Listen Port' field, e.g., 7002
9. From 'Configuration' tab -> 'Keystores' tab, click 'Change' button in 'Keystores' section
10. From dropdown, select 'Custom Identity and Java Standard Trust' and click 'Save'
11. Enter the fully qualified path to Identity keystore, from step 2, in 'Custom Identity Keystore' field
12. Enter 'JKS' in the 'Custom Identity Keystore Type' field
13. Enter the Identity keystore password in 'Custom Identity Keystore Passphrase' and 'Confirm Custom Identity Keystore Passphrase' fields
14. Enter the Java Standard Trust keystore (cacerts) password in 'Java Standard Trust Keystore Passphrase' and 'Confirm Java Standard Trust Keystore Passphrase' fields
15. Leave all other fields blank and click 'Save'
16. From 'Configuration' tab -> 'SSL' tab, enter values from step 2 into corresponding fields, as follows:
- Enter <alias> into 'Private Key Alias'
- Enter <private_key_password> into 'Private Key Passphrase'
- Enter <private_key_password> into 'Confirm Private Key Passphrase'
17. Click 'Save', and from 'Change Center' click 'Activate Changes' to enable configuration changes
18. Repeat steps 4-17 for all servers requiring SSL configuration
19. From 'Domain Structure', select 'Environment' -> 'Servers', click 'Control' tab
20. Select checkbox for all servers configured in previous steps and click 'Restart SSL'
V-56297 No Change
Findings ID: WBLC-05-000174 Rule ID: SV-70551r1_rule Severity: medium CCI: CCI-000187

Discussion

The cornerstone of the 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.

Application servers must provide the capability to utilize and meet requirements of the DoD Enterprise PKI infrastructure for application authentication.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Authentication' tab
5. Ensure the list of 'Authentication Providers' contains at least one non-Default Authentication Provider
6. If the Authentication Provider is perimeter-based, ensure the list contains at least one non-Default IdentityAsserter

If PKI-based authentication is being used and the list of 'Authentication Providers' does not contain at least one non-Default Authentication Provider, this is a finding.

If PKI-based authentication is being used and the Authentication Provider is perimeter-based and the list of 'Authentication Providers' does not contain at least one non-Default IdentityAsserter, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Providers' tab -> 'Authentication' tab
5. Utilize 'Change Center' to create a new change session
6. Click 'New'. Enter a value in 'Name' field and select a valid authentication provider type (e.g., LDAPAuthenticator) in the 'Type' dropdown. Click 'OK'
7. From the list, select the newly created authentication provider and select the 'Configuration' tab -> 'Provider Specific' tab
8. Set all provider specific values to configure the new authentication provider. Click 'Save'
9. Continuing from step 4, if the new authentication provider is perimeter-based, click 'New'. Enter a value in 'Name' field and select a valid authentication provider type (e.g., SAML2IdentityAsserter) in the 'Type' dropdown. Click 'OK'
10. From the list, select the newly created authentication identity asserter and select the 'Configuration' tab -> 'Provider Specific' tab
11. Set all provider specific values to configure the new authentication identity asserter. Click 'Save'
V-56299 No Change
Findings ID: WBLC-05-000176 Rule ID: SV-70553r3_rule Severity: medium CCI: CCI-000803

Discussion

Encryption is only as good as the encryption modules utilized. Unapproved cryptographic module algorithms cannot be verified and cannot be relied upon to provide confidentiality or integrity, and DoD data may be compromised due to weak algorithms.

FIPS 140-2 is the current standard for validating cryptographic modules, and NSA Type-X (where X=1, 2, 3, 4) products are NSA-certified hardware-based encryption modules.

Application servers must provide FIPS-compliant encryption modules when storing encrypted data and configuration settings.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Logs' -> 'View Log Messages'
3. Within the 'Search' panel, expand 'Selected Targets'
4. Click 'Target Log Files' icon for 'AdminServer' target
5. From the list of log files, select 'AdminServer.log' and click 'View Log File' button
6. Within the search criteria, enter the value 'FIPS' for the 'Message contains' field, and select the appropriate 'Start Date' and 'End Date' range. Click 'Search'
7. Check for the following log entry: "Changing the default Random Number Generator in RSA CryptoJ ... to FIPS186PRNG" or "Changing the default Random Number Generator in RSA CryptoJ from ECDRBG128 to HMACDRBG."

If either of these log entries are found, this is not a finding.

If a log entry cannot be found, navigate to the DOMAIN_HOME directory:
8. View the contents of the appropriate WebLogic server start script:
On UNIX operating systems: startWebLogic.sh
On Microsoft Windows operating systems: startWebLogic.cmd
9. Ensure the JAVA_OPTIONS variable is set:
On UNIX operating systems:
JAVA_OPTIONS=" -Djava.security.properties==/<mylocation>/java.security ${JAVA_OPTIONS}"
On Microsoft Windows operating systems:
set JAVA_OPTIONS= -Djava.security.properties==C:\<mylocation>\java.security %JAVA_OPTIONS%
10. Ensure the <mylocation> path specified above contains a valid java.security file (Refer to section 2.2.4 of the Overview document)
11. Ensure the PRE_CLASSPATH variable is set:
On UNIX operating systems:
PRE_CLASSPATH="%MW_HOME%\wlserver\server\lib\jcmFIPS.jar;%MW_HOME%\wlserver\server\lib\sslj.jar ${PRE_CLASSPATH}"
On Microsoft Windows operating systems:
set PRE_CLASSPATH= %MW_HOME%\wlserver\server\lib\jcmFIPS.jar;%MW_HOME%\wlserver\server\lib\sslj.jar;%PRE_CLASSPATH%

If the java options are not set correctly, this is a finding.

Fix

1. Shut down any running instances of WebLogic server
2. On disk, navigate to the DOMAIN_HOME directory
3. View the contents of the appropriate WebLogic server start script:
On UNIX operating systems: startWebLogic.sh
On Microsoft Windows operating systems: startWebLogic.cmd
4. Ensure the JAVA_OPTIONS variable is set:
On UNIX operating systems:
JAVA_OPTIONS=" -Djava.security.properties==/<mylocation>/java.security ${JAVA_OPTIONS}"
On Microsoft Windows operating systems:
set JAVA_OPTIONS= -Djava.security.properties==C:\<mylocation>\java.security %JAVA_OPTIONS%
5. Ensure the <mylocation> path specified above contains a valid java.security file (Refer to section 2.2.4 of the Overview document)
6. Ensure the PRE_CLASSPATH variable is set:
On UNIX operating systems:
PRE_CLASSPATH="%MW_HOME%\wlserver\server\lib\jcmFIPS.jar;%MW_HOME%\wlserver\server\lib\sslj.jar ${PRE_CLASSPATH}"
On Microsoft Windows operating systems:
set PRE_CLASSPATH= %MW_HOME%\wlserver\server\lib\jcmFIPS.jar;%MW_HOME%\wlserver\server\lib\sslj.jar;%PRE_CLASSPATH%
7. Refer to section 2.2.4 of the Overview document
V-56301 No Change
Findings ID: WBLC-05-000177 Rule ID: SV-70555r3_rule Severity: medium CCI: CCI-000803

Discussion

Encryption is only as good as the encryption modules utilized. Unapproved cryptographic module algorithms cannot be verified and cannot be relied upon to provide confidentiality or integrity, and DoD data may be compromised due to weak algorithms.

FIPS 140-2 is the current standard for validating cryptographic modules, and NSA Type-X (where X=1, 2, 3, 4) products are NSA-certified hardware-based encryption modules.

Application servers must provide FIPS-compliant encryption modules when authenticating users and processes.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Logs' -> 'View Log Messages'
3. Within the 'Search' panel, expand 'Selected Targets'
4. Click 'Target Log Files' icon for 'AdminServer' target
5. From the list of log files, select 'AdminServer.log' and click 'View Log File' button
6. Within the search criteria, enter the value 'FIPS' for the 'Message contains' field, and select the appropriate 'Start Date' and 'End Date' range. Click 'Search'
7. Check for the following log entry: "Changing the default Random Number Generator in RSA CryptoJ ... to FIPS186PRNG" or "Changing the default Random Number Generator in RSA CryptoJ from ECDRBG128 to HMACDRBG."

If either of these log entries are found, this is not a finding.

If a log entry cannot be found, navigate to the DOMAIN_HOME directory:
8. View the contents of the appropriate WebLogic server start script:
On UNIX operating systems: startWebLogic.sh
On Microsoft Windows operating systems: startWebLogic.cmd
9. Ensure the JAVA_OPTIONS variable is set:
On UNIX operating systems:
JAVA_OPTIONS=" -Djava.security.properties==/<mylocation>/java.security ${JAVA_OPTIONS}"
On Microsoft Windows operating systems:
set JAVA_OPTIONS= -Djava.security.properties==C:\<mylocation>\java.security %JAVA_OPTIONS%
10. Ensure the <mylocation> path specified above contains a valid java.security file (Refer to section 2.2.4 of the Overview document)
11. Ensure the PRE_CLASSPATH variable is set:
On UNIX operating systems:
PRE_CLASSPATH="%MW_HOME%\wlserver\server\lib\jcmFIPS.jar;%MW_HOME%\wlserver\server\lib\sslj.jar ${PRE_CLASSPATH}"
On Microsoft Windows operating systems:
set PRE_CLASSPATH= %MW_HOME%\wlserver\server\lib\jcmFIPS.jar;%MW_HOME%\wlserver\server\lib\sslj.jar;%PRE_CLASSPATH%

If the java options are not set correctly, this is a finding.

Fix

1. Shut down any running instances of WebLogic server
2. On disk, navigate to the DOMAIN_HOME directory
3. View the contents of the appropriate WebLogic server start script:
On UNIX operating systems: startWebLogic.sh
On Microsoft Windows operating systems: startWebLogic.cmd
4. Ensure the JAVA_OPTIONS variable is set:
On UNIX operating systems:
JAVA_OPTIONS=" -Djava.security.properties==/<mylocation>/java.security ${JAVA_OPTIONS}"
On Microsoft Windows operating systems:
set JAVA_OPTIONS= -Djava.security.properties==C:\<mylocation>\java.security %JAVA_OPTIONS%
5. Ensure the <mylocation> path specified above contains a valid java.security file (Refer to section 2.2.4 of the Overview document)
6. Ensure the PRE_CLASSPATH variable is set:
On UNIX operating systems:
PRE_CLASSPATH="%MW_HOME%\wlserver\server\lib\jcmFIPS.jar;%MW_HOME%\wlserver\server\lib\sslj.jar ${PRE_CLASSPATH}"
On Microsoft Windows operating systems:
set PRE_CLASSPATH= %MW_HOME%\wlserver\server\lib\jcmFIPS.jar;%MW_HOME%\wlserver\server\lib\sslj.jar;%PRE_CLASSPATH%
7. Refer to section 2.2.4 of the Overview document
V-56303 No Change
Findings ID: WBLC-06-000190 Rule ID: SV-70557r1_rule Severity: medium CCI: CCI-000888

Discussion

Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network.

Application servers provide an HTTP-oriented remote management capability that is used for managing the application server as well as uploading and deleting applications that are hosted on the application server. Application servers need to ensure the communication channels used to remotely access the system utilize cryptographic mechanisms such as TLS.

Checks

1. Access AC
2. From 'Domain Structure', select 'Environment' -> 'Servers'
3. From the list of servers, select one which needs check for SSL configuration verification
4. From 'Configuration' tab -> 'General' tab, ensure 'Listen Port Enabled' checkbox is deselected
5. Ensure 'SSL Listen Port Enabled' checkbox is selected and a valid port number is in 'SSL Listen Port' field, e.g., 7002
6. From 'Configuration' tab -> 'Keystores' tab, ensure 'Custom Identity and Java Standard Trust' is selected in 'Keystores' section
7. Repeat steps 3-6 for all servers requiring SSL configuration checking

If any of the servers requiring SSL have the 'Listen Port Enabled' selected or 'SSL Listen Port Enable' not selected or 'Custom Identity and Java Standard Trust' is not selected for the keystores, this is a finding.

Fix

1. Obtain an identity (private key and digital certificates) and trust (certificates of trusted certificate authorities) to configure on the server
2. Create Identity keystore and load private key and certificate using ImportPrivateKey java utility, example:
$ java utils.ImportPrivateKey -certfile <cert_file> -keyfile <private_key_file> [-keyfilepass <private_key_password>] -keystore <keystore> -storepass <storepass> [-storetype <storetype>] -alias <alias> [-keypass <keypass>]
3. Access AC
4. Utilize 'Change Center' to create a new change session
5. From 'Domain Structure', select 'Environment' -> 'Servers'
6. From the list of servers, select one which needs SSL set up
7. From 'Configuration' tab -> 'General' tab, deselect 'Listen Port Enabled' checkbox
8. Select 'SSL Listen Port Enabled' checkbox and enter a valid port number in 'SSL Listen Port' field, e.g., 7002
9. From 'Configuration' tab -> 'Keystores' tab, click 'Change' button in 'Keystores' section
10. From dropdown, select 'Custom Identity and Java Standard Trust' and click 'Save'
11. Enter the fully qualified path to Identity keystore, from step 2, in 'Custom Identity Keystore' field
12. Enter 'JKS' in the 'Custom Identity Keystore Type' field
13. Enter the Identity keystore password in 'Custom Identity Keystore Passphrase' and 'Confirm Custom Identity Keystore Passphrase' fields
14. Enter the Java Standard Trust keystore (cacerts) password in 'Java Standard Trust Keystore Passphrase' and 'Confirm Java Standard Trust Keystore Passphrase' fields
15. Leave all other fields blank and click 'Save'
16. From 'Configuration' tab -> 'SSL' tab, enter values from step 2 into corresponding fields, as follows:
- Enter <alias> into 'Private Key Alias'
- Enter <private_key_password> into 'Private Key Passphrase'
- Enter <private_key_password> into 'Confirm Private Key Passphrase'
17. Click 'Save', and from 'Change Center' click 'Activate Changes' to enable configuration changes
18. Repeat steps 4-17 for all servers requiring SSL configuration
19. From 'Domain Structure', select 'Environment' -> 'Servers', click 'Control' tab
20. Select checkbox for all servers configured in previous steps and click 'Restart SSL'
V-56305 No Change
Findings ID: WBLC-06-000191 Rule ID: SV-70559r1_rule Severity: medium CCI: CCI-000877

Discussion

Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network.

Application servers will typically utilize an HTTP interface for providing both local and remote maintenance and diagnostic sessions. In these instances, an acceptable strong identification and authentication technique consists of utilizing two-factor authentication via secured HTTPS connections. If the application server also provides maintenance and diagnostic access via a fat client or other client-based connection, then that client must also utilize two-factor authentication and use FIPS-approved encryption modules for establishing transport connections.

Checks

1. Access AC
2. From 'Domain Structure', select 'Environment' -> 'Servers'
3. From the list of servers, select one which needs check for SSL configuration verification
4. From 'Configuration' tab -> 'General' tab, ensure 'Listen Port Enabled' checkbox is deselected
5. Ensure 'SSL Listen Port Enabled' checkbox is selected and a valid port number is in 'SSL Listen Port' field, e.g., 7002
6. From 'Configuration' tab -> 'Keystores' tab, ensure 'Custom Identity and Java Standard Trust' is selected in 'Keystores' section
7. Repeat steps 3-6 for all servers requiring SSL configuration checking

If any of the servers requiring SSL have the 'Listen Port Enabled' selected or 'SSL Listen Port Enable' not selected or 'Custom Identity and Java Standard Trust' is not selected for the keystores, this is a finding.

Fix

1. Obtain an identity (private key and digital certificates) and trust (certificates of trusted certificate authorities) to configure on the server
2. Create Identity keystore and load private key and certificate using ImportPrivateKey java utility, example:
$ java utils.ImportPrivateKey -certfile <cert_file> -keyfile <private_key_file> [-keyfilepass <private_key_password>] -keystore <keystore> -storepass <storepass> [-storetype <storetype>] -alias <alias> [-keypass <keypass>]
3. Access AC
4. Utilize 'Change Center' to create a new change session
5. From 'Domain Structure', select 'Environment' -> 'Servers'
6. From the list of servers, select one which needs SSL set up
7. From 'Configuration' tab -> 'General' tab, deselect 'Listen Port Enabled' checkbox
8. Select 'SSL Listen Port Enabled' checkbox and enter a valid port number in 'SSL Listen Port' field, e.g., 7002
9. From 'Configuration' tab -> 'Keystores' tab, click 'Change' button in 'Keystores' section
10. From dropdown, select 'Custom Identity and Java Standard Trust' and click 'Save'
11. Enter the fully qualified path to Identity keystore, from step 2, in 'Custom Identity Keystore' field
12. Enter 'JKS' in the 'Custom Identity Keystore Type' field
13. Enter the Identity keystore password in 'Custom Identity Keystore Passphrase' and 'Confirm Custom Identity Keystore Passphrase' fields
14. Enter the Java Standard Trust keystore (cacerts) password in 'Java Standard Trust Keystore Passphrase' and 'Confirm Java Standard Trust Keystore Passphrase' fields
15. Leave all other fields blank and click 'Save'
16. From 'Configuration' tab -> 'SSL' tab, enter values from step 2 into corresponding fields, as follows:
- Enter <alias> into 'Private Key Alias'
- Enter <private_key_password> into 'Private Key Passphrase'
- Enter <private_key_password> into 'Confirm Private Key Passphrase'
17. Click 'Save', and from 'Change Center' click 'Activate Changes' to enable configuration changes
18. Repeat steps 4-17 for all servers requiring SSL configuration
19. From 'Domain Structure', select 'Environment' -> 'Servers', click 'Control' tab
20. Select checkbox for all servers configured in previous steps and click 'Restart SSL'
V-56307 No Change
Findings ID: WBLC-08-000210 Rule ID: SV-70561r1_rule Severity: low CCI: CCI-001133

Discussion

If communications sessions remain open for extended periods of time even when unused, there is the potential for an adversary to hijack the session and use it to gain access to the device or networks to which it is attached. Terminating sessions after a certain period of inactivity is a method for mitigating the risk of this vulnerability.

The application server must provide a mechanism for timing out or otherwise terminating inactive web sessions.

Checks

1. Access AC
2. From 'Domain Structure', select 'Deployments'
3. Sort 'Deployments' table by 'Type' by click the column header
4. Select an 'Enterprise Application' or 'Web Application' to check the session timeout setting
5. Select 'Configuration' tab -> 'Application' tab for deployments of 'Enterprise Application' type
Select 'Configuration' tab -> 'General' tab for deployments of 'Web Application' type
6. Ensure 'Session Timeout' field value is set to '900' (seconds)

If the 'Session Timeout' field is not set '900', this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Deployments'
3. Sort 'Deployments' table by 'Type' by click the column header
4. Select an 'Enterprise Application' or 'Web Application' to check the session timeout setting
5. Select 'Configuration' tab -> 'Application' tab for deployments of 'Enterprise Application' type
Select 'Configuration' tab -> 'General' tab for deployments of 'Web Application' type
6. Utilize 'Change Center' to create a new change session
7. Set value in 'Session Timeout' field value to '900' (seconds). Click 'Save'
8. Repeat steps 4-7 for each 'Enterprise Application' and 'Web Application' deployment
V-56309 No Change
Findings ID: WBLC-08-000211 Rule ID: SV-70563r1_rule Severity: medium CCI: CCI-001135

Discussion

Without a trusted communication path, the application server is vulnerable to a man-in-the-middle attack.

Application server user interfaces are used for management of the application server so the communications path between client and server must be trusted or management of the server may be compromised.

Checks

1. Access AC
2. From 'Domain Structure', select 'Environment' -> 'Servers'
3. From the list of servers, select one which needs check for SSL configuration verification
4. From 'Configuration' tab -> 'General' tab, ensure 'Listen Port Enabled' checkbox is deselected
5. Ensure 'SSL Listen Port Enabled' checkbox is selected and a valid port number is in 'SSL Listen Port' field, e.g., 7002
6. From 'Configuration' tab -> 'Keystores' tab, ensure 'Custom Identity and Java Standard Trust' is selected in 'Keystores' section
7. Repeat steps 3-6 for all servers requiring SSL configuration checking

If any of the servers requiring SSL have the 'Listen Port Enabled' selected or 'SSL Listen Port Enable' not selected or 'Custom Identity and Java Standard Trust' is not selected for the keystores, this is a finding.

Fix

1. Obtain an identity (private key and digital certificates) and trust (certificates of trusted certificate authorities) to configure on the server
2. Create Identity keystore and load private key and certificate using ImportPrivateKey java utility, example:
$ java utils.ImportPrivateKey -certfile <cert_file> -keyfile <private_key_file> [-keyfilepass <private_key_password>] -keystore <keystore> -storepass <storepass> [-storetype <storetype>] -alias <alias> [-keypass <keypass>]
3. Access AC
4. Utilize 'Change Center' to create a new change session
5. From 'Domain Structure', select 'Environment' -> 'Servers'
6. From the list of servers, select one which needs SSL set up
7. From 'Configuration' tab -> 'General' tab, deselect 'Listen Port Enabled' checkbox
8. Select 'SSL Listen Port Enabled' checkbox and enter a valid port number in 'SSL Listen Port' field, e.g., 7002
9. From 'Configuration' tab -> 'Keystores' tab, click 'Change' button in 'Keystores' section
10. From dropdown, select 'Custom Identity and Java Standard Trust' and click 'Save'
11. Enter the fully qualified path to Identity keystore, from step 2, in 'Custom Identity Keystore' field
12. Enter 'JKS' in the 'Custom Identity Keystore Type' field
13. Enter the Identity keystore password in 'Custom Identity Keystore Passphrase' and 'Confirm Custom Identity Keystore Passphrase' fields
14. Enter the Java Standard Trust keystore (cacerts) password in 'Java Standard Trust Keystore Passphrase' and 'Confirm Java Standard Trust Keystore Passphrase' fields
15. Leave all other fields blank and click 'Save'
16. From 'Configuration' tab -> 'SSL' tab, enter values from step 2 into corresponding fields, as follows:
- Enter <alias> into 'Private Key Alias'
- Enter <privae_key_password> into 'Private Key Passphrase'
- Enter <private_key_password> into 'Confirm Private Key Passphrase'
17. Click 'Save', and from 'Change Center' click 'Activate Changes' to enable configuration changes
18. Repeat steps 4-17 for all servers requiring SSL configuration
19. From 'Domain Structure', select 'Environment' -> 'Servers', click 'Control' tab
20. Select checkbox for all servers configured in previous steps and click 'Restart SSL'
V-56313 No Change
Findings ID: WBLC-08-000214 Rule ID: SV-70567r3_rule Severity: medium CCI: CCI-001144

Discussion

Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data.

Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. Encryption modules/algorithms are the mathematical procedures used for encrypting data.

NSA has developed Type 1 algorithms for protecting classified information. The Committee on National Security Systems (CNSS) National Information Assurance Glossary (CNSS Instruction No. 4009) defines Type 1 products as:

"Cryptographic equipment, assembly or component classified or certified by NSA for encrypting and decrypting classified and sensitive national security information when appropriately keyed. Developed using established NSA business processes and containing NSA-approved algorithms. Used to protect systems requiring the most stringent protection mechanisms."

Although persons may have a security clearance, they may not have a "need to know" and are required to be separated from the information in question. The application server must employ NSA-approved cryptography to protect classified information from those individuals who have no "need to know" or when encryption of compartmentalized data is required by data classification.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Logs' -> 'View Log Messages'
3. Within the 'Search' panel, expand 'Selected Targets'
4. Click 'Target Log Files' icon for 'AdminServer' target
5. From the list of log files, select 'AdminServer.log' and click 'View Log File' button
6. Within the search criteria, enter the value 'FIPS' for the 'Message contains' field, and select the appropriate 'Start Date' and 'End Date' range. Click 'Search'
7. Check for the following log entry: "Changing the default Random Number Generator in RSA CryptoJ ... to FIPS186PRNG" or "Changing the default Random Number Generator in RSA CryptoJ from ECDRBG128 to HMACDRBG."

If either of these log entries are found, this is not a finding.

If a log entry cannot be found, navigate to the DOMAIN_HOME directory:
8. View the contents of the appropriate WebLogic server start script:
On UNIX operating systems: startWebLogic.sh
On Microsoft Windows operating systems: startWebLogic.cmd
9. Ensure the JAVA_OPTIONS variable is set:
On UNIX operating systems:
JAVA_OPTIONS=" -Djava.security.properties==/<mylocation>/java.security ${JAVA_OPTIONS}"
On Microsoft Windows operating systems:
set JAVA_OPTIONS= -Djava.security.properties==C:\<mylocation>\java.security %JAVA_OPTIONS%
10. Ensure the <mylocation> path specified above contains a valid java.security file (Refer to section 2.2.4 of the Overview document)
11. Ensure the PRE_CLASSPATH variable is set:
On UNIX operating systems:
PRE_CLASSPATH="%MW_HOME%\wlserver\server\lib\jcmFIPS.jar;%MW_HOME%\wlserver\server\lib\sslj.jar ${PRE_CLASSPATH}"
On Microsoft Windows operating systems:
set PRE_CLASSPATH= %MW_HOME%\wlserver\server\lib\jcmFIPS.jar;%MW_HOME%\wlserver\server\lib\sslj.jar;%PRE_CLASSPATH%

If the java options are not set correctly, this is a finding.

Fix

1. Shut down any running instances of WebLogic server
2. On disk, navigate to the DOMAIN_HOME directory
3. View the contents of the appropriate WebLogic server start script:
On UNIX operating systems: startWebLogic.sh
On Microsoft Windows operating systems: startWebLogic.cmd
4. Ensure the JAVA_OPTIONS variable is set:
On UNIX operating systems:
JAVA_OPTIONS=" -Djava.security.properties==/<mylocation>/java.security ${JAVA_OPTIONS}"
On Microsoft Windows operating systems:
set JAVA_OPTIONS= -Djava.security.properties==C:\<mylocation>\java.security %JAVA_OPTIONS%
5. Ensure the <mylocation> path specified above contains a valid java.security file (Refer to section 2.2.4 of the Overview document)
6. Ensure the PRE_CLASSPATH variable is set:
On UNIX operating systems:
PRE_CLASSPATH="%MW_HOME%\wlserver\server\lib\jcmFIPS.jar;%MW_HOME%\wlserver\server\lib\sslj.jar ${PRE_CLASSPATH}"
On Microsoft Windows operating systems:
set PRE_CLASSPATH= %MW_HOME%\wlserver\server\lib\jcmFIPS.jar;%MW_HOME%\wlserver\server\lib\sslj.jar;%PRE_CLASSPATH%
7. Refer to section 2.2.4 of the Overview document
V-56315 No Change
Findings ID: WBLC-08-000218 Rule ID: SV-70569r1_rule Severity: medium CCI: CCI-001149

Discussion

The purpose of this control is to ensure organizations explicitly address the protection needs for public information and applications, with such protection likely being implemented as part of other security controls.

Application servers must protect the integrity of publicly available information.

Checks

1. Access AC
2. From 'Domain Structure', select 'Deployments'
3. Select a deployed component which contains publicly available information and/or applications
4. Select 'Targets' tab
5. Ensure one or more of the selected targets for this deployment is a cluster of managed servers

If the information requires clustering of managed server and the managed servers are not clustered, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Deployments'
3. Select a deployed component which contains publicly available information and/or applications
4. Utilize 'Change Center' to create a new change session
5. Select 'Targets' tab
6. Select one or more clusters of managed servers as a target for this deployment. Click 'Save'.
V-56317 No Change
Findings ID: WBLC-08-000222 Rule ID: SV-70571r1_rule Severity: medium CCI: CCI-001082

Discussion

Application server management functionality includes functions necessary to administer the application server and requires privileged access via one of the accounts assigned to a management role.

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

Checks

1. Access AC
2. From 'Domain Structure', select 'Environment' -> 'Servers'
3. A single server in the list will be named 'Admin Server' and this is the server which hosts AS management functionality, such as the AdminConsole application
4. All remaining servers in the list are 'Managed Servers' and these are the individual or clustered servers which will host the actual applications
5. Ensure no applications are deployed on the Admin server, rather, only on the Managed servers

If any applications are deployed on the Admin server, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Environment' -> 'Servers'
3. A single server in the list will be named 'Admin Server' and this is the server which hosts AS management functionality, such as the AdminConsole application
4. All remaining servers in the list are 'Managed Servers' and these are the individual or clustered servers which will host the actual applications
5. Utilize 'Change Center' to create a new change session
6. Undeploy all applications that are not used for AS management from the Admin server, and redeploy onto the Managed servers
7. This can be done from 'Deployments' tab -> 'Targets' tab; select each application which must be redeployed , deselect 'Admin Server' and select one or more of the Managed servers
8. Click 'Save' and restart servers if necessary
V-56321 No Change
Findings ID: WBLC-08-000223 Rule ID: SV-70575r1_rule Severity: medium CCI: CCI-001184

Discussion

This control focuses on communications protection at the session, versus packet level.

At the application layer, session IDs are tokens generated by web applications to uniquely identify an application user's session. Web applications utilize session tokens or session IDs in order to establish application user identity. Proper use of session IDs addresses man-in-the-middle attacks, including session hijacking or insertion of false information into a session.

Application servers must provide the capability to perform mutual authentication. Mutual authentication is when both the client and the server authenticate each other.

Checks

1. Access AC
2. From 'Domain Structure', select 'Environment' -> 'Servers'
3. From the list of servers, select one which needs check for Mutual Authentication configuration verification
4. From 'Configuration' tab -> 'General' tab, ensure 'Listen Port Enabled' checkbox is deselected
5. Ensure 'SSL Listen Port Enabled' checkbox is selected and a valid port number is in 'SSL Listen Port' field, e.g., 7002
6. From 'Configuration' tab -> 'SSL' tab, click 'Advanced' link
7. Ensure 'Two Way Client Cert Behavior' field value is set to 'Client Certs Requested And Enforced'
8. Repeat steps 3-7 for all servers requiring Mutual Authentication configuration checking

If any servers requiring Mutual Authentication do not have the 'SSL Listen Port Enabled' checkbox selected or the 'Two Way Client Cert Behavior' field value set to 'Client Certs Requested And Enforced', this is a finding.

Fix

1. Obtain the certificate(s) for the trusted certificate authority that signed the certificates for the client(s)
2. Access EM
3. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Security' -> 'Keystore'
4. Locate the desired keystore in which to load the client certificate(s), select and click 'Manage' button
5. From 'Manage Certificates' page, click 'Import'
6. Complete 'Certificate Type', 'Alias' and 'Certificate Source' fields and click 'OK'. Ensure the imported certificate(s) appears in the list.
7. Access AC
8. Utilize 'Change Center' to create a new change session
9. From 'Domain Structure', select 'Environment' -> 'Servers'
10. From the list of servers, select one which needs Mutual Authentication set up
11. From 'Configuration' tab -> 'SSL' tab, click 'Advanced' link
12. Set 'Two Way Client Cert Behavior' field value is set to 'Client Certs Requested And Enforced'
13. Repeat steps 7-12 for all servers requiring SSL configuration
14. From 'Domain Structure', select 'Environment' -> 'Servers', click 'Control' tab
15. Select checkbox for all servers configured in previous steps and click 'Restart SSL'
V-56323 No Change
Findings ID: WBLC-08-000224 Rule ID: SV-70577r1_rule Severity: medium CCI: CCI-001185

Discussion

If communications sessions remain open for extended periods of time even when unused, there is the potential for an adversary to hijack the session and use it to gain access to the device or networks to which it is attached. Terminating sessions after a logout event or after a certain period of inactivity is a method for mitigating the risk of this vulnerability. When a user management session becomes idle, or when a user logs out of the management interface, the application server must terminate the session.

Checks

1. Access AC
2. From 'Domain Structure', select 'Deployments'
3. Sort 'Deployments' table by 'Type' by click the column header
4. Select an 'Enterprise Application' or 'Web Application' to check the session timeout setting
5. Select 'Configuration' tab -> 'Application' tab for deployments of 'Enterprise Application' type
Select 'Configuration' tab -> 'General' tab for deployments of 'Web Application' type
6. Ensure 'Session Timeout' field value is set to organization- or policy-defined session idle time limit

If the 'Session Timeout' field value is not set to an organization- or policy-defined session idle time limit, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Deployments'
3. Sort 'Deployments' table by 'Type' by click the column header
4. Select an 'Enterprise Application' or 'Web Application' to check the session timeout setting
5. Select 'Configuration' tab -> 'Application' tab for deployments of 'Enterprise Application' type
Select 'Configuration' tab -> 'General' tab for deployments of 'Web Application' type
6. Utilize 'Change Center' to create a new change session
7. Set value in 'Session Timeout' field value to organization- or policy-defined session idle time limit. Click 'Save'
8. Repeat steps 4-7 for each 'Enterprise Application' and 'Web Application' deployment
V-56327 No Change
Findings ID: WBLC-08-000229 Rule ID: SV-70581r1_rule Severity: medium CCI: CCI-001190

Discussion

Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system.

When an application is deployed to the application server, if the deployment process does not complete properly and without errors, there is the potential that some application files may not be deployed or may be corrupted and an application error may occur during runtime.

The application server must be able to perform complete application deployments. A partial deployment can leave the server in an inconsistent state. Application servers may provide a transaction rollback function to address this issue.

Checks

1. Access AC
2. From 'Domain Structure', select the top-level domain
3. Select 'Configuration' tab -> 'General' tab
4. Ensure 'Production Mode' checkbox is selected

If the 'Production Mode' checkbox is not selected, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select the top-level domain
3. Select 'Configuration' tab -> 'General' tab
4. Check 'Production Mode' checkbox. Click 'Save'
5. Restart all servers
V-56329 No Change
Findings ID: WBLC-08-000231 Rule ID: SV-70583r1_rule Severity: medium CCI: CCI-001132

Discussion

Preventing the disclosure of transmitted information requires that applications take measures to employ some form of cryptographic mechanism in order to protect the information during transmission. This is usually achieved through the use of Transport Layer Security (TLS), SSL VPN, or IPSEC tunnel.

If the application server does not protect the application files that are created before and during the application deployment process, there is a risk that the application could be compromised prior to deployment.

Checks

1. Access AC
2. From 'Domain Structure', select 'Environment' -> 'Servers'
3. From the list of servers, select the AdminServer
4. From 'Configuration' tab -> 'General' tab, ensure 'Listen Port Enabled' checkbox is deselected
5. Ensure 'SSL Listen Port Enabled' checkbox is selected and a valid port number is in 'SSL Listen Port' field, e.g., 7002
6. From 'Configuration' tab -> 'Keystores' tab, ensure 'Custom Identity and Java Standard Trust' is selected in 'Keystores' section

If the field 'SSL Listen Port Enabled' is not selected or 'Listen Port Enabled' is selected or 'Custom Identity and Java Standard Trust' is not selected for the keystore, this is a finding.

Fix

1. Obtain an identity (private key and digital certificates) and trust (certificates of trusted certificate authorities) to configure on the server
2. Create Identity keystore and load private key and certificate using ImportPrivateKey java utility, example:
$ java utils.ImportPrivateKey -certfile <cert_file> -keyfile <private_key_file> [-keyfilepass <private_key_password>] -keystore <keystore> -storepass <storepass> [-storetype <storetype>] -alias <alias> [-keypass <keypass>]
3. Access AC
4. Utilize 'Change Center' to create a new change session
5. From 'Domain Structure', select 'Environment' -> 'Servers'
6. From the list of servers, select one which needs SSL set up
7. From 'Configuration' tab -> 'General' tab, deselect 'Listen Port Enabled' checkbox
8. Select 'SSL Listen Port Enabled' checkbox and enter a valid port number in 'SSL Listen Port' field, e.g., 7002
9. From 'Configuration' tab -> 'Keystores' tab, click 'Change' button in 'Keystores' section
10. From dropdown, select 'Custom Identity and Java Standard Trust' and click 'Save'
11. Enter the fully qualified path to Identity keystore, from step 2, in 'Custom Identity Keystore' field
12. Enter 'JKS' in the 'Custom Identity Keystore Type' field
13. Enter the Identity keystore password in 'Custom Identity Keystore Passphrase' and 'Confirm Custom Identity Keystore Passphrase' fields
14. Enter the Java Standard Trust keystore (cacerts) password in 'Java Standard Trust Keystore Passphrase' and 'Confirm Java Standard Trust Keystore Passphrase' fields
15. Leave all other fields blank and click 'Save'
16. From 'Configuration' tab -> 'SSL' tab, enter values from step 2 into corresponding fields, as follows:
- Enter <alias> into 'Private Key Alias'
- Enter <private_key_password> into 'Private Key Passphrase'
- Enter <private_key_password> into 'Confirm Private Key Passphrase'
17. Click 'Save', and from 'Change Center' click 'Activate Changes' to enable configuration changes
18. Repeat steps 4-17 for all servers requiring SSL configuration
19. From 'Domain Structure', select 'Environment' -> 'Servers', click 'Control' tab
20. Select checkbox for all servers configured in previous steps and click 'Restart SSL'
V-56333 No Change
Findings ID: WBLC-08-000235 Rule ID: SV-70587r1_rule Severity: low CCI: CCI-001209

Discussion

Information can be subjected to unauthorized changes (e.g., malicious and/or unintentional modification) at information aggregation or protocol transformation points. It is therefore imperative the application take steps to validate and assure the integrity of data while at these stages of processing.

The application server must ensure the integrity of data that is pending transfer for deployment is maintained. If the application were to simply transmit aggregated, packaged, or transformed data without ensuring the data was not manipulated during these processes, then the integrity of the data and the application itself may be called into question.

Checks

1. Access AC
2. From 'Domain Structure', select the top-level domain
3. Select 'Configuration' tab -> 'General' tab
4. Ensure 'Production Mode' checkbox is selected

If the 'Production Mode' checkbox is not selected, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select the top-level domain
3. Select 'Configuration' tab -> 'General' tab
4. Check 'Production Mode' checkbox. Click 'Save'
5. Restart all servers
V-56337 No Change
Findings ID: WBLC-08-000236 Rule ID: SV-70591r1_rule Severity: medium CCI: CCI-001092

Discussion

Employing increased capacity and bandwidth combined with service redundancy can reduce the susceptibility to some DoS attacks. When utilizing an application server in a high risk environment (such as a DMZ), the amount of access to the system from various sources usually increases, as does the system's risk of becoming more susceptible to DoS attacks.

The application server must be able to be configured to withstand or minimize the risk of DoS attacks. This can be partially achieved if the application server provides configuration options that limit the number of allowed concurrent HTTP connections.

Checks

1. Access AC
2. From 'Domain Structure', select 'Deployments'
3. Sort 'Deployments' table by 'Type' by click the column header
4. Select an 'Enterprise Application' or 'Web Application' to check the session timeout setting
5. Select 'Configuration' tab -> 'Application' tab for deployments of 'Enterprise Application' type
Select 'Configuration' tab -> 'General' tab for deployments of 'Web Application' type
6. Ensure 'Maximum in-memory Session' field value is set to an integer value at or lower than an acceptable maximum number of HTTP sessions

If a value is not set in the 'Maximum in-memory Session' field for all deployments, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Deployments'
3. Sort 'Deployments' table by 'Type' by click the column header
4. Select an 'Enterprise Application' or 'Web Application' to check the session timeout setting
5. Select 'Configuration' tab -> 'Application' tab for deployments of 'Enterprise Application' type
Select 'Configuration' tab -> 'General' tab for deployments of 'Web Application' type
6. Utilize 'Change Center' to create a new change session
7. Set value in 'Maximum in-memory Session' field value to an integer value at or lower than an acceptable maximum number of HTTP sessions. Click 'Save'
8. Repeat steps 4-7 for each 'Enterprise Application' and 'Web Application' deployment
V-56341 No Change
Findings ID: WBLC-08-000237 Rule ID: SV-70595r1_rule Severity: medium CCI: CCI-001096

Discussion

Priority protection helps the application server prevent a lower-priority application process from delaying or interfering with any higher-priority application processes. If the application server is not capable of managing application resource requests, the application server could become overwhelmed by a high volume of low-priority resource requests which can cause an availability issue.

This requirement only applies to Mission Assurance Category 1 systems and does not apply to information systems with a Mission Assurance Category of 2 or 3.

Checks

1. Access AC
2. From 'Domain Structure', select 'Environment' -> 'Work Managers'
3. Existing Work Managers will appear in the list

If Work Managers are not created to allow prioritization of resources, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Environment' -> 'Work Managers'
3. Utilize 'Change Center' to create a new change session
4. Click 'New', select 'Work Manager' radio option, click 'Next'
5. Type a unique name, click 'Next', select server(s) which to apply this work manager to, click 'Finish'
6. Select newly created work manager from table to configure
7. Set thread and capacity constraints for this work manager, target the server(s) to apply these constraints to, click 'Save'
8. Deploy applications requiring prioritization to the server(s) selected as target of the work manager in order to apply the priority conditions specified by the work manager to deployed applications
V-56343 No Change
Findings ID: WBLC-08-000238 Rule ID: SV-70597r1_rule Severity: medium CCI: CCI-001126

Discussion

Fail secure is a condition achieved by the application server in order to ensure that in the event of an operational failure, the system does not enter into an unsecure state where intended security properties no longer hold.

An example of secure failure is when an application server is configured for secure LDAP (LDAPS) authentication. If the application server fails to make a successful LDAPS connection it does not try to use unencrypted LDAP instead.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Monitoring' -> 'Port Usage'
3. In the results table, ensure values in the 'Protocol' column each end with 's' (secure)

If the protocols are not secure, this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Environment' -> 'Servers'
3. From the list of servers, select one which is assigned a protocol which does not end in 's' (secure)
4. Utilize 'Change Center' to create a new change session
5. From 'Configuration' tab -> 'General' tab, deselect the 'Listen Port Enabled' checkbox
6. Select the 'SSL Listen Port Enabled checkbox
7. Enter a valid port value in the 'SSL Listen Port' field and click 'Save'
8. Review the 'Port Usage' table in EM again to ensure all values in the 'Protocol' column end with 's' (secure)
V-56347 No Change
Findings ID: WBLC-08-000239 Rule ID: SV-70601r1_rule Severity: medium CCI: CCI-001131

Discussion

Preventing the disclosure of transmitted information requires that application servers take measures to employ approved cryptography in order to protect the information during transmission over the network. This is usually achieved through the use of Transport Layer Security (TLS), SSL VPN, or IPSEC tunnel.

If data in transit is unencrypted, it is vulnerable to disclosure. If approved cryptographic algorithms are not used, encryption strength cannot be assured.

The application server must utilize approved encryption when transmitting sensitive data.

Checks

1. Access AC
2. From 'Domain Structure', select 'Environment' -> 'Servers'
3. From the list of servers, select one which needs check for SSL configuration verification
4. From 'Configuration' tab -> 'General' tab, ensure 'Listen Port Enabled' checkbox is deselected
5. Ensure 'SSL Listen Port Enabled' checkbox is selected and a valid port number is in 'SSL Listen Port' field, e.g., 7002
6. From 'Configuration' tab -> 'Keystores' tab, ensure 'Custom Identity and Java Standard Trust' is selected in 'Keystores' section
7. Repeat steps 3-6 for all servers requiring SSL configuration checking

If any of the servers requiring cryptographic mechanisms does not have 'SSL List Port Enabled', this is a finding.

Fix

1. Obtain an identity (private key and digital certificates) and trust (certificates of trusted certificate authorities) to configure on the server
2. Create Identity keystore and load private key and certificate using ImportPrivateKey java utility, example:
$ java utils.ImportPrivateKey -certfile <cert_file> -keyfile <private_key_file> [-keyfilepass <private_key_password>] -keystore <keystore> -storepass <storepass> [-storetype <storetype>] -alias <alias> [-keypass <keypass>]
3. Access AC
4. Utilize 'Change Center' to create a new change session
5. From 'Domain Structure', select 'Environment' -> 'Servers'
6. From the list of servers, select one which needs SSL set up
7. From 'Configuration' tab -> 'General' tab, deselect 'Listen Port Enabled' checkbox
8. Select 'SSL Listen Port Enabled' checkbox and enter a valid port number in 'SSL Listen Port' field, e.g., 7002
9. From 'Configuration' tab -> 'Keystores' tab, click 'Change' button in 'Keystores' section
10. From dropdown, select 'Custom Identity and Java Standard Trust' and click 'Save'
11. Enter the fully qualified path to Identity keystore, from step 2, in 'Custom Identity Keystore' field
12. Enter 'JKS' in the 'Custom Identity Keystore Type' field
13. Enter the Identity keystore password in 'Custom Identity Keystore Passphrase' and 'Confirm Custom Identity Keystore Passphrase' fields
14. Enter the Java Standard Trust keystore (cacerts) password in 'Java Standard Trust Keystore Passphrase' and 'Confirm Java Standard Trust Keystore Passphrase' fields
15. Leave all other fields blank and click 'Save'
16. From 'Configuration' tab -> 'SSL' tab, enter values from step 2 into corresponding fields, as follows:
- Enter <alias> into 'Private Key Alias'
- Enter <private_key_password> into 'Private Key Passphrase'
- Enter <private_key_password> into 'Confirm Private Key Passphrase'
17. Click 'Save', and from 'Change Center' click 'Activate Changes' to enable configuration changes
18. Repeat steps 4-17 for all servers requiring SSL configuration
19. From 'Domain Structure', select 'Environment' -> 'Servers', click 'Control' tab
20. Select checkbox for all servers configured in previous steps and click 'Restart SSL'
V-56351 No Change
Findings ID: WBLC-09-000252 Rule ID: SV-70605r1_rule Severity: low CCI: CCI-001311

Discussion

The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the application server is able to identify and handle error conditions is guided by organizational policy and operational requirements. Adequate logging levels and system performance capabilities need to be balanced with data protection requirements.

Application servers must have the capability to log at various levels which can provide log entries for potential security-related error events.

An example is the capability for the application server to assign a criticality level to a failed login attempt error message, a security-related error message being of a higher criticality.

Checks

1. Access EM
2. Expand the domain from the navigation tree, and select the AdminServer
3. Use the dropdown to select 'WebLogic Server' -> 'Logs' -> 'Log Configuration'
4. Select the 'Log Levels' tab, and within the table, expand 'Root Logger' node
5. Log levels for system-related events can be set here
6. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Security' -> 'Audit Policy'
7. Select 'Oracle Platform Security Services' from the 'Audit Component Name' dropdown
8. Log levels for security-related events can be set here

If security-related events are not set properly, this is a finding.

Fix

1. Access EM
2. Expand the domain from the navigation tree, and select the AdminServer
3. Use the dropdown to select 'WebLogic Server' -> 'Logs' -> 'Log Configuration'
4. Select the 'Log Levels' tab, and within the table, expand 'Root Logger' node
5. Log levels for system-related events can be set here
6. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Security' -> 'Audit Policy'
7. Select 'Oracle Platform Security Services' from the 'Audit Component Name' dropdown
8. Log levels for security-related events can be set here
V-56377 No Change
Findings ID: WBLC-09-000253 Rule ID: SV-70631r1_rule Severity: medium CCI: CCI-001312

Discussion

Any application providing too much information in error logs and in administrative messages to the screen risks compromising the data and security of the application and system. The structure and content of error messages needs to be carefully considered by the organization and development team.

The application server must not log sensitive information such as passwords, private keys, or other sensitive data. This requirement pertains to logs that are generated by the application server and application server processes, not the applications that may reside on the application server. Those errors are out of the scope of these requirements.

Checks

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Logs' -> 'View Log Messages'
3. Within the search criteria, click 'Add Fields' button
4. Notice the list of available fields do not contain sensitive data

If sensitive or potentially harmful information, such as passwords, private keys or other sensitive data, is part of the error logs or administrative messages, this is a finding.

Fix

1. Access EM
2. Select the domain from the navigation tree, and use the dropdown to select 'WebLogic Domain' -> 'Logs' -> 'View Log Messages'
3. Within the search criteria, click 'Add Fields' button
4. Notice the list of available fields do not contain sensitive data
V-56379 No Change
Findings ID: WBLC-09-000254 Rule ID: SV-70633r1_rule Severity: medium CCI: CCI-001314

Discussion

If the application provides too much information in error logs and administrative messages to the screen, this could lead to compromise. The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Application servers must protect the error messages that are created by the application server. All application server users' accounts are used for the management of the server and the applications residing on the application server. All accounts are assigned to a certain role with corresponding access rights. The application server must restrict access to error messages so only authorized personnel may view them. Error messages are usually written to logs contained on the file system. The application server will usually create new log files as needed and must take steps to ensure that the proper file permissions are utilized when the log files are created.

Checks

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Users and Groups' tab -> 'Users' tab
5. From 'Users' table, select a user that must not have access to view error messages
6. From users settings page, select 'Groups' tab
7. Ensure the 'Chosen' table does not contain any of the following roles - 'Admin', 'Deployer', 'Monitor', 'Operator'
8. Repeat steps 5-7 for all users that must not have access to view error messages

If any user that should not be able to view error messages has the roles of 'Admin', 'Deployer', 'Monitor' or 'Operator', this is a finding.

Fix

1. Access AC
2. From 'Domain Structure', select 'Security Realms'
3. Select realm to configure (default is 'myrealm')
4. Select 'Users and Groups' tab -> 'Users' tab
5. From 'Users' table, select a user that must not have access to view error messages
6. From users settings page, select 'Groups' tab
7. From the 'Chosen' table, use the shuttle buttons to remove all of the following roles - 'Admin', 'Deployer', 'Monitor', 'Operator'
8. Click 'Save'
9. Repeat steps 5-8 for all users that must not have access to view error messages
V-56381 No Change
Findings ID: WBLC-09-000257 Rule ID: SV-70635r1_rule Severity: medium CCI: CCI-001265

Discussion

Incident response applications are, by their nature, designed to monitor, detect, and alarm on defined events occurring on the system or on the network. A large part of their functionality is the accurate and timely notification of events.

Application servers can act as a resource for incident responders by providing information and notifications needed for support personnel to respond to application server incidents. Notifications can be made more efficient by the utilization of groups containing the members who would be responding to a particular alarm or event.

Checks

1. Access AC
2. From 'Domain Structure', select 'Diagnostics' -> 'Diagnostic Modules'
3. Select 'Module-HealthState' from 'Diagnostic System Modules' list
4. Select 'Configuration' tab -> 'Watches and Notifications' tab. Select the 'Watches' tab from the bottom of page
5. Ensure 'ServerHealthWatch' row has 'Enabled' column value set to 'true'
6. Select 'Configuration' tab -> 'Watches and Notifications' tab. Select the 'Notifications' tab from the bottom of page
7. Ensure 'ServerHealthNotification' row has 'Enable Notification' column value set to 'true'

If 'ServerHealthNotification' is set to false, this is a finding.

Fix

1. Access AC
2. Utilize 'Change Center' to create a new change session
3. From 'Domain Structure', select 'Diagnostics' -> 'Diagnostic Modules'
4. If 'Module-HealthState' does not exist, click 'New' button. Enter 'Module-HealthState' in 'Name' field and click 'OK' button
5. Select 'Module-HealthState' from 'Diagnostic System Modules' list
6. Select 'Configuration' tab -> 'Watches and Notifications' tab. Select the 'Watches' tab from the bottom of page
7. Click 'New' button. Set the following values in the fields as shown:
'Watch Name' = 'ServerHealthWatch'
'Watch Type' = 'Collected Metrics'
'Enable Watch' = selected
8. Click 'Next'
9. Click 'Add Expressions'
10. Set 'MBean Server location' dropdown value to 'ServerRuntime'. Click 'Next'
11. Set 'MBean Type' dropdown value to 'weblogic.management.runtime.ServerRuntimeMBean'. Click 'Next'
12. Set 'Instance' dropdown value to a WebLogic Server instance to be monitored. Click 'Next'
13. Select 'Enter an Attribute Expression' radio button, enter following value in 'Attribute Expression' field: HealthState.State
14. Set 'Operator' dropdown value to '>='. Set 'Value' field to '3'. Click 'Finish'
15. Repeat steps 9-14 for all WebLogic Server instances to be monitored. Click 'Finish'
16. Continuing from step 6 above, select the 'Notifications' tab from the bottom of page
17. Click 'New' button. Set 'Type' dropdown value to 'SMTP (E-Mail)'. Click 'Next'. Set the following values in the fields as shown:
'Notification Name' = 'ServerHealthNotification'
'Enable Notification' = selected
18. Click 'Next'
19. Select an existing 'Mail Session Name', or click 'Create a New Mail Session' button to create one (JNDI name and Java mail settings must be known)
20. In 'E-Mail Recipients' text area, add list of administrator email addresses, and customize 'E-Mail Subject' and 'E-Mail Body' fields as needed. Click 'Finish'
21. Return to the 'Watches' tab from the bottom of page. Select 'ServerHealthWatch'. Select 'Notifications' tab
22. Use shuttle list to set 'ServerHealthNotification' into the 'Chosen' table. Click 'Save'
V-56383 No Change
Findings ID: WBLC-10-000270 Rule ID: SV-70637r1_rule Severity: medium CCI: CCI-000366

Discussion

It is critical that, when a system is at risk of failing to process audit logs, it detects and takes action to mitigate the failure. As part of the mitigation, the system must send a notification to designated individuals that auditing is failing, log the notification message and the individuals who received the notification. When the system is not capable of notification and notification logging, an external software package, such as Oracle Diagnostic Framework, must be used.

Checks

Review the configuration of Oracle WebLogic to determine if a tool, such as Oracle Diagnostic Framework, is in place to monitor audit subsystem failure notification information that is sent out.

If a tool is not in place to monitor audit subsystem failure notification information that is sent, this is a finding.

Fix

Install a tool, such as Oracle Diagnostics Framework, to monitor audit subsystem failure notification information.
V-56385 No Change
Findings ID: WBLC-10-000271 Rule ID: SV-70639r1_rule Severity: medium CCI: CCI-000366

Discussion

The application server can host multiple applications which require different functions to operate successfully but many of the functions are capabilities that are needed for all the hosted applications and should be managed through a common interface. Examples of enterprise wide functions are automated rollback of changes, failover and patching.

These functions are often outside the domain of the application server and so the application server must be integrated with a tool, such as Oracle Enterprise Manager, which is specific built to handle these requirements.

Checks

Review the Oracle WebLogic configuration to determine if a tool, such as Oracle Enterprise Manager, is in place to centrally manage enterprise functionality needed for Oracle WebLogic. If a tool is not in place to centrally manage enterprise functionality, this is a finding.

Fix

Install a tool such as Oracle Enterprise Manager, to handle enterprise functionality such as automated failover, rollback and patching of Oracle WebLogic.
V-56387 No Change
Findings ID: WBLC-10-000272 Rule ID: SV-70641r1_rule Severity: medium CCI: CCI-000366

Discussion

Multifactor authentication is defined as: using two or more factors to achieve authentication.

Factors include:
(i) something a user knows (e.g., password/PIN);
(ii) something a user has (e.g., cryptographic identification device, token); or
(iii) something a user is (e.g., biometric). A CAC meets this definition.

Implementing a tool, such as Oracle Access Manager, will implement multi-factor authentication to the application server and tie the authenticated user to a user account (i.e. roles and privileges) assigned to the authenticated user.

Checks

Review the WebLogic configuration to determine if a tool, such as Oracle Access Manager, is in place to implement multi-factor authentication for the users. If a tool is not in place to implement multi-factor authentication, this is a finding.

Fix

Install a tool, such as Oracle Access Manager, to handle multi-factor authentication of users.