Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
Determine whether the system documentation specifies limits on the number of concurrent DBMS sessions per account by type of user. If it does not, assume a limit of 10 for database administrators and 2 for all other users. Check the concurrent-sessions settings in the MarkLogic. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the App Server to be checked resides (e.g., Default). 3. Click the App Servers icon on the left tree menu. 4. Select the App Server in which in which to check session limits. The App Server Configuration page displays. 5. Inspect the concurrent request limit field; a value of 0 means there is no concurrent request limit (unlimited), and this is a finding. 6. If a value other than 0 but not equal to the organization-defined number is set, this is a finding. 7. Repeat for all App Servers.
Determine whether the system documentation specifies limits on the number of concurrent DBMS sessions per account by type of user. If it does not, assume a limit of 10 for database administrators and 2 for all other users. Fix the concurrent-sessions settings in MarkLogic. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the App Server to be fixed resides (e.g., Default). 3. Click the App Servers icon on the left tree menu. 4. Select the App Server in which in which to fix session limits. The App Server Configuration page displays. 5. In the concurrent request limit field, enter a value corresponding to the organization-defined maximum number of concurrent user sessions to allow. 6. Repeat for all App Servers.
If all accounts are authenticated by the organization-level authentication/access mechanism and not by the MarkLogic, this is not a finding. If there are any accounts managed by MarkLogic, review the system documentation for justification and approval of these accounts. If any MarkLogic-managed accounts exist that are not documented and approved, this is a finding. Check to see if MarkLogic is configured to use External Security from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the click the Security icon in the left tree menu. 2. Click the External Security icon. 3. If no External Security Configuration Object exists, this is a finding. 4. If at least one External Security Configuration Object exists, proceed to check all existing user accounts below. 5. Click the Security icon in the left tree menu. 6. Click the Users icon. 7. Select the user to check. 8. In the User Configuration window, verify that at least one external name for the user is defined in the External Name section, if no external names are defined and justification/approval does not exists for this account, this is a finding. 9. Repeat for all users.
If there are any accounts managed by MarkLogic, update the system documentation for justification and approval of these accounts. Configure MarkLogic to use External Security from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Security icon in the left tree menu. 2. Click the External Authentication icon. 3. Click the Create tab at the top of the External Authentication Summary window. 4. Complete the External Security Configuration Object for the available organization-level security provider. 5. Click the Security icon in the left tree menu. 6. Click the Users icon. 7. Select the user to fix. 8. In the User Configuration window, enter the external name for the user in the field in the External Name section.
Check MarkLogic settings to determine whether users are restricted from accessing objects and data they are not authorized to access. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click on the Security Icon. 2. Click the Users Icon. 3. Click on a User, and then click the Describe tab. 4. Verify the User has the appropriate Roles assigned per organization/user requirements and system documentation. 5. If the User is missing a required role or possesses a Role they do not require, this is a finding. 6. Repeat for all added Users.
Configure MarkLogic settings and access controls to permit user access only to objects and data the user is authorized to view or interact with, and to prevent access to all other objects and data. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Security Icon. 2. Click the Users Icon. 3. Select one of the added Users with a misconfigured set of Security Roles. 4. Either add or remove Security Role(s) as required per organization/user requirements and system documentation. 5. Click OK. 6. Repeat actions above for all misconfigured Users.
Review the configuration of audit logs to determine whether auditing includes details identifying the individual user. If it does not, this is a finding. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit-enabled field. A value of false means there is no auditing identifying the individual user and this is a finding. 5. If audit enabled field is true, but the settings do not meet the DoD minimum requirements for non-repudiation, this is a finding.
Configure MarkLogic audit logs to ensure auditing includes details identifying the individual user. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Configure the settings to meet DoD minimum requirements for protection against a user falsely repudiating.
Check DBMS auditing to determine whether organization-defined auditable events are being audited by the system. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means there is no auditing and this is a finding. 5. If audit enabled field is true, but the selected auditable events do not meet DoD minimum requirements, this is a finding.
Configure MarkLogic to generate audit records for at least the DoD minimum or organization-defined set of events. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Configure the auditable events to meet DoD minimum requirements.
Check MarkLogic settings and documentation to determine whether designated personnel are able to select which auditable events are being audited. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Security icon. 2. Click the Users icon on the left tree menu. 3. Inspect the Roles assigned to the Users. If a User who is designated personnel does not have the admin role, this is a finding. 4. Inspect the Roles assigned to the Users. If a User who is not designated personnel has the admin role, this is a finding.
Configure the DBMS's settings to allow designated personnel to select which auditable events are audited. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Security icon. 2. Click the Users icon on the left tree menu. 3. Inspect the Roles assigned to the Users. For designated personnel, assign the admin role and change user roles as necessary. 4. Inspect the Roles assigned to the Users. For non-designated personnel, remove the admin role and change user roles as necessary.
Check the MarkLogic security and audit configurations to verify that audit records are produced when privileges/permissions/role memberships are retrieved, if they are required by the system documentation or organizational policies. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means there is no auditing and this is a finding. 5. If audit enabled field is true, but the security-access audit event is not selected, this is a finding. 6. If security-access audit event is selected, but "failed events only" is selected in the outcome setting of the audit restrictions is selected, this is a finding.
Change the MarkLogic security and audit configurations to ensure audit records are produced when privileges/permissions/role memberships are retrieved, if they are required by the system documentation or organizational policies. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the security-access audit event. 6. Enable "both" under the outcome setting in the audit restrictions section.
If MarkLogic is currently required to audit the retrieval of privilege/permission/role membership information, check the MarkLogic security and audit configurations to verify audit records are produced when the DBMS denies retrieval of privileges/permissions/role membership. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means there is no auditing and this is a finding. 5. If audit enabled field is true, but the security-access audit event is not selected, this is a finding. 6. If security-access audit event is selected, but "successful events only" is selected in the outcome setting of the audit restrictions is selected, this is a finding.
If MarkLogic is currently required to audit the retrieval of privilege/permission/role membership information, change the MarkLogic security and audit configurations to ensure audit records are produced when the DBMS denies retrieval of privileges/permissions/role membership. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the security-access audit event. 6. Enable "both" under the outcome setting in the audit restrictions section.
Check that MarkLogic session-level auditing and specific session audits are currently defined and session auditing is enabled; or if a third-party product is available for session auditing. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field, a value of false means there is no auditing, this is a finding.
Configure MarkLogic session-level auditing, ensure specific session audits are currently defined, and enable session auditing or verify a third-party product is available for session auditing. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true.
If the application owner has determined the need for system availability outweighs the need for a complete audit trail, this is not applicable. If the system is configured for High Availability (HA), and the application owner has determined the need for a complete audit trail outweighs the need for system availability, this is a finding. The following are the minimum configuration requirements for HA: - Failover enabled = True for the Group - Security database forests are configured with replica forests - Databases associated with the users application are configured with replica forests If HA is a requirement for Administrative functions: - App Services database forests are configured with replica forests - Modules database forests are configured with replica forests - Documents database forests are configured with replica forests - Triggers database forests are configured with replica forests Perform the check for HA from the MarkLogic Admin Interface with a user that holds administrative-level privileges: 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. On the Configuration tab, check the value of "failover enabled". True = HA can be enabled False = HA cannot be enabled 4. Click the Databases icon in the left tree menu. 5. Click the Security Database. 6. Click the Status Tab. 7. Review the Forest section: a. Count the number of forests with a state of "open". b. Count the number of forests with a state of "[sync|async|wait] replicating". c. The number of replicating forests should be greater than or equal to the number of open forests. 8. Repeat steps 4-7 for the user application databases (data/content, modules, triggers, etc.). 9. Repeat steps 4-7 for the following databases if HA is required for Administrative functions: - App Services - Modules - Documents - Triggers
Configure the database to go offline, rolling back all in-flight transactions, in the case of an auditing failure due to insufficient disk space. Perform the fix from the MarkLogic Admin Interface with a user that holds administrative-level privileges: 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. On the Configuration tab set the value of "failover enabled" to "false". 4. Click OK to save the configuration.
Review controls and permissions are sufficient to protect audit log files from unauthorized access at the operating-system level. Verify User ownership, Group ownership, and permissions on the "audit" file: > ls -al /var/opt/MarkLogic/Logs/AuditLog.txt If the User owner is not "daemon", this is a finding If the Group owner is not "daemon", this is a finding. If the directory is more permissive than 700, this is a finding.
Apply controls and modify permissions to protect audit log files from unauthorized access at the operating-system level. Change owner and group of /var/opt/MarkLogic/Logs to user daemon from the command line with a privileged user: > chown daemon.daemon /var/opt/MarkLogic/Logs Change permissions of /var/opt/MarkLogic/Logs to 700 (rwx by owner only) from the command line > chmod 700 /var/opt/MarkLogic/Logs
Review controls and permissions are sufficient to protect audit log files from unauthorized access at the operating-system level. Verify User ownership, Group ownership, and permissions on the "audit" file: > ls -al /var/opt/MarkLogic/Logs/AuditLog.txt If the User owner is not "daemon", this is a finding If the Group owner is not "daemon", this is a finding. If the directory is more permissive than 700, this is a finding.
Apply controls and modify permissions to protect audit log files from unauthorized access at the operating-system level. Change owner and group of /var/opt/MarkLogic/Logs to user daemon from the command line with a privileged user: > chown daemon.daemon /var/opt/MarkLogic/Logs Change permissions of /var/opt/MarkLogic/Logs to 700 (rwx by owner only) from the command line > chmod 700 /var/opt/MarkLogic/Logs
Review controls and permissions are sufficient to protect audit log files from unauthorized access at the operating-system level. Verify User ownership, Group ownership, and permissions on the "audit" file: > ls -al /var/opt/MarkLogic/Logs/AuditLog.txt If the User owner is not "daemon", this is a finding If the Group owner is not "daemon", this is a finding. If the directory is more permissive than 700, this is a finding.
Apply controls and modify permissions to protect audit log files from unauthorized access at the operating-system level. Change owner and group of /var/opt/MarkLogic/Logs to user daemon from the command line with a privileged user: > chown daemon.daemon /var/opt/MarkLogic/Logs Change permissions of /var/opt/MarkLogic/Logs to 700 (rwx by owner only) from the command line > chmod 700 /var/opt/MarkLogic/Logs
Review access permissions to tools used to view or modify audit log data. Since MarkLogic Audit logs are stored in plain text files, this includes text editors provided by the OS. Alternatively, enable Encryption-at-Rest for the logs. This would ensure only individuals/systems with a valid encryption key may access the data within logs and audit files. If appropriate permissions and access controls are not applied to prevent unauthorized modification of these tools, and Encryption-at-Rest is not enabled for logs, this is a finding. Perform the check from the MarkLogic Admin Interface with a user that holds administrative-level privileges. 1. Click the Clusters icon on the left tree menu. 2. Click the Keystore tab. 3. If "logs encryption" is set to "off", this is a finding.
Add or modify access controls and permissions for tools used to view or modify audit log data, including OS text editors. Since MarkLogic Audit logs are stored in plain text files, this includes text editors provided by the OS. Tools must be accessible by authorized personnel only. Alternatively, Encryption-at-Rest for system logs may be enabled to prevent unauthorized disclosure of contained information. Perform the fix from the MarkLogic Admin Interface with a user that holds administrative-level privileges. 1. Click the Clusters icon on the left tree menu. 2. Click the Keystore tab. 3. Change "logs encryption" setting to "on".
Review access permissions to tools used to view or modify audit log data. Since MarkLogic Audit logs are stored in plain text files, this includes text editors provided by the OS. Alternatively, Encryption-at-Rest can be enabled for the logs. This would ensure only individuals/systems with a valid encryption key may access the data within logs and audit files. If appropriate permissions and access controls are not applied to prevent unauthorized modification of these tools, and Encryption-at-Rest is not enabled for logs, this is a finding. Perform the check from the MarkLogic Admin Interface with a user that holds administrative-level privileges. 1. Click the Clusters icon on the left tree menu. 2. Click the Keystore tab. 3. If "logs encryption" is set to "off", this is a finding.
Add or modify access controls and permissions to tools used to view or modify audit log data, including OS text editors. Since MarkLogic Audit logs are stored in plain text files, this includes text editors provided by the OS. Tools must be accessible by authorized personnel only. Alternatively, Encryption-at-Rest for system logs may be enabled to prevent unauthorized disclosure of contained information. Perform the fix from the MarkLogic Admin Interface with a user that holds administrative-level privileges. 1. Click the Clusters icon on the left tree menu. 2. Click the Keystore tab. 3. Change "logs encryption" setting to "on".
Review access permissions to tools used to view or modify audit log data. Since MarkLogic Audit logs are stored in plain text files, this includes text editors provided by the OS. Alternatively, Encryption-at-Rest can be enabled for the logs. This would ensure only individuals/systems with a valid encryption key may access the data within logs and audit files. If appropriate permissions and access controls are not applied to prevent unauthorized modification of these tools, and Encryption-at-Rest is not enabled for logs, this is a finding. Perform the check from the MarkLogic Admin Interface with a user that holds administrative-level privileges. 1. Click the Clusters icon on the left tree menu. 2. Click the Keystore tab. 3. If "logs encryption" is set to "off", this is a finding.
Add or modify access controls and permissions to tools used to view or modify audit log data, including OS text editors. Since MarkLogic Audit logs are stored in plain text files, this includes text editors provided by the OS. Tools must be accessible by authorized personnel only. Alternatively, Encryption-at-Rest for system logs may be enabled to prevent unauthorized disclosure of contained information. Perform the fix from the MarkLogic Admin Interface with a user that holds administrative-level privileges. 1. Click the Clusters icon on the left tree menu. 2. Click the Keystore tab. 3. Change "logs encryption" setting to "on".
Review monitoring procedures and implementation evidence to verify monitoring of changes to MarkLogic software libraries, related applications, and configuration files is done. If a third-party file automated tool is used, this is not a finding. To check for automated monitoring, issue the following command at a command prompt with a user that has administrative privileges: Check to see if the crond service is running for scheduling recurring tasks. If it is not running, this is a finding. > sudo systemctl status crond Check to see if ml-filechange-mon.sh is in the cron schedule, and runs frequently enough to meet System Security Plan (SSP) requirements. If the script is not scheduled to run, or does not run frequently enough to meet the SSP requirements, this is a finding. > sudo crontab -l | grep ml-filechange Check ml-filechange-mon.sh to verify email addresses have been configured to receive alerts. If no email addresses have been added, this is a finding. > grep "EMAIL_LIST" /path/to/ml-filechange-mon.sh
Implement procedures to monitor for unauthorized changes to DBMS software libraries, related software application libraries, and configuration files. If a third-party automated tool is not employed, an automated job that reports file information on the directories and files of interest and compares them to the baseline report for the same will meet the requirement. The supplemental file "ml-filechange-mon.sh" can be used to meet this requirement. - Edit the ml-filechange-mon.sh script with the correct email addresses and notification level. - Place the script in a location that can be accessed by the cron daemon. - Edit the crontab, and configure the script to run frequently enough to meet DoD minimum requirements.
Review procedures for controlling, granting access to, and tracking use of the MarkLogic software installation account. If access or use of this account is not restricted to the minimum number of personnel required or if unauthorized access to the account has been granted, this is a finding. At a command prompt, on the system where MarkLogic is installed run the following command: > ls -al /var/opt/MarkLogic If files are owned by the user "daemon", this is not a finding. If user is not "daemon", verify that Organization policy and system documentation states that a separate user is needed and approved.
Review procedures for controlling, granting access to, and tracking the use of the MarkLogic software installation account. Ensure use of this account is restricted to the minimum number of personnel required and no unauthorized access to the account has been granted. MarkLogic should be installed by a user account that has "sudo" privileges to run "yum" or "rpm". At a command prompt, on the system where MarkLogic is installed, run one of the following commands: > sudo yum install /path/to/MarkLogic-version.rpm or > sudo rpm -i /path/to/MarkLogic-version.rpm Either of these commands will install MarkLogic with the owner set correctly to "daemon". If user is not "daemon", ensure Organization policy and system documentation states that a separate user is needed and approved.
Only applications required for the functioning and administration, not use of, MarkLogic should be located in the same disk directory as the MarkLogic software libraries. Review the MarkLogic software library directories /opt/MarkLogic and /var/opt/MarkLogic and note other root directories located on the same disk directory or any subdirectories. If any non-MarkLogic software directories exist on the disk directory, examine or investigate their use. If any of the directories are used by other applications, including third-party applications that use MarkLogic, this is a finding. At a command prompt on the MarkLogic system, run the following commands: > ls /opt/MarkLogic If any directories exist that are not in the list below, this is a finding. Admin bin FlexRep include Lang Messages Apps Config HealthCheck Installer mlcmd Plugins Assets Converters java lib Modules Samples At a command prompt on the MarkLogic system, run the following commands: > ls /var/opt/MarkLogic If any directories exist that are not in the list below, this is a finding. kms Lib run Stage Forests Journals Label Logs Temp If other software is installed in those directories and is not approved by Org Policy, this is a finding.
Only applications that are required for the functioning and administration, not use of, MarkLogic should be located in the same disk directory as the MarkLogic software libraries. Review the MarkLogic software library directories /opt/MarkLogic and /var/opt/MarkLogic and note other root directories located on the same disk directory or any subdirectories. Remove any other applications, including third-party applications that use MarkLogic that are not approved by Org Policy. At a command prompt on the MarkLogic system, run the following commands: If the software was installed via yum/rpm > sudo yum remove [Software-Package-Name] If the software was installed via unzip/untar. > sudo rm -r [/path/to/unauthorized/software]
Review system documentation to identify accounts authorized to own database objects. Review accounts that own objects in the database(s). Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Security icon. 2. Click the Users icon on the left tree menu. 3. Inspect the Users. If there is a User who is not authorized to own database objects, this is a finding.
Assign ownership of authorized objects to authorized object owner accounts. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Security icon. 2. Click the Users icon on the left tree menu. 3. Inspect the Users. For users who are not authorized to own database objects, remove the users.
Identify the group(s)/role(s) established for MarkLogic modification and the list of users in those group(s)/roles. Identify the individuals authorized to modify the DBMS. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Security icon. 2. Click the Users icon on the left tree menu. 3. Inspect the Users. If there is a User who is not authorized to own database objects, this is a finding.
Revoke unauthorized memberships in the MarkLogic modification group(s)/role(s). Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Security icon. 2. Click the Users icon on the left tree menu. 3. Inspect the Users. For users who are not authorized to own database objects, remove the users.
Review the list of components and features installed with MarkLogic, and check for unused components or features. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Databases icon. 2. Inspect the list of databases. If there is an unused database, this is a finding. 3. Click the Forests icon. 4. Inspect the list of forests. If there is an unused forest, this is a finding. 5. Click the Groups >> [GroupName] >> App Servers 6. Inspect the list of app servers. If there is an unused database, this is a finding.
Remove any database objects and applications that are installed to support them. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Databases icon. 2. Inspect the list of databases and select an unused database. 3. Click Delete and confirm the deletion. 4. Click the Forests icon. 5. Inspect the list of forests and select an unused forest. 6. Click Delete and confirm the deletion. 7. Click the Groups >> [GroupName] >> App Servers. 8. Inspect the list of app servers and select an unused app server. 9. Click Delete and confirm the deletion.
Verify whether external executables are being used. If so, check with the ISSO to determine if the use of the external executables (MLSQL/odbc client and Converters) is authorized. If it is not, this is a finding. To check for Converters, issue the following command at a command prompt with a user that has administrative privileges. > sudo yum info MarkLogicConverters If the command returns information on the version of MarkLogic converters installed, and use of this package has not been authorized, this is a finding. To check for MLSQL/odbc client, issue the following command at a command prompt with a user that has administrative privileges. > sudo yum info mlsqlodbc If the command returns information on the version of MLSQL odbc client install, and use of this package has not been authorized, this is a finding.
If the use of the included external executables (MLSQL/odbc and/or CONVERT) is not authorized by the ISSO then remove the executables from the MarkLogic installation directory, find the executables by name for the different operating systems. To remove Converters, issue the following command at a command prompt with a user that has administrative privileges. > sudo yum remove MarkLogicConverters To remove MLSQL/odbc client, issue the following command at a command prompt with a user that has administrative privileges. > sudo yum info mlsqlodbc
Review the DBMS settings and local documentation for functions, ports, protocols, and services that are approved. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the App Server to check resides (e.g., Default). 3. Click the App Servers icon on the left tree menu. 4. Inspect the list of App Servers and associated Protocols and Ports. 5. If any App Server has an associated protocol or port that is not approved, this is a finding.
Disable functions, ports, protocols, and services that are not approved. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the App Server to check resides (e.g., Default). 3. Click the App Servers icon on the left tree menu. 4. Inspect the list of App Servers and associated Protocols and Ports. 5. If any App Server has an associated protocol or port that is not approved, remove the App Server by selecting the server and selecting either "Disable" or "Delete".
Review DBMS settings to determine whether organizational users are uniquely identified and authenticated when logging on/connecting to the system. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the App Server to be checked resides (e.g., Default). 3. Click the App Servers icon on the left tree menu. 4. Select each of the App Servers. 5. Inspect the selected authentication method. If "application-level" is selected and a user other than "nobody" (or equivalent) is set as the default user, this is a finding.
Configure MarkLogic settings to uniquely identify and authenticate all organizational users who log on/connect to the system. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the App Server to be checked resides (e.g., Default). 3. Click the App Servers icon on the left tree menu. 4. Select each of the App Servers. 5. Inspect the selected authentication method. If "application-level" is selected and a user other than "nobody" (or equivalent) is set as the default user, then change the default user to "nobody".
Review MarkLogic settings to see if password authentication is being used, and whether password complexity and lifetime rules are being enforced. Check for MarkLogic Password Plugin from the MarkLogic Query Console with a user that holds administrative-level privileges. 1. Select "XQuery" in the Query Type drop down and copy the following code into the window: xquery version "1.0-ml"; import module namespace plugin = "http://marklogic.com/extension/plugin" at "/MarkLogic/plugin/plugin.xqy"; plugin:plugins("http://marklogic.com/xdmp/security/password-check") 2. Run the script. If the script returns "your query returned an empty sequence", then no password plugin is present. 3. If the script returns a file name or file names (e.g., password-check-minimum-length.xqy), then review the file/s in the <MarkLogic Home>/Plugins directory to verify compliance with DOD minimum password requirements. 4. Log in to the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 5. Click the Groups icon. 6. Click the group in which the App Server to be checked resides (e.g., Default). 7. Click the App Servers icon on the left tree menu. 8. Select each of the App Servers. 9. Inspect the selected authentication method, if "basic", "digestbasic", or "digest" is selected and there is not a custom password plugin, or if the password plugin does not meet DOD minimum requirements, this is a finding.
If the use of passwords is not needed, configure MarkLogic to prevent password use. If the DBMS can inherit password complexity rules from the operating system or access control program, configure it to do so using one of the following methods: 1. Configure the MarkLogic server to use Kerberos, SAML, or Certificate based authentication. 2. Develop plugin to enforce password complexity. Examples can be found in MarkLogic Application Developers Guide. Plugins must enforce the following rules for passwords: a. minimum of 15 characters, including at least one of each of the following character sets: - Uppercase - Lowercase - Numeric - Special characters (e.g., ~ ! @ # $ % ^ & * ( ) _ + = - ' [ ] / ? > <) b. Minimum number of characters changed from previous password: 50 percent of the minimum password length (eight) c. Password lifetime limits for interactive accounts: Minimum 24 hours, maximum 60 days d. Password lifetime limits for non-interactive accounts: Minimum 24 hours, maximum 365 days e. Number of password changes before an old one may be reused: Minimum of five Develop a custom extension that enforces the password complexity and lifetime. See https://docs.marklogic.com/guide/app-dev/plugins#id_91783
Review MarkLogic configuration settings for encrypting passwords in transit across the network. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the App Server to be checked resides (e.g., Default). 3. Click the App Servers icon on the left tree menu. 4. Select each of the App Servers. 5. Inspect the selected authentication method, if "basic" or "digest-basic" is selected, this is a finding. If Application Level is selected and the application server is not configured for SSL, this is a finding
If the MarkLogic application server in question is configured with "digest" or "digest-basic" authentication or is configured with "Application Level" authentication and is not SSL enabled, implement the corrective action outlined below. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the App Server to be checked resides (e.g., Default). 3. Click the App Servers icon on the left tree menu. 4. Select each of the App Servers. 5. Inspect the selected authentication method, if "basic" or "digest-basic" is selected, change the authentication method to something other than those two. If Application Level is selected, ensure the application server is configured for SSL.
Review DBMS configuration to verify that certificates being accepted by the DBMS are validated by performing RFC 5280-compliant certification path validation, specifically periodic revocation list processing, with custom application code that performs these functions. To check for existing CRLs, use the MarkLogic QConsole and execute the following XQuery command against the Security Database: cts:uri-match("http://marklogic.com/xdmp/pki/crls/*") If there are CRLs, then it will return which CRLs are loaded, if not then it will return an empty sequence. If any required CRLs are missing, this is a finding.
Organizations must develop a strategy for maintaining a record of CRLs that have been applied to MarkLogic as well as a strategy for regularly obtaining updated CRLs from applicable Certificate Authorities. Use one of the following two methods to add a CRL to MarkLogic: Option 1 - Use the MarkLogic REST API "PUT /manage/v2/certificate-revocation-lists" (requires user authenticating to the system and have security and manage-admin roles) Using a compatible HTTP request generator (i.e., Postman or curl) construct an HTTP PUT request: EXAMPLE: curl -X PUT --anyauth --user admin:admin --header "Content-Type:text/html" \ -d "http://crl.verisign.com/pca3.crl" \ http://localhost:8002/manage/v2/certificate-revocation-lists?url=url NOTE: If the "url" param is a CRL then the request body must contain the PEM- or DER-encoded CRL. If the "url" parameter is a URL, then the request body must contain the URL from which the CRL was downloaded. Option 2 - Use the Query Console in MarkLogic to insert the CRL using pki:insert-certificate-revocation-list() method (requires user authenticating to the system have security and manage-admin roles) EXAMPLE: xquery version "1.0-ml"; import module namespace pki = "http://marklogic.com/xdmp/pki" at "/MarkLogic/pki.xqy"; let $URI := "http://crl.verisign.com/pca3.crl" return pki:insert-certificate-revocation-list( $URI, xdmp:document-get($URI)/binary() )
Review MarkLogic configuration to determine whether SSL FIPS has been enabled. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Clusters icon on the left tree menu. 2. Select the local cluster. Click the Configure tab and verify "ssl fips enabled" is set to true. If not, this is a finding.
Ensure SSL FIPS has been enabled in MarkLogic server. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Clusters icon on the left tree menu. 2. Select the local cluster. Click the Configure tab. 3. Set the "ssl fips enabled" setting to true and click "ok".
Review MarkLogic configuration to determine whether SSL FIPS has been enabled. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Clusters icon. 2. In the Summary tab, if the value for "ssl fips enabled" is "false", this is a finding.
Ensure SSL FIPS has been enabled in MarkLogic server. Perform the fix operation from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Clusters icon. 2. Click the Configure tab. 3. Set the value for "ssl fips enabled" to "true" and click OK.
Review MarkLogic settings to determine if non-organizational users are uniquely identified and authenticated. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Security icon. 2. Click the Users icon on the left tree menu. 3. Inspect the Users; if there is a non-organizational user who is not uniquely identified, this is a finding.
If non-organizational users are not uniquely identified and authenticated, implement the steps below. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Security icon. 2. Click the Users icon on the left tree menu. 3. Inspect the Users, and remove any non-organizational users who are not uniquely identified.
Validate MarkLogic User accounts to verify only Administrators have Administrative roles assigned and each Administrator has an individual account. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Security icon. 2. Click the Users icon on the left tree menu. 3. Inspect the Users. If administrator and general user accounts are not separated, this is a finding.
Configure MarkLogic user roles so that only actual Administrators are assigned Administrative roles and each Administrator has an individual account. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Security icon. 2. Click the Users icon on the left tree menu. 3. Inspect the Users. 4. Remove administrative privileges from general user accounts, and ensure administrators have separate administrative accounts.
Review MarkLogic settings to determine whether protections against man-in-the-middle attacks that guess at session identifier values are enabled. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the App Server to check resides (e.g., Default). 3. Click the App Servers icon on the left tree menu. 4. If any of the application servers has a "no" under the SSL column, this is a finding.
Configure MarkLogic settings to enable protections against man-in-the-middle attacks that guess at session identifier values. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. See: https://docs.marklogic.com/guide/security/SSL 1. Click the Groups icon. 2. Click the group in which the App Server to check resides (e.g., Default). 3. Click the App Servers icon on the left tree menu. 4. For each of the app servers that has a "no" under the SSL column, follow the instructions outlined in MarkLogic Server - Security Guide Rev 9-0.9, Chapter 9.0: Configuring SSL on App Servers.
If the application owner and Authorizing Official have determined that encryption of data at rest is NOT required, this is not a finding. If full-disk encryption is being used, this is not a finding. Review system documentation to determine whether the system handles classified information. If the system does not handle classified information, the severity of this check should be downgraded to Category II. Review MarkLogic settings to determine whether controls exist to protect the confidentiality and integrity of data at rest in the database. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Databases icon. 2. Click the database to be checked. 3. If the "data encryption" drop-down is set to ON, this is not a finding, and no further checks need to be performed. 4. If the "data encryption" drop-down is set to OFF, continue the check. 5. If the "data encryption" drop-down is set to default-cluster, continue the check with the steps below: a. Click the Clusters icon. b. Click [Cluster Name]. c. Click the Keystore Tab. d. If the Cluster Default Encryption configuration is OFF, this is a finding. Findings Matrix ------------------------------------------------------- Database Cfg. | Cluster Cfg | Finding -------------------------------------------------------- ON | *Any* | No *Any* | Force | No Default-cluster | Default-on | No Default-cluster | Default-off | Yes Off | Default-on | Yes Off | Default-off | Yes
Apply appropriate controls to protect the confidentiality and integrity of data at rest in the database. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Databases icon. 2. Click the database to be fixed. 3. Select ON from the data encryption drop-down.
If the application owner and Authorizing Official have determined that encryption of data at rest is NOT required, this is not a finding. If full-disk encryption is being used, this is not a finding. Review system documentation to determine whether the system handles classified information. If the system does not handle classified information, the severity of this check should be downgraded to Category II. Review MarkLogic settings to determine whether controls exist to protect the confidentiality and integrity of data at rest in the database. From a command line at the OS level, verify User ownership, Group ownership, and permissions on the files: > ls -al /var/opt/MarkLogic/ If the User owner is not "daemon", and encryption at rest is not enabled, this is a finding. If the Group owner is not "daemon", and encryption at rest is not enabled, this is a finding. If the directory is more permissive than 750, and encryption at rest is not enabled, this is a finding. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Databases icon. 2. Click the database to be checked. 3. If the "data encryption" drop-down is set to ON, this is not a finding, and no further checks need to be performed. 4. If the "data encryption" drop-down is set to OFF, continue the check. 5. If the "data encryption" drop-down is set to default-cluster, continue the check with the steps below: a. Click the Clusters icon. b. Click [Cluster Name]. c. Click the Configure Tab. d. If the Cluster Default Encryption configuration is OFF, this is a finding. Findings Matrix ------------------------------------------------------- Database Cfg. | Cluster Cfg | Finding -------------------------------------------------------- ON | *Any* | No *Any* | Force | No Default-cluster | Default-on | No Default-cluster | Default-off | Yes Off | Default-on | Yes Off | Default-off | Yes
Apply appropriate controls to protect the confidentiality and integrity of data at rest in the database. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Databases icon. 2. Click the database to be fixed. 3. Select ON from the data encryption drop-down. OR Change owner and group of /var/opt/MarkLogic to user daemon from the command line with a privileged user: > chown -R daemon.daemon /var/opt/MarkLogic Change permissions of /var/opt/MarkLogic to 750 (rwx by owner only) from the command line > chmod 750 /var/opt/MarkLogic
Check MarkLogic settings and custom database code to verify that error messages do not contain information beyond what is needed for troubleshooting the issue. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group that is to be checked. 3. Check settings for "file log level" and "system log level". If "file log level" is set to "debug", "finer", or "finest", this is a finding. If "system log level" is set to "debug", "finer", or "finest", this is a finding.
Configure MarkLogic log settings not to divulge sensitive information or information useful for system identification in error messages. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group that is to be fixed. 3. Set the "system log level" to "notice" and the "file log level" to "info".
MarkLogic supports role-based access control for all entities/documents maintained within the database. User roles and applied document permissions determine access. For example, if a document has read permission for role1 and read permission for role2, a user who possesses either role1 or role2 can read that document. Permissions in this example are evaluated using OR semantics. Adding a Compartment to a role ensures access controls are evaluated using AND semantics when determining user access to a given resource. This security level is applied to the entire document/resource. 1. Verify applicable roles are configured with the necessary access Compartments for the specified role. 2. Verify all documents inserted into the MarkLogic database have the applicable permission (Compartment) applied. If applicable roles do not have Compartments defined, this is a finding. If documents inserted into the database do not have the applicable document permissions (Compartments) applied, this is a finding. Additionally, MarkLogic can enforce Element Level Security and Element Redaction ensuring users can only access specific elements of information they are permitted to access. Data a user is not permitted to see may be redacted or excluded all together. Element Level Security also ensures document searches do not return results where the search value is within an Element the user does not have access to. This security level is applied to specified elements within a given document. When/where applicable: 1. Navigate to the MarkLogic Admin page >> Security >> Protected Paths. 2. Verify the applicable elements requiring additional protections are defined using an XQuery path expression (applicable for both XML and JSON document types). 3. Verify the applicable role(s) are added against the specified path expression. If specific document elements require additional protections and no Protected Paths or Protect Path roles are defined, this is a finding.
See specific MarkLogic documentation regarding Compartment level security for necessary steps. Applying Document Compartment Security: 1. Navigate to the MarkLogic Admin page >> Security >> Roles. 2. Create a new role and assign applicable roles/permissions. 3. Provide a Compartment name to the role. 4. Ensure all data ingestion mechanisms (i.e., document insertion code/logic) apply the necessary applicable security permissions. Applying Element-Level Security: 1. Navigate to the MarkLogic Admin page >> Security >> Protected Paths. 2. Create a Protected Path by specifying an XQuery path expression identifying the element requiring specific protections. 3. Add one or more applicable roles, specify their capability, and then save the configuration. 4. Repeat step 3 for each element requiring additional protections.
MarkLogic supports role-based access control for all entities/documents maintained within the database. User roles and applied document permissions determine access. For example, if a document has read permission for role1 and read permission for role2, a user who possesses either role1 or role2 can read that document. Permissions in this example are evaluated using "OR" semantics. Adding a Compartment to a role ensures access controls are evaluated using "AND" semantics when determining user access to a given resource. This security level is applied to the entire document/resource. 1. Verify applicable roles are configured with the necessary access Compartments for the specified role. 2. Verify all documents inserted into the MarkLogic database have the applicable permission (Compartment) applied. If applicable roles do not have Compartments defined, this is a finding. If documents inserted into the database do not have the applicable document permissions (Compartments) applied, this is a finding. Additionally, MarkLogic can enforce Element-Level Security and Element Redaction ensuring users can only access specific elements of information they are permitted to access. Data a user is not permitted to see may be redacted or excluded all together. Element-Level Security also ensures document searches do not return results where the search value is within an Element to which the user does not have access. This security level is applied to specified elements within a given document. When/where applicable: 1. Navigate to the MarkLogic Admin page >> Security >> Protected Paths. 2. Verify the applicable elements requiring additional protections are defined using an XQuery path expression (applicable for both XML and JSON document types). 3. Verify the applicable role(s) are added against the specified path expression. If specific document elements require additional protections and no Protected Paths or Protect Path roles are defined, this is a finding.
See specific MarkLogic documentation regarding Compartment level security for necessary steps. Applying Document Compartment Security: 1. Navigate to the MarkLogic Admin page >> Security >> Roles. 2. Create a new role and assign applicable roles/permissions. 3. Provide a Compartment name to the role. 4. Ensure all data ingestion mechanisms (i.e., document insertion code/logic) apply the necessary applicable security permissions. Applying Element-Level Security: 1. Navigate to the MarkLogic Admin page >> Security >> Protected Paths. 2. Create a Protected Path by specifying an XQuery path expression identifying the element requiring specific protections. 3. Add one or more applicable roles and specify their capability then save the configuration. 4. Repeat step 3 for each element requiring additional protections.
Review the MarkLogic system documentation to obtain the definition of the database/DBMS functionality considered privileged in the context of the system in question. Review MarkLogic users and assigned roles 1. Navigate to the MarkLogic Admin page >> Security >> Roles. 2. Validate user-created roles have appropriate permissions/roles applied. 3. Navigate to the MarkLogic Admin page >> Security >> Users. 4. Verify user-created Users are only granted roles meeting their specific requirements and do not allow for unnecessary elevated privileges. If Users are assigned roles providing unnecessary elevated or privileged permissions, this is a finding. If Roles are defined with unnecessary elevated permissions, this is a finding.
Review MarkLogic User and Role configurations to ensure correct privileges are assigned and update as required. 1. Navigate to the MarkLogic Admin page >> Security >> Roles. 2. Select specific roles (usually custom defined roles by administrator) and only apply privileges with the least amount of permissions required for a given role. 3. Navigate to the MarkLogic Admin Page >> Security >> Users. 4. Select specific users (usually custom defined users by an administrator) and add/remove roles allowing for the least amount of privileges required for the specified user. 5. Save configuration and repeat for each user-defined User/Role.
By default, MarkLogic does not allow any user to perform any actions within or against the system unless that user is assigned specific roles granting access/execution privileges. All read, update, or execute privileges are defined by specifying applicable system roles/permissions. 1. Verify MarkLogic user-defined modules are created and stored with applicable document permissions. 2. Verify users interacting with the system are assigned to roles with the least amount of privileges required for a given user. 3. Navigate to the MarkLogic Admin page >> Security >> Users. 4. Validate all system users are assigned to roles with the least amount of privileges necessary while allowing them to interact with system resources and perform applicable actions based upon their use case. If a user is assigned roles exceeding their required access/privilege level, this is a finding. If custom modules are stored with unnecessary elevated document permissions, this is finding.
Correcting issues with unnecessary elevated privileges, and access to or execution of system resources, is a two-step process. Correcting custom code/module permissions: When inserting custom code into a given Modules database, ensure those custom modules have the correct permissions applied by writing them to the database with the applicable/correct document permissions. The permissions should specify specific roles and permissions (i.e., read, update, execute) Correcting User privileges: 1. Navigate to the MarkLogic Admin page >> Security >> Roles. 2. Select a role under consideration and add/remove specific roles or permissions allowing the required level of permissions for a given role. 3. Save the configuration. 4. Navigate to the MarkLogic Admin page >> Security >> Users. 5. Select a user under consideration and add or remove applicable roles providing the user with the least level of privileges required for acceptable interaction with the system. 6. Repeat as required for each User and Role (usually these are user-defined roles or users).
Investigate whether there have been any incidents where the MarkLogic server ran out of audit log space since the last time the space was allocated or other corrective measures were taken. If there have been, this is a finding.
All MarkLogic logs, including audits, are stored within the Data directory (i.e., /var/opt/MarkLogic/Logs). MarkLogic requires the lesser of 2x the content forest size, or 96GB of free space. System Administrators must ensure/configure between 1.5 and 3x free disk space for normal operations.
Review system configuration to determine if appropriate support staff are not notified immediately upon storage volume utilization reaching 75 percent. If the Organization is not using Ops Director, or a third-party tool for storage volume utilization/alerting, this is a finding.
Configure the system to notify appropriate support staff immediately upon storage volume utilization reaching 75 percent. Use MarkLogic Ops Director with Alerts, or third-party tool to monitor storage Volume utilization/alerting.
Review OS scripts, or third-party monitoring software settings to determine whether a real-time alert will be sent to the appropriate personnel when auditing fails for any reason. If real-time alerts are not sent upon auditing failure, this is a finding.
Configure the system to provide an immediate real-time alert to appropriate support staff when a specified audit failure occurs by using OS scripts or a third-party tool for audit failure events alerting.
Review the MarkLogic security and audit configurations to verify that audit records are produced when other errors prevent attempts to change the configuration of the MarkLogic Server or database(s). Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field, a value of false means auditing is not enabled, this is a finding. 5. If the following audit events are not enabled, this is a finding: - Audit Configuration Change - Configuration Change - User Configuration Change 6. If the Audit Restrictions - Outcome is not Both, this is a finding. 7. If any Audit Restriction Inclusions/Exclusions are not documented in the System Security Plan, this is a finding.
Configure the MarkLogic to produce audit records when it denies attempts to change the configuration or when other errors prevent attempts to change the configuration of the MarkLogic Server or database(s). Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the following audit events: - Audit Configuration Change - Configuration Change - User Configuration Change 6. Set the Audit Restrictions - Outcome to Both. 7. If any Audit Restriction - Inclusions/Exclusions are approved in the SSP, ensure they have been applied.
Review the network functions, ports, protocols, and services supported by MarkLogic for any that are prohibited by the PPSM guidance. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the App Servers icon on the left tree menu. 4. Inspect the Summary screen for the Type/Port/ and SSL configuration. 5. If any of the App Servers uses a protocol or port prohibited by the PPSM guidance, this is a finding.
Disable each prohibited network function, port, protocol, or service in MarkLogic. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the App Servers icon on the left tree menu. 4. For any App Server that uses a prohibited port or protocol either disable the App Server or reconfigure to be compliant with the PPSM.
Review MarkLogic settings to determine whether the organization-defined limit for cached authentication is implemented. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Security icon. 2. Click the External Security icon. 3. Select each of the External Security providers. 4. For each of the providers inspect the cache timeout field, a value that does not match the organization-defined time limit is a finding.
Modify MarkLogic settings to implement the organization-defined limit on the lifetime of cached authenticators. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Security icon. 2. Click the External Security icon. 3. Select each of the External Security providers. 4. For each of the providers set the cache timeout field to the organization-defined time limit.
Review MarkLogic settings to determine whether the server will accept non-DoD approved PKI end-entity certificates, this is a finding. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Security icon. 2. Click the Certificate Authorities icon. 3. If there are any PKI end-entity certificates that are not DoD approved, this is a finding.
Configure MarkLogic to accept only DoD and DoD-approved PKI end-entity certificates by revoking trust in any certificates not issued by a DoD-approved certificate authority. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Security icon. 2. Click the Certificate Authorities icon. 3. Remove all PKI end-entity certificates not approved by DoD.
Review the system documentation to determine whether the organization has defined the information at rest that is to be protected from modification, which must include, at a minimum, PII and classified information. If no information is identified as requiring such protection, this is not a finding. Review system settings to determine if any of the information defined as requiring cryptographic protection from modification, is not encrypted in a manner that provides the required level of protection. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Databases icon. 2. Click the database that is to be checked. 3. If the "data encryption" drop-down is set to ON, this is not a finding, and no further checks need to be performed. 4. If the "data encryption" drop-down is set to OFF, continue the check. 5. If the "data encryption" drop-down is set to default-cluster, continue the check with the steps below: a. Click on the Clusters icon. b. Click [Cluster Name]. c. Click the Keystore Tab. d. If the Cluster Default Encryption configuration is OFF, this is a finding. Findings Matrix ------------------------------------------------------- Database Cfg. | Cluster Cfg | Finding -------------------------------------------------------- ON | *Any* | No *Any* | Force | No Default-cluster | Default-on | No Default-cluster | Default-off | Yes Off | Default-on | Yes Off | Default-off | Yes
Configure MarkLogic to provide the required level of cryptographic protection. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Databases icon. 2. Click the database that is to be fixed. 3. Select ON from the data encryption drop-down.
Review the system documentation to determine whether the organization has defined the information-at-rest that is to be protected from modification, which must include, at a minimum, PII and classified information. If no information is identified as requiring such protection, this is not a finding. Review system settings to determine if any of the information defined as requiring cryptographic protection from modification, is not encrypted in a manner that provides the required level of protection. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Databases icon. 2. Click the database to be checked. 3. If the data encryption drop-down is set to ON, this is not a finding, and no further checks need to be performed. 4. If the data encryption drop-down is set to OFF, continue the check. 5. If the data encryption drop-down is set to default-cluster, continue the check with the steps below: a. Click the Clusters icon. b. Click [Cluster Name]. c. Click the Configure Tab. d. If the Cluster Default Encryption configuration is OFF, this is a finding. Findings Matrix ------------------------------------------------------- Database Cfg. | Cluster Cfg | Finding -------------------------------------------------------- ON | *Any* | No *Any* | Force | No Default-cluster | Default-on | No Default-cluster | Default-off | Yes Off | Default-on | Yes Off | Default-off | Yes
Configure MarkLogic to provide the required level of cryptographic protection. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Databases icon. 2. Click the database is to be fixed. 3. Select ON from the data encryption drop-down.
Obtain evidence that package updates are consistently applied to MarkLogic within the time frame defined for each patch. The most recent releases of MarkLogic Server can be found at https://help.marklogic.com. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. Check the MarkLogic version identified in the upper left side of the Admin Interface and compare it to the versions found on the MarkLogic website. Obtain evidence that package updates are consistently applied to MarkLogic within the time frame defined for each patch. If such evidence cannot be obtained, or the evidence that is obtained indicates a pattern of noncompliance, this is a finding.
Institute and adhere to policies and procedures to ensure that package updates are consistently applied to MarkLogic within the time allowed. MarkLogic releases full software package updates that include all relevant security updates as well as enhancements and bug fixes. Larger updates are usually released quarterly, with smaller updates provided as needed between quarterly releases. Security updates are not packaged separately.
Review MarkLogic configuration to determine if audit records will be produced when security objects are accessed, to include reads, creations, modifications and deletions of data, and execution of logic. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Verify audit enabled field is set to true. If the setting is not true, this is a finding. 5. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding.
Configure MarkLogic to produce audit records when security objects are accessed, to include reads, creations, modifications and deletions of data, and execution of logic. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the security-access event for auditing. 6. Under the Audit Restrictions section, enable "both" under the Outcome selection.
Review MarkLogic configuration to determine if audit records will be produced when security objects are accessed, to include reads, creations, modifications and deletions of data, and execution of logic. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Verify audit enabled field is set to true. If the setting is not true, this is a finding. 5. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding.
Configure MarkLogic to produce audit records when security objects are accessed, to include reads, creations, modifications and deletions of data, and execution of logic. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the security-access event for auditing. 6. Under the Audit Restrictions section, enable "both" under the Outcome selection.
Review the DBMS/database security and audit configurations to verify that audit records are produced when categories of information are accessed, to include reads, creations, modifications, and deletions. If they are not produced, this is a finding. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field, a value of false means there is no auditing identifying the individual user, this is a finding. 5. If audit enabled field is true but the document-read event is not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not both, this is a finding. 7. If the role that has been configured for the category of information is not included under the audit restriction roles, this is a finding.
Configure MarkLogic to produce audit records when categories of information are accessed, to include reads, creations, modifications, and deletions. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the document-read event for auditing. 6. Enable "both" for the audit restriction under the outcome selection. 7. Add the role that encompasses the categories of information that need auditing. See MarkLogic Server - Using Security Guide 9.0-9, Ch 5, Section 2: Configuring Compartment Security, for information on defining the categories of information by using compartmented security.
Review MarkLogic security and audit configurations to verify that audit records are produced when the system denies attempts or when other errors prevent attempts to access categories of information, including reads, creations, modifications, and deletions. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field, a value of false means there is no auditing identifying the individual user, this is a finding. 5. If audit enabled field is true, but the document-read event is not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding. 7. If the role that has been configured for the category of information is not included under the audit restriction roles, this is a finding.
Configure the MarkLogic to produce audit records when the system denies attempts or when other errors prevent attempts to access categories of information, including reads, creations, modifications, and deletions. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the document-read event for auditing. 6. Enable "both" for the audit restriction under the outcome selection. 7. Add the role that encompasses the categories of information that need auditing. See MarkLogic Server - Using Security Guide 9.0-9, Ch 5, Section 2: Configuring Compartment Security, for information on defining the categories of information by using compartmented security.
Review MarkLogic security and audit configurations to verify that audit records are produced when privileges/permissions/role memberships are added. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means there is no auditing identifying the individual user and this is a finding. 5. If audit enabled field is true, but the user-role-addition event is not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding.
Configure MarkLogic to produce audit records when privileges/permissions/role memberships are added. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the user-role-addition event for auditing. 6. Enable "both" for the audit restriction under the outcome selection.
Review MarkLogic security and audit configurations to verify audit records are produced when the DBMS denies the addition of privileges/permissions/role membership or when other errors prevent the addition of privileges/permissions/role membership. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field, a value of false means auditing is not enabled, this is a finding. 5. If audit enabled field is true but the user-role-addition event is not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding.
Configure MarkLogic to produce audit records when it denies attempts to add privileges/permissions/role membership or when other errors prevent attempts to add privileges/permissions/role membership. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the user-role-addition event for auditing. 6. Enable "both" for the audit restriction under the outcome selection.
Check MarkLogic audit configurations to verify that audit records are produced when privileges/permissions/role memberships are modified. If they are not produced, this is a finding. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. 5. If audit enabled field is true but the permission-change, user-role-addition and user-role-removal events are not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding. 7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.
Configure MarkLogic to produce audit records when privileges/permissions/role memberships are modified. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the permission-change, user-role-addition, and user-role-removal events for auditing. 6. Enable "both" for the audit restriction under the outcome selection. 7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.
Check MarkLogic audit configurations to verify that audit records are produced when attempts to modify privileges/permissions/role memberships are denied. If they are not produced, this is a finding. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field, a value of false means auditing is not enabled, this is a finding. 5. If audit enabled field is true but the permission-change, user-role-addition, and user-role-removal events are not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding. 7. If any roles, URIs, or users are identified in audit restrictions, and not documented in the System Security Plan, this is a finding.
Configure MarkLogic to produce audit records when attempts to modify privileges/permissions/role memberships are denied. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the permission-change, user-role-addition, and user-role-removal events for auditing. 6. Enable "both" for the audit restriction under the outcome selection. 7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.
Check MarkLogic audit configurations to verify that audit records are produced when security objects are modified. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. 5. If audit enabled field is true, but the security-access event are not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding. 7. If any roles, URIs, or users are identified in audit restrictions, and not documented in the System Security Plan, this is a finding.
Configure MarkLogic to produce audit records when security objects are modified. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the security-access event for auditing. 6. Enable "both" for the audit restriction under the outcome selection. 7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.
Check MarkLogic audit configurations to verify that audit records are produced when the system denies attempts or other errors prevent attempts to modify security objects. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. 5. If audit enabled field is true but the security-access event are not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding. 7. If any roles, URIs, or users are identified in audit restrictions, and not documented in the System Security Plan, this is a finding.
Configure MarkLogic to produce audit records when it denies attempts to modify security objects, or other errors prevent attempts to modify security objects Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the security-access event for auditing. 6. Enable "both" for the audit restriction under the outcome selection. 7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.
Check MarkLogic audit configurations to verify that audit records are produced when categories of information are modified. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field, a value of false means auditing is not enabled, this is a finding. 5. If audit enabled field is true but the document-update event is not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not both, this is a finding. 7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.
Configure MarkLogic to produce audit records when categories of information are modified. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the document-update event for auditing. 6. Enable "both" for the audit restriction under the outcome selection. 7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan. See MarkLogic Server - Using Security Guide 9.0-9, Ch 5, Section 2: Configuring Compartment Security, for information on defining the categories of information by using compartmented security.
Check MarkLogic audit configurations to verify that audit records are produced when the system denies attempts, other errors prevent attempts to modify categories of information. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. 5. If audit enabled field is true but the document-update event is not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding. 7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.
Configure MarkLogic to produce audit records when the system denies attempts, other errors prevent attempts to modify categories of information. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. If audit enabled field is true but the document-update event is not selected, this is a finding. 6. Enable "both" for the audit restriction under the outcome selection. 7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.
Check MarkLogic audit configurations to verify that audit records are produced when privileges/permissions/role memberships are removed, revoked, or denied to any user or role. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. 5. If audit enabled field is true but the user-role-removal event is not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding. 7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.
Configure MarkLogic audit settings to generate an audit record when privileges/permissions/role memberships are removed, revoked, or denied to any user or role. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable user-role-removal event for auditing. 6. Enable "both" for the audit restriction under the outcome selection. 7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.
Check MarkLogic audit configurations to verify that audit records are produced when the system denies attempts to remove, revoke, or deny privileges/permissions/role membership, or when other errors prevent attempts to remove, revoke, or deny privileges/permissions/role membership to any user or role. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. 5. If audit enabled field is true, but the user-role-removal event is not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding. 7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.
Configure MarkLogic to produce audit records when the system denies attempts to remove, revoke, or deny privileges/permissions/role membership, or when other errors prevent attempts to remove, revoke, or deny privileges/permissions/role membership to any user or role. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable user-role-removal event for auditing. 6. Enable "both" for the audit restriction under the outcome selection. 7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.
Check MarkLogic audit configurations to verify that audit records are produced when security objects are dropped. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. 5. If audit enabled field is true, but the user-role-removal and security-access events are not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding. 7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.
Configure MarkLogic to produce audit records when security objects are deleted. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable user-role-removal and security-access events for auditing. 6. Enable "both" for the audit restriction under the outcome selection. 7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.
Check MarkLogic audit configurations to verify that audit records are produced when the system denies attempts, or when other errors prevent attempts to drop security objects. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. 5. If audit enabled field is true, but the user-role-removal and security-access events are not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding. 7. If any roles, URIs, or users are identified in audit restrictions, and not documented in the System Security Plan, this is a finding.
Configure MarkLogic to produce audit records when the system denies attempts, or when other errors prevent attempts to drop security objects. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable user-role-removal event for auditing. 6. Enable "both" for the audit restriction under the outcome selection. 7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.
Check MarkLogic audit configurations to verify that audit records are produced when categories of information are deleted. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. 5. If audit enabled field is true, but the document-update event is not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding. 7. If any roles, URIs, or users are identified in audit restrictions, and not documented in the System Security Plan, this is a finding.
Configure MarkLogic to produce audit records when categories of information are deleted. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the document-update event for auditing. 6. Enable "both" for the audit restriction under the outcome selection. 7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan. See MarkLogic Server - Using Security Guide 9.0-9, Ch 5, Section 2: Configuring Compartment Security, for information on defining the categories of information by using compartmented security.
Check MarkLogic audit configurations to verify that audit records are produced when the system denies attempts, or when other errors prevent attempts to delete categories of information. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. 5. If audit enabled field is true, but the document-update event is not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not both, this is a finding. 7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.
Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the document-update event for auditing. 6. Enable "both" for the audit restriction under the outcome selection. 7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan. See MarkLogic Server - Using Security Guide 9.0-9, Ch 5, Section 2: Configuring Compartment Security, for information on defining the categories of information by using compartmented security.
Check the MarkLogic audit settings to verify whether an audit record is generated each time a user (or other principal) logs on or connects to the DBMS, this is a finding. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. 5. If audit enabled field is true, but the authentication-failure event is not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding. 7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.
Configure MarkLogic audit settings to generate an audit record each time a user (or other principal) logs on or connects to the DBMS. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the authentication-failure event for auditing. 6. Enable "both" for the audit restriction under the outcome selection. 7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.
Check MarkLogic audit settings to verify an audit record is generated each time a user (or other principal) attempts but fails to log on or connect to the DBMS (including attempts where the user ID is invalid/unknown). Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means auditing is not enable and this is a finding. 5. If audit enabled field is true but the authentication-failure event is not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding. 7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.
Configure MarkLogic audit settings to generate an audit record each time a user (or other principal) attempts but fails to log on or connect to the DBMS (including attempts where the user ID is invalid/unknown). Include attempts where the user ID is invalid/unknown. Ensure that the audit record contains the time of the event and the user ID that was entered (if any). Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the authentication-failure event for auditing. 6. Enable "both" for the audit restriction under the outcome selection. 7. Ensure no roles, URIs or users are identified in the audit restrictions, unless documented in the System Security Plan.
Check MarkLogic audit configuration to verify audit records are generated when privileged actions occur. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. 5. If audit enabled field is true but the security-access event is not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding. 7. If any roles, URIs, or users are identified in audit restrictions, and not documented in the System Security Plan, this is a finding.
Configure MarkLogic to produce audit records when privileged actions occur. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the security-access event for auditing. 6. Enable "both" for the audit restriction under the outcome selection. 7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.
Review MarkLogic security and audit configurations to verify that audit records are produced when the DBMS prevents attempted privileged actions. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. 5. If audit enabled field is true, but the security-access event is not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding. 7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.
Configure MarkLogic to produce audit records when the DBMS prevents attempted privileged actions. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the security-access event for auditing. 6. Enable "both" for the audit restriction under the outcome selection. 7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.
Check MarkLogic audit configuration to verify whether audit records are generated each time a user (or other principal) who is already connected to the DBMS logs on or connects to the DBMS from a different workstation. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. 5. If audit enabled field is true, but the security-access event is not selected, this is a finding. 6. Under the Audit Restrictions - Outcome section, verify the security-access event for auditing is set to "both". If the setting is not "both", this is a finding. 7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.
Configure MarkLogic audit settings to generate an audit record each time a user (or other principal) who is already connected to the DBMS logs on or connects to the DBMS from a different workstation. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable the security-access and concurrent-request-denial events for auditing. 6. Enable "both" for the audit restriction under the outcome selection. 7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.
Review audit settings to verify objects identified by the application owner, for which access must be audited, are being audited. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to be checked resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. 5. If any audit events identified in the System Security Plan are not enabled, this is a finding. 6. If the Audit Restrictions - Outcome is not Both, this is a finding. 7. If any Audit Restriction Inclusions/Exclusions are not documented in the System Security Plan, this is a finding.
Configure audit settings to create audit records when the specified access to the specified objects occurs. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Enable any audit events identified as required in the System Security Plan (SSP). 6. Set the Audit Restrictions - Outcome to Both. 7. If any Audit Restriction - Inclusions/Exclusions are approved in the SSP, ensure they have been applied.
Check MarkLogic configuration to verify use of NIST FIPS validated cryptographic modules to provision digital signatures. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Clusters icon. 2. Click the local cluster. 3. If SSL FIPS enabled button is false, this is a finding.
Configure MarkLogic to use NIST FIPS validated cryptographic modules to provision digital signatures. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Clusters icon. 2. Click the local cluster. 3. Enable SSL FIPS option.
Check MarkLogic configuration to verify use of a NIST FIPS validated cryptographic modules to generate and verify cryptographic hashes. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level-privileges. 1. Click the Clusters icon. 2. Click the local cluster. 3. If SSL FIPS enabled button is false, this is a finding.
Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. Configure MarkLogic to use a NIST FIPS validated cryptographic module for generation and verification of cryptographic hashes. 1. Click the Clusters icon. 2. Click the local cluster. 3. Enable SSL FIPS option.
If the database contains, or is intended to contain, unclassified information requiring confidentiality and cryptographic protection, check MarkLogic configuration to verify use of NIST FIPS validated cryptographic modules to provide this protection. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Clusters icon. 2. Click the local cluster. 3. If SSL FIPS enabled button is false, this is a finding.
Configure MarkLogic to use NIST FIPS validated cryptographic modules to provide cryptographic protection for the unclassified information that requires it. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Clusters icon. 2. Click the local cluster. 3. Enable SSL FIPS option.
Review the system documentation to determine how audit records are offloaded. If the MarkLogic Server instance is not monitored by a third-party audit management tool, this is a finding.
Configure the system to offload MarkLogic audit records. Add the MarkLogic Server instance under the monitoring of a third-party audit management tool.
Determine the applicable DoD security configuration and implementation guidance for the deployment environment. Asses the MarkLogic Server documentation and configuration in accordance with the applicable guidance. If MarkLogic is not configured in accordance with security configuration settings, this is a finding.
From the list of applicable DoD security configuration and implementation guidance, address the items that the MarkLogic Server configuration does not meet.
Review the system documentation and interview the database administrator. Identify all database software components. Review the current version and release information; execute the following from the query console: xdmp:version(); --OR-- Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. Version is displayed in the upper left corner of the console. Access the MarkLogic website to validate that the version is currently supported: https://developer.marklogic.com/products/support-matrix/ If the DBMS or any of the software components are not supported by the vendor, this is a finding.
Remove or decommission all unsupported software products. Upgrade unsupported DBMS or unsupported components to a supported version of the product.