MarkLogic Server v9 Security Technical Implementation Guide

  • Version/Release: V3R2
  • Published: 2024-09-04
  • Released: 2024-10-24
  • Expand All:
  • Severity:
  • Sort:
Compare

Select any two versions of this STIG to compare the individual requirements

View

Select any old version/release of this STIG to view the previous requirements

This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DOD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.
a
MarkLogic Server must limit the number of concurrent sessions to an organization-defined number per user for all accounts and/or account types.
AC-10 - Low - CCI-000054 - V-220339 - SV-220339r960735_rule
RMF Control
AC-10
Severity
Low
CCI
CCI-000054
Version
ML09-00-000100
Vuln IDs
  • V-220339
  • V-100921
Rule IDs
  • SV-220339r960735_rule
  • SV-110025
Database management includes the ability to control the number of users and user sessions utilizing a DBMS. Unlimited concurrent connections to the DBMS could allow a successful Denial of Service (DoS) attack by exhausting connection resources and a system can also fail or be degraded by an overload of legitimate users. Limiting the number of concurrent sessions per user is helpful in reducing these risks. This requirement addresses concurrent session control for a single account. It does not address concurrent sessions by a single user via multiple system accounts and it does not deal with the total number of sessions across all accounts. The capability to limit the number of concurrent sessions per user must be configured in or added to the DBMS (for example, by use of a logon trigger), when this is technically feasible. Note that it is not sufficient to limit sessions via a web server or application server alone, because legitimate users and adversaries can potentially connect to the DBMS by other means. The organization will need to define the maximum number of concurrent sessions by account type, by account, or a combination thereof. In deciding on the appropriate number, it is important to consider the work requirements of the various types of users. For example, 2 might be an acceptable limit for general users accessing the database via an application; but 10 might be too few for a database administrator using a database management GUI tool, where each query tab and navigation pane may count as a separate session. (Sessions may also be referred to as connections or logons, which for the purposes of this requirement are synonyms.) Limiting Concurrent Requests with User Session Limits There is an option on each App Server (HTTP, ODBC, XDBC, and WebDAV Server) configuration to limit the number of concurrent requests a user can have against that App Server. A concurrent request is defined to be a request against that App Server from the same user while another request from the same user is still active. Each App Server has a concurrent request limit configuration parameter. The default is 0, which means there is no limit to the number of concurrent requests. The value must be an integer greater than or equal to 0. Setting the concurrent request limit configuration parameter to a value other than 0 limits the number of concurrent requests any user can run against that App Server to the specified number. For example, by setting the number to 3, any requests made by a user named Raymond while 3 requests from Raymond are running will fail with an exception. When the limit is reached, the application will throw a 403 (forbidden) error with the XDMP-REQUESTLIMIT exception.
Checks: C-22054r531246_chk

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.

Fix: F-22043r401469_fix

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.

b
MarkLogic Server must integrate with an organization-level authentication/access mechanism providing account management and automation for all users, groups, roles, and any other principals.
AC-2 - Medium - CCI-000015 - V-220340 - SV-220340r960768_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-000015
Version
ML09-00-000200
Vuln IDs
  • V-220340
  • V-100923
Rule IDs
  • SV-220340r960768_rule
  • SV-110027
Enterprise environments make account management for applications and databases challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other error. Managing accounts for the same person in multiple places is inefficient and prone to problems with consistency and synchronization. A comprehensive application account management process that includes automation helps to ensure accounts designated as requiring attention are consistently and promptly addressed. Examples include, but are not limited to, using automation to take action on multiple accounts designated as inactive, suspended, or terminated, or by disabling accounts located in non-centralized account stores, such as multiple servers. Account management functions can also include: assignment of group or role membership; identifying account type; specifying user access authorizations (i.e., privileges); account removal, update, or termination; and administrative alerts. The use of automated mechanisms can include, for example: using email or text messaging to notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using automated telephone notification to report atypical system account usage. The DBMS must be configured to automatically utilize organization-level account management functions and these functions must immediately enforce the organization's current account policy. Automation may be comprised of differing technologies that when placed together contain an overall mechanism supporting an organization's automated account management requirements. MarkLogic Server can be configured so that users are authenticated using an external authentication protocol, such as Lightweight Directory Access Protocol (LDAP), Kerberos, or certificate. These external agents serve as centralized points of authentication or repositories for user information from which authorization decisions can be made. MarkLogic Server can be configured with multiple external security providers. A user only needs to authenticate with one of them to gain access.
Checks: C-22055r401471_chk

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.

Fix: F-22044r401472_fix

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.

c
MarkLogic Server must enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.
AC-3 - High - CCI-000213 - V-220341 - SV-220341r960792_rule
RMF Control
AC-3
Severity
High
CCI
CCI-000213
Version
ML09-00-000300
Vuln IDs
  • V-220341
  • V-100925
Rule IDs
  • SV-220341r960792_rule
  • SV-110029
Authentication with a DoD-approved PKI certificate does not necessarily imply authorization to access the DBMS. To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD systems, including databases, must be properly configured to implement access control policies. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system. This requirement is applicable to access control enforcement applications, a category that includes database management systems. If the DBMS does not follow applicable policy when approving access, it may be in conflict with networks or other applications in the information system. This may result in users either gaining or being denied access inappropriately and in conflict with applicable policy. MarkLogic Server uses a role-based security model. A user’s privileges and permissions are based on the roles assigned to the user. For background information on understanding the security model in MarkLogic Server, see Security Guide.
Checks: C-22056r401474_chk

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.

Fix: F-22045r401475_fix

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.

b
MarkLogic Server must protect against a user falsely repudiating having performed organization-defined actions.
AU-10 - Medium - CCI-000166 - V-220342 - SV-220342r960864_rule
RMF Control
AU-10
Severity
Medium
CCI
CCI-000166
Version
ML09-00-000400
Vuln IDs
  • V-220342
  • V-100927
Rule IDs
  • SV-220342r960864_rule
  • SV-110031
Non-repudiation of actions taken is required in order to maintain data integrity. Examples of particular actions taken by individuals include creating information, sending a message, approving information (e.g., indicating concurrence or signing a contract), and receiving a message. Non-repudiation protects against later claims by a user of not having created, modified, or deleted a particular data item or collection of data in the database. In designing a database, the organization must define the types of data and the user actions that must be protected from repudiation. The implementation must then include building audit features into the application data tables and configuring the DBMS's audit tools to capture the necessary audit trail. Design and implementation also must ensure that applications pass individual user identification to the DBMS, even where the application connects to the DBMS with a standard, shared account. MarkLogic Server includes an auditing capability. Auditing can be enabled to capture security-relevant events to monitor suspicious database activity or to satisfy applicable auditing requirements. Configure the generation of audit events by including or excluding MarkLogic Server roles, users, or documents based on URI. More information on auditing can be found here: https://docs.marklogic.com/guide/security/auditing
Checks: C-22057r531248_chk

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.

Fix: F-22046r401478_fix

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.

b
MarkLogic Server must be configured to provide audit record generation capability for DoD-defined auditable events within all DBMS/database components.
AU-12 - Medium - CCI-000169 - V-220343 - SV-220343r960879_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
ML09-00-000500
Vuln IDs
  • V-220343
  • V-100929
Rule IDs
  • SV-220343r960879_rule
  • SV-110033
Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the DBMS (e.g., process, module). Certain specific application functionalities may be audited as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. DoD has defined the list of events for which the DBMS will provide an audit record generation capability as the following: (i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); (ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities, or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and (iii) All account creation, modification, disabling, and termination actions. Organizations may define additional events requiring continuous or ad hoc auditing. MarkLogic Server includes an auditing capability. Auditing can be enabled to capture security-relevant events to monitor suspicious database activity or to satisfy applicable auditing requirements. The generation of audit events can be configured by including or excluding MarkLogic Server roles, users, or documents based on URI. Some actions that can be audited are the following: - Startup and shutdown of MarkLogic Server - Adding or removing roles from a user - Usage of amps - Starting and stopping the auditing system For the complete list of auditable events and their descriptions, see Auditing Events in the Administrator's Guide: https://docs.marklogic.com/guide/admin/auditing
Checks: C-22058r401480_chk

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.

Fix: F-22047r401481_fix

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.

b
MarkLogic Server must allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.
AU-12 - Medium - CCI-000171 - V-220344 - SV-220344r960882_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000171
Version
ML09-00-000600
Vuln IDs
  • V-220344
  • V-100931
Rule IDs
  • SV-220344r960882_rule
  • SV-110035
Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent or interfere with the auditing of critical events. Suppression of auditing could permit an adversary to evade detection. Misconfigured audits can degrade the system's performance by overwhelming the audit log, and can make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. MarkLogic Server includes an auditing capability. Auditing can be enabled to capture security-relevant events to monitor suspicious database activity or to satisfy applicable auditing requirements. The generation of audit events can be configured by including or excluding MarkLogic Server roles, users, or documents based on URI. Some actions that can be audited are the following: - Startup and shutdown of MarkLogic Server - Adding or removing roles from a user - Usage of amps - Starting and stopping the auditing system For the complete list of auditable events and their descriptions, see Auditing Events in the Administrator's Guide: https://docs.marklogic.com/guide/admin/auditing
Checks: C-22059r531250_chk

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.

Fix: F-22048r401484_fix

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.

b
MarkLogic Server must be able to generate audit records when privileges/permissions are retrieved.
AU-12 - Medium - CCI-000172 - V-220345 - SV-220345r960885_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-000700
Vuln IDs
  • V-220345
  • V-100933
Rule IDs
  • SV-220345r960885_rule
  • SV-110037
Under some circumstances, it may be useful to monitor who/what is reading privilege/permission/role information. Therefore, it must be possible to configure auditing to do this. DBMSs typically make such information available through views or functions. This requirement addresses explicit requests for privilege/permission/role membership information. It does not refer to the implicit retrieval of privileges/permissions/role memberships that the DBMS continually performs to determine if any and every action on the database is permitted.
Checks: C-22060r401486_chk

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.

Fix: F-22049r401487_fix

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.

b
MarkLogic Server must be able to generate audit records when unsuccessful attempts to retrieve privileges/permissions occur.
AU-12 - Medium - CCI-000172 - V-220346 - SV-220346r960885_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-000750
Vuln IDs
  • V-220346
  • V-100935
Rule IDs
  • SV-220346r960885_rule
  • SV-110039
Under some circumstances, it may be useful to monitor who/what is reading privilege/permission/role information. Therefore, it must be possible to configure auditing to do this. DBMSs typically make such information available through views or functions. This requirement addresses explicit requests for privilege/permission/role membership information. It does not refer to the implicit retrieval of privileges/permissions/role memberships that the DBMS continually performs to determine if any and every action on the database is permitted. To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones. MarkLogic Server includes an auditing capability. Auditing can be enabled to capture security-relevant events to monitor suspicious database activity or to satisfy applicable auditing requirements. The generation of audit events can be configured by including or excluding MarkLogic Server roles, users, or documents based on URI. Some actions that can be audited are the following: - Startup and shutdown of MarkLogic Server - Adding or removing roles from a user - Usage of amps - Starting and stopping the auditing system For the complete list of auditable events and their descriptions, see Auditing Events in the Administrator's Guide: https://docs.marklogic.com/guide/admin/auditing
Checks: C-22061r401489_chk

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.

Fix: F-22050r401490_fix

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.

b
MarkLogic Server must initiate session auditing upon startup.
AU-14 - Medium - CCI-001464 - V-220347 - SV-220347r960888_rule
RMF Control
AU-14
Severity
Medium
CCI
CCI-001464
Version
ML09-00-000800
Vuln IDs
  • V-220347
  • V-100937
Rule IDs
  • SV-220347r960888_rule
  • SV-110041
Session auditing is used when a user's activities are under investigation. To ensure all activity is captured during the periods when session auditing is in use, it must be in operation for the entire time the DBMS is running.
Checks: C-22062r401492_chk

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.

Fix: F-22051r401493_fix

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.

b
MarkLogic Server must shut down by default upon audit failure, to include the unavailability of space for more audit log records; or must be configurable to shut down upon audit failure.
AU-5 - Medium - CCI-000140 - V-220348 - SV-220348r960915_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-000140
Version
ML09-00-001600
Vuln IDs
  • V-220348
  • V-100939
Rule IDs
  • SV-220348r960915_rule
  • SV-110043
It is critical that when the DBMS is at risk of failing to process audit logs as required, it take action to mitigate the failure. Audit processing failures include: software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode. When the need for system availability does not outweigh the need for a complete audit trail, the DBMS should shut down immediately, rolling back all in-flight transactions. Systems in which audit trail completeness is paramount will most likely be at a lower MAC level than MAC I; the final determination is the prerogative of the application owner, subject to Authorizing Official concurrence. Sufficient auditing resources must be allocated to avoid a shutdown in all but the most extreme situations.
Checks: C-22063r401495_chk

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

Fix: F-22052r401496_fix

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.

b
The audit information produced by MarkLogic Server must be protected from unauthorized read access.
AU-9 - Medium - CCI-000162 - V-220349 - SV-220349r960930_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000162
Version
ML09-00-001900
Vuln IDs
  • V-220349
  • V-100941
Rule IDs
  • SV-220349r960930_rule
  • SV-110045
If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult, if not impossible, to achieve. In addition, access to audit records provides information an attacker could potentially use to their advantage. To ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, copy, etc. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Some commonly employed methods include: ensuring log files enjoy the proper file system permissions, utilizing file system protections, and limiting log data location. Additionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring audit information is protected from unauthorized access. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. When auditing is enabled, MarkLogic Server writes audit events to the AuditLog.txt file. Each host in a cluster maintains its own audit log files. Some actions might trigger multiple audit events, and those events might be logged over multiple hosts, as events are audited on the host in which the event occurs. For more information about the audit events, see Auditable Events. Note the following about the audit event log files: - Writes messages to AuditLog.txt file for various events. - Each event has a timestamp, event type, user, role, and other information relevant to the event (for example, document URI for document-read event). For an example of log entries, see Sample Audit Logs. - How often to rotate the audit files (similar to the log files, as described in Log Files) can be configured. - The Audit log files are stored in the same directory as the Access log files (port_AccessLog.txt) and the Error log files (ErrorLog.txt), which is in the /Logs directory. These files are private to the host in which the audit event occurred. - View the current or any archived file log at any time using standard text file viewing tools. Additionally, the log files can be accessed from the Log tab on the main page of the Admin Interface.
Checks: C-22064r531370_chk

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.

Fix: F-22053r531371_fix

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

b
The audit information produced by MarkLogic Server must be protected from unauthorized modification.
AU-9 - Medium - CCI-000163 - V-220350 - SV-220350r960933_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000163
Version
ML09-00-002000
Vuln IDs
  • V-220350
  • V-100943
Rule IDs
  • SV-220350r960933_rule
  • SV-110047
If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized modification. This requirement can be achieved through multiple methods that will depend upon system architecture and design. Some commonly employed methods include ensuring log files enjoy the proper file system permissions and limiting log data locations. Applications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights that the user enjoys in order to make access decisions regarding the modification of audit data. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Modification of database audit data could mask the theft of, or the unauthorized modification of, sensitive data stored in the database. When auditing is enabled, MarkLogic Server writes audit events to the AuditLog.txt file. Each host in a cluster maintains its own audit log files. Some actions might trigger multiple audit events, and those events might be logged over multiple hosts, as events are audited on the host in which the event occurs. For more information about the audit events, see Auditable Events. Note the following about the audit event log files: - Writes messages to AuditLog.txt file for various events. - Each event has a timestamp, event type, user, role, and other information relevant to the event (e.g., document URI for document-read event). For an example of log entries, see Sample Audit Logs. - How often to rotate the audit files (similar to the log files, as described in Log Files) can be configured. - The Audit log files are stored in the same directory as the Access log files (port_AccessLog.txt) and the Error log files (ErrorLog.txt), which is in the /Logs directory. These files are private to the host in which the audit event occurred. - View the current or any archived file log at any time using standard text file viewing tools. Additionally, the log files can be accessed from the Log tab on the main page of the Admin Interface.
Checks: C-22065r401501_chk

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.

Fix: F-22054r401502_fix

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

b
The audit information produced by MarkLogic Server must be protected from unauthorized deletion.
AU-9 - Medium - CCI-000164 - V-220351 - SV-220351r960936_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000164
Version
ML09-00-002100
Vuln IDs
  • V-220351
  • V-100945
Rule IDs
  • SV-220351r960936_rule
  • SV-110049
If audit data becomes compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods depending on system architecture and design. Some commonly employed methods include: ensuring log files employ the proper file system permissions, utilizing file system protections, restricting access; and backing up log data to ensure log data is retained. Applications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights the user enjoys to make access decisions regarding the deletion of audit data. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. When auditing is enabled, MarkLogic Server writes audit events to the AuditLog.txt file. Each host in a cluster maintains its own audit log files. Some actions might trigger multiple audit events, and those events might be logged over multiple hosts, as events are audited on the host in which the event occurs. For more information about the audit events, see Auditable Events. Note the following about the audit event log files: - Writes messages to AuditLog.txt file for various events. - Each event has a timestamp, event type, user, role, and other information relevant to the event (for example, document URI for document-read event). For an example of log entries, see Sample Audit Logs. - How often to rotate the audit files (similar to the log files, as described in Log Files) can be configured. - The Audit log files are stored in the same directory as the Access log files (port_AccessLog.txt) and the Error log files (ErrorLog.txt), which is in the /Logs directory. These files are private to the host in which the audit event occurred. - View the current or any archived file log at any time using standard text file viewing tools. Additionally, the log files can be accessed from the Log tab on the main page of the Admin Interface. Deletion of database audit data could mask the theft of, or the unauthorized modification of, sensitive data stored in the database.
Checks: C-22066r401504_chk

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.

Fix: F-22055r401505_fix

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

b
MarkLogic Server must protect its audit features from unauthorized access.
AU-9 - Medium - CCI-001493 - V-220352 - SV-220352r960939_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001493
Version
ML09-00-002200
Vuln IDs
  • V-220352
  • V-100947
Rule IDs
  • SV-220352r960939_rule
  • SV-110051
Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Depending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. Access to audit tools must be controlled and protected from unauthorized access. Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, OS-provided audit tools, vendor-provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records. If an attacker were to gain access to audit tools, he could analyze audit logs for system weaknesses or weaknesses in the auditing itself. An attacker could also manipulate logs to hide evidence of malicious activity. When auditing is enabled, MarkLogic Server writes audit events to the AuditLog.txt file. Each host in a cluster maintains its own audit log files. Some actions might trigger multiple audit events, and those events might be logged over multiple hosts, as events are audited on the host in which the event occurs. For more information about the audit events, see Auditable Events. Note the following about the audit event log files: - Writes messages to AuditLog.txt file for various events. - Each event has a timestamp, event type, user, role, and other information relevant to the event (for example, document URI for document-read event). For an example of log entries, see Sample Audit Logs. - How often to rotate the audit files (similar to the log files, as described in Log Files) can be configured. - Audit log files are stored in the same directory as the Access log files (port_AccessLog.txt) and the Error log files (ErrorLog.txt), which is in the /Logs directory. These files are private to the host in which the audit event occurred. - View the current or any archived file log at any time using standard text file viewing tools. Additionally, the log files can be accessed from the Log tab on the main page of the Admin Interface.
Checks: C-22067r401507_chk

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.

Fix: F-22056r401508_fix

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

b
MarkLogic Server must protect its audit configuration from unauthorized modification.
AU-9 - Medium - CCI-001494 - V-220353 - SV-220353r960942_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001494
Version
ML09-00-002300
Vuln IDs
  • V-220353
  • V-100949
Rule IDs
  • SV-220353r960942_rule
  • SV-110053
Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data. Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys to make access decisions regarding the modification of audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.
Checks: C-22068r401510_chk

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.

Fix: F-22057r401511_fix

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

b
MarkLogic Server must protect its audit features from unauthorized removal.
AU-9 - Medium - CCI-001495 - V-220354 - SV-220354r960945_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001495
Version
ML09-00-002400
Vuln IDs
  • V-220354
  • V-100951
Rule IDs
  • SV-220354r960945_rule
  • SV-110055
Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data. Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys to make access decisions regarding the deletion of audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.
Checks: C-22069r401513_chk

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.

Fix: F-22058r401514_fix

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

b
MarkLogic Server must limit privileges to change software modules, including stored procedures, functions, and triggers, and links to software external to the DBMS.
CM-5 - Medium - CCI-001499 - V-220355 - SV-220355r960960_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001499
Version
ML09-00-002500
Vuln IDs
  • V-220355
  • V-100953
Rule IDs
  • SV-220355r960960_rule
  • SV-110057
If the system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. Accordingly, only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. Unmanaged changes that occur to the database software libraries or configuration can lead to unauthorized or compromised installations.
Checks: C-22070r401516_chk

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

Fix: F-22059r401517_fix

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.

b
MarkLogic Server software installation account must be restricted to authorized users.
CM-5 - Medium - CCI-001499 - V-220356 - SV-220356r960960_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001499
Version
ML09-00-002600
Vuln IDs
  • V-220356
  • V-100955
Rule IDs
  • SV-220356r960960_rule
  • SV-110059
When dealing with change control issues, it should be noted any changes to the hardware, software, and/or firmware components of the information system and/or application could have significant effects on the overall security of the system. If the system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. Accordingly, only qualified and authorized individuals must be allowed access to information system components for purposes of initiating changes, including upgrades and modifications. DBA and other privileged administrative or application owner accounts are granted privileges that allow actions that can have a great impact on database security and operation. It is especially important to grant privileged access to only those persons who are qualified and authorized to use them.
Checks: C-22071r401519_chk

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.

Fix: F-22060r401520_fix

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.

b
MarkLogic Server software, including configuration files, must be stored in dedicated directories, or DASD pools, separate from the host OS and other applications.
CM-5 - Medium - CCI-001499 - V-220357 - SV-220357r960960_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001499
Version
ML09-00-002700
Vuln IDs
  • V-220357
  • V-100957
Rule IDs
  • SV-220357r960960_rule
  • SV-110061
When dealing with change control issues, it should be noted any changes to the hardware, software, and/or firmware components of the information system and/or application could potentially have significant effects on the overall security of the system. Multiple applications can provide a cumulative negative effect. A vulnerability and subsequent exploit to one application can lead to an exploit of other applications sharing the same security context. For example, an exploit to a web server process that leads to unauthorized administrative access to host system directories can most likely lead to a compromise of all applications hosted by the same system. Database software not installed using dedicated directories both threatens, and is threatened by, other hosted applications. Access controls defined for one application may by default provide access to the other application's database objects or directories. Any method that provides any level of separation of security context assists in the protection between applications.
Checks: C-22072r401522_chk

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.

Fix: F-22061r401523_fix

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]

b
MarkLogic Server objects (including but not limited to indexes, storage, functions, triggers, links to software external to the server, etc.) must be owned by database/MarkLogic Server principals authorized for ownership.
CM-5 - Medium - CCI-001499 - V-220358 - SV-220358r960960_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001499
Version
ML09-00-002800
Vuln IDs
  • V-220358
  • V-100959
Rule IDs
  • SV-220358r960960_rule
  • SV-110063
Within the database, object ownership implies full privileges to the owned object, including the privilege to assign access to the owned objects to other subjects. Database functions and procedures can be coded using definer's rights. This allows anyone who utilizes the object to perform the actions if they were the owner. If not properly managed, this can lead to privileged actions being taken by unauthorized individuals. Conversely, if critical tables or other objects rely on unauthorized owner accounts, these objects may be lost when an account is removed.
Checks: C-22073r401525_chk

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.

Fix: F-22062r401526_fix

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.

b
The role(s)/group(s) used to modify database structure (including but not necessarily limited to indexes, storage, etc.) and logic modules (functions, triggers, links to software external to the MarkLogic Server, etc.) must be restricted to authorized users.
CM-5 - Medium - CCI-001499 - V-220359 - SV-220359r960960_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001499
Version
ML09-00-002900
Vuln IDs
  • V-220359
  • V-100961
Rule IDs
  • SV-220359r960960_rule
  • SV-110065
If the DBMS were to allow any user to make changes to database structure or logic, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. Accordingly, only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. Unmanaged changes that occur to the database software libraries or configuration can lead to unauthorized or compromised installations.
Checks: C-22074r401528_chk

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.

Fix: F-22063r401529_fix

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.

b
Unused database components, DBMS software, and database objects must be removed.
CM-7 - Medium - CCI-000381 - V-220360 - SV-220360r960963_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
ML09-00-003100
Vuln IDs
  • V-220360
  • V-100963
Rule IDs
  • SV-220360r960963_rule
  • SV-110067
Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). It is detrimental for software products to provide, or install by default, functionality exceeding requirements or mission objectives. DBMSs must adhere to the principles of least functionality by providing only essential capabilities.
Checks: C-22075r401531_chk

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.

Fix: F-22064r401532_fix

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.

b
Access to external executables must be disabled or restricted.
CM-7 - Medium - CCI-000381 - V-220361 - SV-220361r960963_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
ML09-00-003300
Vuln IDs
  • V-220361
  • V-100965
Rule IDs
  • SV-220361r960963_rule
  • SV-110069
Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). It is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. Applications must adhere to the principles of least functionality by providing only essential capabilities. DBMSs may spawn additional external processes to execute procedures that are defined in the DBMS but stored in external host files (external procedures). The spawned process used to execute the external procedure may operate within a different OS security context than the DBMS and provide unauthorized access to the host system.
Checks: C-22076r401534_chk

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.

Fix: F-22065r401535_fix

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

b
MarkLogic Server must be configured to prohibit or restrict the use of organization-defined functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments.
CM-7 - Medium - CCI-000382 - V-220362 - SV-220362r960966_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
ML09-00-003400
Vuln IDs
  • V-220362
  • V-100967
Rule IDs
  • SV-220362r960966_rule
  • SV-110071
In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols/services on information systems. Applications are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., email and web services); however, doing so increases risk over limiting the services provided by any one component. To support the requirements and principles of least functionality, the application must support the organizational requirements providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues. Database Management Systems using ports, protocols, and services deemed unsafe are open to attack through those ports, protocols, and services. This can allow unauthorized access to the database and through the database to other components of the information system.
Checks: C-22077r401537_chk

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.

Fix: F-22066r401538_fix

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

b
MarkLogic Server must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).
IA-2 - Medium - CCI-000764 - V-220363 - SV-220363r960969_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-000764
Version
ML09-00-003500
Vuln IDs
  • V-220363
  • V-100969
Rule IDs
  • SV-220363r960969_rule
  • SV-110073
To ensure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of the system. Organizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors). Organizational users (and any processes acting on behalf of users) must be uniquely identified and authenticated for all accesses, except the following: (i) Accesses explicitly identified and documented by the organization. Organizations document specific user actions that can be performed on the information system without identification or authentication; and (ii) Accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals using shared accounts, for detailed accountability of individual activity.
Checks: C-22078r401540_chk

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.

Fix: F-22067r401541_fix

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

b
If MarkLogic Server authentication using passwords is employed, MarkLogic Server must enforce the DOD standards for password complexity and lifetime.
- Medium - CCI-004066 - V-220364 - SV-220364r1018604_rule
RMF Control
Severity
Medium
CCI
CCI-004066
Version
ML09-00-003600
Vuln IDs
  • V-220364
  • V-100971
Rule IDs
  • SV-220364r1018604_rule
  • SV-110075
OS/enterprise authentication and identification must be used (SRG-APP-000023-DB-000001). Native DBMS authentication may be used only when circumstances make it unavoidable, and must be documented and Authorizing Official (AO)-approved. The DOD standard for authentication is DOD-approved PKI certificates. Authentication based on User ID and Password may be used only when it is not possible to employ a PKI certificate, and requires AO approval. In such cases, the DOD standards for password complexity and lifetime must be implemented. DBMS products that can inherit the rules for these from the operating system or access control program (e.g., Microsoft Active Directory) must be configured to do so. For other DBMSs, the rules must be enforced using available configuration parameters or custom code. Types of Authentication Control the authentication scheme for HTTP, WebDAV, ODBC, and XDBC App Servers. - Basic authentication is the typical authentication scheme for web applications. A user is prompted for a username and password when accessing an application page. In basic mode, the password is obfuscated but not encrypted. - Digest authentication works the same way as basic, but offers encryption of passwords sent over the network. A user is prompted for a username and password when accessing an application page. - The digest-basic authentication scheme uses the more secure digest scheme whenever possible, but reverts to basic authentication when needed. Some older browsers, for example, do not support digest authentication. The digest-basic scheme is also useful if basic authentication was previously used, but must be migrated to digest. The first time a user accesses the server after changing from basic to digest-basic authentication scheme, the server computes the digest password by extracting the relevant information from the credentials supplied in basic mode. - Certificate-based authentication requires internal and external users and HTTPS clients to authenticate to MarkLogic Server via a client certificate, either in addition to, or rather than a password. - Application-level authentication bypasses all authentication and automatically logs all users in as a specified default user. Specify the default user in the Admin Interface, and any users accessing the server automatically inherit the security attributes (roles, privileges, default permissions) of the default user. Application-level authentication is available on HTTP, ODBC, and WebDAV servers. - In Kerberos Ticket, the user is authenticated by Kerberos and a Kerberos session ticket is used to authenticate the user to access MarkLogic Server. - When SAML authentication is used, a client requests a resource from MarkLogic Server with no security context. MarkLogic redirects the authentication request to an Identity Provider, the Identity Provider prompts the user to login, if necessary, and sends the authentication request back to MarkLogic Server (the Service Provider) for validation.
Checks: C-22079r998231_chk

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.

Fix: F-22068r998232_fix

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

c
If passwords are used for authentication, the MarkLogic Server must transmit only encrypted representations of passwords.
IA-5 - High - CCI-000197 - V-220365 - SV-220365r961029_rule
RMF Control
IA-5
Severity
High
CCI
CCI-000197
Version
ML09-00-003800
Vuln IDs
  • V-220365
  • V-100975
Rule IDs
  • SV-220365r961029_rule
  • SV-110079
The DoD standard for authentication is DoD-approved PKI certificates. Authentication based on User ID and Password may be used only when it is not possible to employ a PKI certificate, and requires AO approval. In such cases, passwords must be protected at all times, and encryption is the standard method for protecting passwords during transmission. DBMS passwords sent in clear text format across the network are vulnerable to discovery by unauthorized users. Disclosure of passwords may easily lead to unauthorized access to the database. MarkLogic Types of Authentication: Basic* Digest Digest-Basic* Certificate Application Level Kerberos Ticket SAML * Indicates that the authentication method allows the username and password to be transmitted in clear text. For more information on the types of authentication MarkLogic offers, follow this link: https://docs.marklogic.com/9.0/guide/security/authentication#id_14250
Checks: C-22080r401546_chk

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

Fix: F-22069r401547_fix

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.

b
MarkLogic Server, when utilizing PKI-based authentication, must validate certificates by performing RFC 5280-compliant certification path validation.
IA-5 - Medium - CCI-000185 - V-220366 - SV-220366r961038_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000185
Version
ML09-00-003900
Vuln IDs
  • V-220366
  • V-100977
Rule IDs
  • SV-220366r961038_rule
  • SV-110081
The DoD standard for authentication is DoD-approved PKI certificates. A certificate’s certification path is the path from the end entity certificate to a trusted root certification authority (CA). Certification path validation is necessary for a relying party to make an informed decision regarding acceptance of an end entity certificate. Certification path validation includes checks such as certificate issuer trust, time validity, and revocation status for each certificate in the certification path. Revocation status information resource/or CA and subject certificates in a certification path is commonly provided via certificate revocation lists (CRLs) or online certificate status protocol (OCSP) responses. Database Management Systems that do not validate certificates by performing RFC 5280-compliant certification path validation are in danger of accepting certificates that are invalid and/or counterfeit. This could allow unauthorized access to the database.
Checks: C-22081r401549_chk

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.

Fix: F-22070r401550_fix

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() )

c
MarkLogic Server must enforce authorized access to all PKI private keys stored/utilized by the DBMS.
IA-5 - High - CCI-000186 - V-220367 - SV-220367r961041_rule
RMF Control
IA-5
Severity
High
CCI
CCI-000186
Version
ML09-00-004000
Vuln IDs
  • V-220367
  • V-100979
Rule IDs
  • SV-220367r961041_rule
  • SV-110083
The DoD standard for authentication is DoD-approved PKI certificates. PKI certificate-based authentication is performed by requiring the certificate holder to cryptographically prove possession of the corresponding private key. If the private key is stolen, an attacker can use the private key(s) to impersonate the certificate holder. In cases where the DBMS-stored private keys are used to authenticate the DBMS to the system’s clients, loss of the corresponding private keys would allow an attacker to successfully perform undetected man-in-the-middle attacks against the DBMS system and its clients. Both the holder of a digital certificate and the issuing authority must take careful measures to protect the corresponding private key. Private keys should always be generated and protected in FIPS 140-2 or 140-3 validated cryptographic modules. All access to the private key(s) of the DBMS must be restricted to authorized and authenticated users. If unauthorized users have access to one or more of the DBMS's private keys, an attacker could gain access to the key(s) and use them to impersonate the database on the network or otherwise perform unauthorized actions.
Checks: C-22082r401552_chk

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.

Fix: F-22071r401553_fix

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

c
MarkLogic Server must use NIST FIPS 140-2 or 140-3 validated cryptographic modules for cryptographic operations and protect classified information in accordance with the requirements of the data owner.
IA-7 - High - CCI-000803 - V-220368 - SV-220368r961050_rule
RMF Control
IA-7
Severity
High
CCI
CCI-000803
Version
ML09-00-004300
Vuln IDs
  • V-220368
  • V-100981
Rule IDs
  • SV-220368r961050_rule
  • SV-110085
Use of weak or not validated cryptographic algorithms undermines the purposes of using encryption and digital signatures to protect data. Weak algorithms can be easily broken, and cryptographic modules that are not validated may not implement algorithms correctly. Unapproved cryptographic modules or algorithms should not be relied on for authentication, confidentiality, or integrity. Weak cryptography could allow an attacker to gain access to and modify data stored in the database as well as the administration settings of the DBMS. Applications, including DBMSs, using cryptography are required to use approved NIST FIPS 140-2 or 140-3 validated cryptographic modules that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. NSA Type-X (where X=1, 2, 3, 4) products are NSA-certified, hardware-based encryption modules. The standard for validating cryptographic modules will transition to the NIST FIPS 140-3 publication. FIPS 140-2 modules can remain active for up to five years after validation or until September 21, 2026, when the FIPS 140-2 validations will be moved to the historical list. Even on the historical list, CMVP supports the purchase and use of these modules for existing systems. While Federal Agencies decide when they move to FIPS 140-3 only modules, purchasers are reminded that for several years there may be a limited selection of FIPS 140-3 modules from which to choose. CMVP recommends purchasers consider all modules that appear on the Validated Modules Search Page: https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules More information on the FIPS 140-3 transition can be found here: https://csrc.nist.gov/Projects/fips-140-3-transition-effort/ Satisfies: SRG-APP-000179-DB-000114, SRG-APP-000416-DB-000380
Checks: C-22083r401555_chk

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.

Fix: F-22072r401556_fix

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.

b
MarkLogic Server must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).
IA-8 - Medium - CCI-000804 - V-220369 - SV-220369r961053_rule
RMF Control
IA-8
Severity
Medium
CCI
CCI-000804
Version
ML09-00-004400
Vuln IDs
  • V-220369
  • V-100983
Rule IDs
  • SV-220369r961053_rule
  • SV-110087
Non-organizational users include all information system users other than organizational users, which include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations). Non-organizational users must be uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization when related to the use of anonymous access, such as accessing a web server. Accordingly, a risk assessment is used in determining the authentication needs of the organization. Scalability, practicality, and security are simultaneously considered in balancing the need to ensure ease of use for access to federal information and information systems with the need to protect and adequately mitigate risk to organizational operations, organizational assets, individuals, other organizations, and the Nation.
Checks: C-22084r531256_chk

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.

Fix: F-22073r401559_fix

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.

b
MarkLogic Server must separate user functionality (including user interface services) from database management functionality.
SC-2 - Medium - CCI-001082 - V-220370 - SV-220370r961095_rule
RMF Control
SC-2
Severity
Medium
CCI
CCI-001082
Version
ML09-00-004500
Vuln IDs
  • V-220370
  • V-100985
Rule IDs
  • SV-220370r961095_rule
  • SV-110089
Information system management functionality includes functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. The separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, combinations of these methods, or other methods, as appropriate. An example of this type of separation is observed in web administrative interfaces that use separate authentication methods for users of any other information system resources. This may include isolating the administrative interface on a different domain and with additional access controls. If administrative functionality or information regarding DBMS management is presented on an interface available for users, information on DBMS settings may be inadvertently made available to the user.
Checks: C-22085r401561_chk

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.

Fix: F-22074r401562_fix

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.

b
MarkLogic Server must maintain the authenticity of communications sessions by guarding against man-in-the-middle attacks that guess at Session ID values.
SC-23 - Medium - CCI-001188 - V-220371 - SV-220371r961119_rule
RMF Control
SC-23
Severity
Medium
CCI
CCI-001188
Version
ML09-00-004800
Vuln IDs
  • V-220371
  • V-100987
Rule IDs
  • SV-220371r961119_rule
  • SV-110091
One class of man-in-the-middle, or session hijacking, attacks involves the adversary guessing at valid session identifiers based on patterns in known identifiers. The preferred technique for thwarting guesses at Session IDs is the generation of unique session identifiers using a FIPS 140-2 or 140-3 approved random number generator. However, it is recognized that available DBMS products do not all implement the preferred technique yet may have other protections against session hijacking. Therefore, other techniques are acceptable, provided they are demonstrated to be effective. MarkLogic Server uses OpenSSL to implement the Secure Sockets Layer (SSL v3) and Transport Layer Security (TLS v1) protocols.
Checks: C-22086r401564_chk

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.

Fix: F-22075r401565_fix

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.

c
MarkLogic Server must protect the confidentiality and integrity of all information at rest.
SC-28 - High - CCI-001199 - V-220372 - SV-220372r961128_rule
RMF Control
SC-28
Severity
High
CCI
CCI-001199
Version
ML09-00-005100
Vuln IDs
  • V-220372
  • V-100989
Rule IDs
  • SV-220372r961128_rule
  • SV-110093
This control is intended to address the confidentiality and integrity of information at rest in non-mobile devices and covers user information and system information. Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive, tape drive) within an organizational information system. Applications and application users generate information throughout the course of their application use. User data generated, as well as application-specific configuration data, needs to be protected. Organizations may choose to employ different mechanisms to achieve confidentiality and integrity protections, as appropriate. If the confidentiality and integrity of application data is not protected, the data will be open to compromise and unauthorized modification. Encryption at rest protects data on media, that is, data at rest as opposed to data moving across a communications channel (data in motion). Increasing security risks and compliance requirements sometimes mandate the use of encryption at rest to prevent unauthorized access to data on disk. Encryption at rest can be configured to encrypt data, log files, and configuration files separately. Encryption is only applied to newly created files once encryption at rest is enabled, and does not apply to existing files without further action by the user. For existing data, a merge or re-index will trigger encryption of data, a configuration change will trigger encryption of configuration files, and log rotation will initiate log encryption. More information can be found here: https://docs.marklogic.com/guide/security/encryption
Checks: C-22087r401567_chk

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

Fix: F-22076r401568_fix

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.

b
Access to MarkLogic Server files must be limited to relevant processes and to authorized, administrative users.
SC-4 - Medium - CCI-001090 - V-220373 - SV-220373r961149_rule
RMF Control
SC-4
Severity
Medium
CCI
CCI-001090
Version
ML09-00-005500
Vuln IDs
  • V-220373
  • V-100991
Rule IDs
  • SV-220373r961149_rule
  • SV-110095
Applications, including DBMSs, must prevent unauthorized and unintended information transfer via shared system resources. Permitting only DBMS processes and authorized, administrative users to have access to the files where the database resides helps ensure those files are not shared inappropriately and are not open to backdoor access and manipulation. Encryption at rest protects data on media, that is, data at rest as opposed to data moving across a communications channel, otherwise known as data in motion. Increasing security risks and compliance requirements sometimes mandate the use of encryption at rest to prevent unauthorized access to data on disk. Encryption at rest can be configured to encrypt data, log files, and configuration files separately. Encryption is only applied to newly created files once encryption at rest is enabled, and does not apply to existing files without further action by the user. For existing data, a merge or re-index will trigger encryption of data, a configuration change will trigger encryption of configuration files, and log rotation will initiate log encryption. For more information: See: https://docs.marklogic.com/guide/security/encryption
Checks: C-22088r401570_chk

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: &gt; 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

Fix: F-22077r401571_fix

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

b
MarkLogic Server must provide non-privileged users with error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries.
SI-11 - Medium - CCI-001312 - V-220374 - SV-220374r961167_rule
RMF Control
SI-11
Severity
Medium
CCI
CCI-001312
Version
ML09-00-005900
Vuln IDs
  • V-220374
  • V-100993
Rule IDs
  • SV-220374r961167_rule
  • SV-110097
Any DBMS or associated application providing too much information in error messages on the screen or printout risks compromising the data and security of the system. The structure and content of error messages must be carefully considered by the organization and development team. Databases can inadvertently provide a wealth of information to an attacker through improperly handled error messages. In addition to sensitive business or personal information, database errors can provide host names, IP addresses, user names, and other system information not required for troubleshooting but very useful to someone targeting the system. Carefully consider the structure/content of error messages. The extent to which information systems are able to identify and handle error conditions is guided by organizational policy and operational requirements. Information that could be exploited by adversaries includes, for example, logon attempts with passwords entered by mistake as the username, mission/business information that can be derived from (if not stated explicitly by) information recorded, and personal information, such as account numbers, social security numbers, and credit card numbers. This calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers, and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed, and must document what has been discovered.
Checks: C-22089r401573_chk

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.

Fix: F-22078r401574_fix

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

b
MarkLogic Server must associate organization-defined types of security labels having organization-defined security label values with information in process.
AC-16 - Medium - CCI-002263 - V-220375 - SV-220375r961272_rule
RMF Control
AC-16
Severity
Medium
CCI
CCI-002263
Version
ML09-00-006400
Vuln IDs
  • V-220375
  • V-100995
Rule IDs
  • SV-220375r961272_rule
  • SV-110099
Without the association of security labels to information, there is no basis for the DBMS to make security-related access-control decisions. Security labels are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These labels are typically associated with internal data structures (e.g., tables, rows) within the database and are used to enable the implementation of access control and flow control policies; reflect special dissemination, handling, or distribution instructions; or support other aspects of the information security policy. One example includes marking data as classified or FOUO. These security labels may be assigned manually or during data processing, and it is imperative these assignments are maintained while the data is in storage. If the security labels are lost when the data is stored, there is the risk of a data compromise. The mechanism used to support security labeling may be a feature of the DBMS product, a third-party product, or custom application code.
Checks: C-22090r855477_chk

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 &gt;&gt; Security &gt;&gt; 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.

Fix: F-22079r401577_fix

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.

b
MarkLogic Server must associate organization-defined types of security labels having organization-defined security label values with information in transmission.
AC-16 - Medium - CCI-002264 - V-220376 - SV-220376r961275_rule
RMF Control
AC-16
Severity
Medium
CCI
CCI-002264
Version
ML09-00-006500
Vuln IDs
  • V-220376
  • V-100997
Rule IDs
  • SV-220376r961275_rule
  • SV-110101
Without the association of security labels to information, there is no basis for the DBMS to make security-related access-control decisions. Security labels are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These labels are typically associated with internal data structures (e.g., tables, rows) within the database and are used to enable the implementation of access control and flow control policies; reflect special dissemination, handling, or distribution instructions; or support other aspects of the information security policy. One example includes marking data as classified or FOUO. These security labels may be assigned manually or during data processing, and it is imperative these assignments are maintained while the data is in storage. If the security labels are lost when the data is stored, there is the risk of a data compromise. The mechanism used to support security labeling may be a feature of the DBMS product, a third-party product, or custom application code.
Checks: C-22091r855479_chk

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 &gt;&gt; Security &gt;&gt; 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.

Fix: F-22080r401580_fix

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.

b
MarkLogic Server must prevent non-privileged users from executing privileged functions, to include disabling, circumventing, or altering implemented security safeguards/countermeasures.
AC-6 - Medium - CCI-002235 - V-220377 - SV-220377r961353_rule
RMF Control
AC-6
Severity
Medium
CCI
CCI-002235
Version
ML09-00-006700
Vuln IDs
  • V-220377
  • V-100999
Rule IDs
  • SV-220377r961353_rule
  • SV-110103
Preventing non-privileged users from executing privileged functions mitigates the risk that unauthorized individuals or processes may gain unnecessary access to information or privileges. System documentation should include a definition of the functionality considered privileged. Depending on circumstances, privileged functions can include, for example, establishing accounts, performing system integrity checks, or administering cryptographic key management activities. Non-privileged users are individuals that do not possess appropriate authorizations. Circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms are examples of privileged functions that require protection from non-privileged users. A privileged function in the DBMS/database context is any operation that modifies the structure of the database, its built-in logic, or its security settings. This would include all Data Definition Language (DDL) statements and all security-related statements. In an SQL environment, it encompasses, but is not necessarily limited to: CREATE ALTER DROP GRANT REVOKE DENY There may also be Data Manipulation Language (DML) statements that, subject to context, should be regarded as privileged. Possible examples include: TRUNCATE TABLE; DELETE, or DELETE affecting more than n rows, for some n, or DELETE without a WHERE clause; UPDATE or UPDATE affecting more than n rows, for some n, or UPDATE without a WHERE clause; any SELECT, INSERT, UPDATE, or DELETE to an application-defined security table executed by other than a security principal. Depending on the capabilities of the DBMS and the design of the database and associated applications, the prevention of unauthorized use of privileged functions may be achieved by means of DBMS security features, database triggers, other mechanisms, or a combination of these.
Checks: C-22092r401582_chk

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 &gt;&gt; Security &gt;&gt; Roles. 2. Validate user-created roles have appropriate permissions/roles applied. 3. Navigate to the MarkLogic Admin page &gt;&gt; Security &gt;&gt; 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.

Fix: F-22081r401583_fix

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.

b
Execution of software modules (to include stored procedures, functions, and triggers) with elevated privileges must be restricted to necessary cases only.
AC-6 - Medium - CCI-002233 - V-220378 - SV-220378r961359_rule
RMF Control
AC-6
Severity
Medium
CCI
CCI-002233
Version
ML09-00-006800
Vuln IDs
  • V-220378
  • V-101001
Rule IDs
  • SV-220378r961359_rule
  • SV-110105
In certain situations, to provide required functionality, a DBMS needs to execute internal logic (stored procedures, functions, triggers, etc.) and/or external code modules with elevated privileges. However, if the privileges required for execution are at a higher level than the privileges assigned to organizational users invoking the functionality applications/programs, those users are indirectly provided with greater privileges than assigned by organizations. Privilege elevation must be utilized only where necessary and protected from misuse. This calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers, and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed, and must document what has been discovered.
Checks: C-22093r401585_chk

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 &gt;&gt; Security &gt;&gt; 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.

Fix: F-22082r401586_fix

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

b
MarkLogic Server must allocate audit record storage capacity in accordance with organization-defined audit record storage requirements.
AU-4 - Medium - CCI-001849 - V-220380 - SV-220380r961392_rule
RMF Control
AU-4
Severity
Medium
CCI
CCI-001849
Version
ML09-00-007200
Vuln IDs
  • V-220380
  • V-101005
Rule IDs
  • SV-220380r961392_rule
  • SV-110109
To ensure sufficient storage capacity for the audit logs, the DBMS must be able to allocate audit record storage capacity. Although another requirement (SRG-APP-000515-DB-000318) mandates that audit data be off-loaded to a centralized log management system, it remains necessary to provide space on the database server to serve as a buffer against outages and capacity limits of the off-loading mechanism. The task of allocating audit record storage capacity is usually performed during initial installation of the DBMS and is closely associated with the DBA and system administrator roles. The DBA or system administrator will usually coordinate the allocation of physical drive space with the application owner/installer and the application will prompt the installer to provide the capacity information, the physical location of the disk, or both. In determining the capacity requirements, consider such factors as: total number of users; expected number of concurrent users during busy periods; number and type of events being monitored; types and amounts of data being captured; the frequency/speed with which audit records are off-loaded to the central log management system; and any limitations that exist on the DBMS's ability to reuse the space formerly occupied by off-loaded records.
Checks: C-22095r401591_chk

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.

Fix: F-22084r855484_fix

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.

b
MarkLogic Server must provide a warning to appropriate support staff when allocated audit record storage volume reaches 75 percent of maximum audit record storage capacity.
AU-5 - Medium - CCI-001855 - V-220381 - SV-220381r961398_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-001855
Version
ML09-00-007300
Vuln IDs
  • V-220381
  • V-101007
Rule IDs
  • SV-220381r961398_rule
  • SV-110111
Organizations are required to use a central log management system, so, under normal conditions, the audit space allocated to the DBMS on its own server will not be an issue. However, space will still be required on the DBMS server for audit records in transit, and, under abnormal conditions, this could fill up. Since a requirement exists to halt processing upon audit failure, a service outage would result. If support personnel are not notified immediately upon storage volume utilization reaching 75 percent, they are unable to plan for storage capacity expansion. The appropriate support staff include, at a minimum, the ISSO and the DBA/SA.
Checks: C-22096r401594_chk

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.

Fix: F-22085r401595_fix

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.

b
MarkLogic Server must provide an immediate real-time alert to appropriate support staff of all audit failures.
AU-5 - Medium - CCI-001858 - V-220382 - SV-220382r961401_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-001858
Version
ML09-00-007400
Vuln IDs
  • V-220382
  • V-101009
Rule IDs
  • SV-220382r961401_rule
  • SV-110113
It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without a real-time alert, security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected. The appropriate support staff include, at a minimum, the ISSO and the DBA/SA. A failure of database auditing will result in either the database continuing to function without auditing or a complete halt to database operations. When audit processing fails, appropriate personnel must be alerted immediately to avoid further downtime or unaudited transactions. Alerts provide organizations with urgent messages. Real-time alerts provide these messages immediately (i.e., the time from event detection to alert occurs in seconds or less).
Checks: C-22097r401597_chk

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.

Fix: F-22086r401598_fix

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.

b
MarkLogic Server must produce audit records of its enforcement of access restrictions associated with changes to the configuration of the DBMS or database(s).
- Medium - CCI-003938 - V-220383 - SV-220383r1018605_rule
RMF Control
Severity
Medium
CCI
CCI-003938
Version
ML09-00-007900
Vuln IDs
  • V-220383
  • V-101011
Rule IDs
  • SV-220383r1018605_rule
  • SV-110115
Without auditing the enforcement of access restrictions against changes to configuration, it would be difficult to identify attempted attacks and an audit trail would not be available for forensic investigation for after-the-fact actions. Enforcement actions are the methods or mechanisms used to prevent unauthorized changes to configuration settings. Enforcement action methods may be as simple as denying access to a file based on the application of file permissions (access restriction). Audit items may consist of lists of actions blocked by access restrictions or changes identified after the fact.
Checks: C-22098r401600_chk

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.

Fix: F-22087r401601_fix

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.

b
MarkLogic Server must disable network functions, ports, protocols, and services deemed by the organization to be nonsecure, in accordance with Ports, Protocols, and Services Management (PPSM) guidance.
CM-7 - Medium - CCI-001762 - V-220384 - SV-220384r961470_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-001762
Version
ML09-00-008000
Vuln IDs
  • V-220384
  • V-101013
Rule IDs
  • SV-220384r961470_rule
  • SV-110117
Use of nonsecure network functions, ports, protocols, and services exposes the system to avoidable threats.
Checks: C-22099r401603_chk

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.

Fix: F-22088r401604_fix

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.

b
MarkLogic Server must prohibit the use of cached authenticators after an organization-defined time period.
IA-5 - Medium - CCI-002007 - V-220385 - SV-220385r961521_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-002007
Version
ML09-00-008200
Vuln IDs
  • V-220385
  • V-101015
Rule IDs
  • SV-220385r961521_rule
  • SV-110119
If cached authentication information is out-of-date, the validity of the authentication information may be questionable.
Checks: C-22100r401606_chk

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.

Fix: F-22089r401607_fix

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.

b
MarkLogic Server must only accept end-entity certificates issued by DoD PKI or DoD-approved PKI Certification Authorities (CAs) for the establishment of all encrypted sessions.
SC-23 - Medium - CCI-002470 - V-220386 - SV-220386r961596_rule
RMF Control
SC-23
Severity
Medium
CCI
CCI-002470
Version
ML09-00-008400
Vuln IDs
  • V-220386
  • V-101017
Rule IDs
  • SV-220386r961596_rule
  • SV-110121
Only DoD-approved external PKIs have been evaluated to ensure that they have security controls and identity vetting procedures in place sufficient for DoD systems to rely on the identity asserted in the certificate. PKIs lacking sufficient security controls and identity vetting procedures risk being compromised and issuing certificates that enable adversaries to impersonate legitimate users. The authoritative list of DoD-approved PKIs is published at https://public.cyber.mil/pki-pke/interoperability/. This requirement focuses on communications protection for the DBMS session rather than for the network packet.
Checks: C-22101r401609_chk

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.

Fix: F-22090r401610_fix

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.

c
MarkLogic Server must implement cryptographic mechanisms to prevent unauthorized modification of organization-defined information at rest (to include, at a minimum, PII and classified information) on organization-defined information system components.
SC-28 - High - CCI-002475 - V-220387 - SV-220387r1018556_rule
RMF Control
SC-28
Severity
High
CCI
CCI-002475
Version
ML09-00-008500
Vuln IDs
  • V-220387
  • V-101019
Rule IDs
  • SV-220387r1018556_rule
  • SV-110123
DBMSs handling data requiring data-at-rest protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest. These cryptographic mechanisms may be native to the DBMS or implemented via additional software or operating system/file system settings, as appropriate to the situation. Selection of a cryptographic mechanism is based on the need to protect the integrity of organizational information. The strength of the mechanism is commensurate with the security category and/or classification of the information. Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields). The decision whether and what to encrypt rests with the data owner and is also influenced by the physical measures taken to secure the equipment and media on which the information resides.
Checks: C-22102r401612_chk

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

Fix: F-22091r401613_fix

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.

c
MarkLogic Server must implement cryptographic mechanisms preventing the unauthorized disclosure of organization-defined information at rest on organization-defined information system components.
SC-28 - High - CCI-002476 - V-220388 - SV-220388r1018557_rule
RMF Control
SC-28
Severity
High
CCI
CCI-002476
Version
ML09-00-008600
Vuln IDs
  • V-220388
  • V-101021
Rule IDs
  • SV-220388r1018557_rule
  • SV-110125
DBMSs handling data requiring data-at-rest protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest. These cryptographic mechanisms may be native to the DBMS or implemented via additional software or operating system/file system settings, as appropriate to the situation. Selection of a cryptographic mechanism is based on the need to protect the integrity of organizational information. The strength of the mechanism is commensurate with the security category and/or classification of the information. Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields). The decision whether and what to encrypt rests with the data owner and is also influenced by the physical measures taken to secure the equipment and media on which the information resides.
Checks: C-22103r401615_chk

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

Fix: F-22092r401616_fix

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.

b
Security-relevant software updates to MarkLogic Server must be installed within the time period directed by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs).
SI-2 - Medium - CCI-002605 - V-220389 - SV-220389r1001008_rule
RMF Control
SI-2
Severity
Medium
CCI
CCI-002605
Version
ML09-00-009200
Vuln IDs
  • V-220389
  • V-101023
Rule IDs
  • SV-220389r1001008_rule
  • SV-110127
Security flaws with software applications, including database management systems, are discovered daily. Vendors are constantly updating and patching their products to address newly discovered security vulnerabilities. Organizations (including any contractor to the organization) are required to promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling must also be addressed expeditiously. Organization-defined time periods for updating security-relevant software may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). This requirement will apply to software patch management solutions used to install patches across the enclave and also to applications themselves not part of that patch management solution. For example, many browsers today provide the capability to install their own patch software. Patch criticality, as well as system criticality, will vary. Therefore, the tactical situations regarding the patch management process will also vary. This means that the time period utilized must be a configurable parameter. Time frames for application of security-relevant software updates may be dependent upon the Information Assurance Vulnerability Management (IAVM) process. The application will be configured to check for and install security-relevant software updates within an identified time period from the availability of the update. The specific time period will be defined by an authoritative source (e.g. IAVM, CTOs, DTMs, and STIGs). 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.
Checks: C-22104r401618_chk

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.

Fix: F-22093r401619_fix

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.

b
MarkLogic Server must be able to generate audit records when security objects are accessed.
AU-12 - Medium - CCI-000172 - V-220390 - SV-220390r961791_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-009300
Vuln IDs
  • V-220390
  • V-101025
Rule IDs
  • SV-220390r961791_rule
  • SV-110129
Changes to the security configuration must be tracked. This requirement applies to situations where security data is retrieved or modified via data manipulation operations, as opposed to via specialized security functionality.
Checks: C-22105r401621_chk

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.

Fix: F-22094r401622_fix

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.

b
MarkLogic Server must generate audit records when unsuccessful attempts to access security objects occur.
AU-12 - Medium - CCI-000172 - V-220391 - SV-220391r961791_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-009400
Vuln IDs
  • V-220391
  • V-101027
Rule IDs
  • SV-220391r961791_rule
  • SV-110131
Changes to the security configuration must be tracked. This requirement applies to situations where security data is retrieved or modified via data manipulation operations, as opposed to via specialized security functionality. To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.
Checks: C-22106r401624_chk

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.

Fix: F-22095r401625_fix

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.

b
MarkLogic Server must generate audit records when categories of information (e.g., classification levels/security levels) are accessed.
AU-12 - Medium - CCI-000172 - V-220392 - SV-220392r961797_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-009500
Vuln IDs
  • V-220392
  • V-101029
Rule IDs
  • SV-220392r961797_rule
  • SV-110133
Changes in categories of information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected. For detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.
Checks: C-22107r401627_chk

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.

Fix: F-22096r401628_fix

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.

b
MarkLogic Server must generate audit records when unsuccessful attempts to access categories of information (e.g., classification levels/security levels) occur.
AU-12 - Medium - CCI-000172 - V-220393 - SV-220393r961797_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-009600
Vuln IDs
  • V-220393
  • V-101031
Rule IDs
  • SV-220393r961797_rule
  • SV-110135
Changes in categories of information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected. To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones. For detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.
Checks: C-22108r401630_chk

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.

Fix: F-22097r401631_fix

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.

b
MarkLogic Server must generate audit records when privileges/permissions are added.
AU-12 - Medium - CCI-000172 - V-220394 - SV-220394r961800_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-009700
Vuln IDs
  • V-220394
  • V-101033
Rule IDs
  • SV-220394r961800_rule
  • SV-110137
Changes in the permissions, privileges, and roles granted to users and roles must be tracked. Without an audit trail, unauthorized elevation or restriction of privileges could go undetected. Elevated privileges give users access to information and functionality that they should not have; restricted privileges wrongly deny access to authorized users.
Checks: C-22109r401633_chk

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.

Fix: F-22098r401634_fix

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.

b
MarkLogic Server must generate audit records when unsuccessful attempts to add privileges/permissions occur.
AU-12 - Medium - CCI-000172 - V-220395 - SV-220395r961800_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-009800
Vuln IDs
  • V-220395
  • V-101035
Rule IDs
  • SV-220395r961800_rule
  • SV-110139
Failed attempts to change the permissions, privileges, and roles granted to users and roles must be tracked. Without an audit trail, unauthorized attempts to elevate or restrict privileges could go undetected. To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.
Checks: C-22110r401636_chk

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.

Fix: F-22099r401637_fix

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.

b
MarkLogic Server must generate audit records when privileges/permissions are modified.
AU-12 - Medium - CCI-000172 - V-220396 - SV-220396r961800_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-009900
Vuln IDs
  • V-220396
  • V-101037
Rule IDs
  • SV-220396r961800_rule
  • SV-110141
Changes in the permissions, privileges, and roles granted to users and roles must be tracked. Without an audit trail, unauthorized elevation or restriction of privileges could go undetected. Elevated privileges give users access to information and functionality that they should not have; restricted privileges wrongly deny access to authorized users.
Checks: C-22111r401639_chk

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.

Fix: F-22100r401640_fix

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.

b
MarkLogic Server must generate audit records when unsuccessful attempts to modify privileges/permissions occur.
AU-12 - Medium - CCI-000172 - V-220397 - SV-220397r961800_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-010000
Vuln IDs
  • V-220397
  • V-101039
Rule IDs
  • SV-220397r961800_rule
  • SV-110143
Failed attempts to change the permissions, privileges, and roles granted to users and roles must be tracked. Without an audit trail, unauthorized attempts to elevate or restrict privileges could go undetected. To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.
Checks: C-22112r401642_chk

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.

Fix: F-22101r401643_fix

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.

b
MarkLogic Server must generate audit records when security objects are modified.
AU-12 - Medium - CCI-000172 - V-220398 - SV-220398r961803_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-010100
Vuln IDs
  • V-220398
  • V-101041
Rule IDs
  • SV-220398r961803_rule
  • SV-110145
Changes in the database objects (tables, views, procedures, functions) that record and control permissions, privileges, and roles granted to users and roles must be tracked. Without an audit trail, unauthorized changes to the security subsystem could go undetected. The database could be severely compromised or rendered inoperative.
Checks: C-22113r401645_chk

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.

Fix: F-22102r401646_fix

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.

b
MarkLogic Server must generate audit records when unsuccessful attempts to modify security objects occur.
AU-12 - Medium - CCI-000172 - V-220399 - SV-220399r961803_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-010200
Vuln IDs
  • V-220399
  • V-101043
Rule IDs
  • SV-220399r961803_rule
  • SV-110147
Changes in the database objects (tables, views, procedures, functions) that record and control permissions, privileges, and roles granted to users and roles must be tracked. Without an audit trail, unauthorized changes to the security subsystem could go undetected. The database could be severely compromised or rendered inoperative. To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.
Checks: C-22114r401648_chk

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.

Fix: F-22103r401649_fix

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.

b
MarkLogic Server must generate audit records when categories of information (e.g., classification levels/security levels) are modified.
AU-12 - Medium - CCI-000172 - V-220400 - SV-220400r961809_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-010300
Vuln IDs
  • V-220400
  • V-101045
Rule IDs
  • SV-220400r961809_rule
  • SV-110149
Changes in categories of information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected. For detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.
Checks: C-22115r401651_chk

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.

Fix: F-22104r401652_fix

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.

b
MarkLogic Server must generate audit records when unsuccessful attempts to modify categories of information (e.g., classification levels/security levels) occur.
AU-12 - Medium - CCI-000172 - V-220401 - SV-220401r961809_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-010400
Vuln IDs
  • V-220401
  • V-101047
Rule IDs
  • SV-220401r961809_rule
  • SV-110151
Changes in categories of information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected. To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones. For detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.
Checks: C-22116r401654_chk

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.

Fix: F-22105r401655_fix

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.

b
MarkLogic Server must generate audit records when privileges/permissions are deleted.
AU-12 - Medium - CCI-000172 - V-220402 - SV-220402r961812_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-010500
Vuln IDs
  • V-220402
  • V-101049
Rule IDs
  • SV-220402r961812_rule
  • SV-110153
Changes in the permissions, privileges, and roles granted to users and roles must be tracked. Without an audit trail, unauthorized elevation or restriction of privileges could go undetected. Elevated privileges give users access to information and functionality that they should not have; restricted privileges wrongly deny access to authorized users.
Checks: C-22117r401657_chk

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.

Fix: F-22106r401658_fix

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.

b
MarkLogic Server must generate audit records when unsuccessful attempts to delete privileges/permissions occur.
AU-12 - Medium - CCI-000172 - V-220403 - SV-220403r961812_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-010600
Vuln IDs
  • V-220403
  • V-101051
Rule IDs
  • SV-220403r961812_rule
  • SV-110155
Failed attempts to change the permissions, privileges, and roles granted to users and roles must be tracked. Without an audit trail, unauthorized attempts to elevate or restrict privileges could go undetected. To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.
Checks: C-22118r401660_chk

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.

Fix: F-22107r401661_fix

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.

b
MarkLogic Server DBMS must generate audit records when security objects are deleted.
AU-12 - Medium - CCI-000172 - V-220404 - SV-220404r961818_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-010700
Vuln IDs
  • V-220404
  • V-101053
Rule IDs
  • SV-220404r961818_rule
  • SV-110157
The removal of security objects from the database/DBMS would seriously degrade a system's information assurance posture. If such an event occurs, it must be logged.
Checks: C-22119r401663_chk

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.

Fix: F-22108r401664_fix

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.

b
MarkLogic Server must generate audit records when unsuccessful attempts to delete security objects occur.
AU-12 - Medium - CCI-000172 - V-220405 - SV-220405r961818_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-010800
Vuln IDs
  • V-220405
  • V-101055
Rule IDs
  • SV-220405r961818_rule
  • SV-110159
The removal of security objects from the database/DBMS would seriously degrade a system's information assurance posture. If such an action is attempted, it must be logged. To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.
Checks: C-22120r401666_chk

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.

Fix: F-22109r401667_fix

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.

b
MarkLogic Server must generate audit records when categories of information (e.g., classification levels/security levels) are deleted.
AU-12 - Medium - CCI-000172 - V-220406 - SV-220406r961821_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-010900
Vuln IDs
  • V-220406
  • V-101057
Rule IDs
  • SV-220406r961821_rule
  • SV-110161
Changes in categories of information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected. For detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.
Checks: C-22121r401669_chk

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.

Fix: F-22110r401670_fix

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.

b
MarkLogic Server must generate audit records when unsuccessful attempts to delete categories of information (e.g., classification levels/security levels) occur.
AU-12 - Medium - CCI-000172 - V-220407 - SV-220407r961821_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-011000
Vuln IDs
  • V-220407
  • V-101059
Rule IDs
  • SV-220407r961821_rule
  • SV-110163
Changes in categories of information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected. To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones. For detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.
Checks: C-22122r401672_chk

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.

Fix: F-22111r401673_fix

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.

b
MarkLogic Server must generate audit records when successful logons or connections occur.
AU-12 - Medium - CCI-000172 - V-220408 - SV-220408r961824_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-011100
Vuln IDs
  • V-220408
  • V-101061
Rule IDs
  • SV-220408r961824_rule
  • SV-110165
For completeness of forensic analysis, it is necessary to track who/what (a user or other principal) logs on to the DBMS.
Checks: C-22123r401675_chk

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.

Fix: F-22112r401676_fix

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.

b
MarkLogic Server must generate audit records when unsuccessful logons or connection attempts occur.
AU-12 - Medium - CCI-000172 - V-220409 - SV-220409r961824_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-011200
Vuln IDs
  • V-220409
  • V-101063
Rule IDs
  • SV-220409r961824_rule
  • SV-110167
For completeness of forensic analysis, it is necessary to track failed attempts to log on to the DBMS. While positive identification may not be possible in a case of failed authentication, as much information as possible about the incident must be captured.
Checks: C-22124r401678_chk

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.

Fix: F-22113r401679_fix

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.

b
MarkLogic Server must generate audit records for all privileged activities or other system-level access.
AU-12 - Medium - CCI-000172 - V-220410 - SV-220410r961827_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-011300
Vuln IDs
  • V-220410
  • V-101065
Rule IDs
  • SV-220410r961827_rule
  • SV-110169
Without tracking privileged activity, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. System documentation should include a definition of the functionality considered privileged. A privileged function in this context is any operation that modifies the structure of the database, its built-in logic, or its security settings. This would include all Data Definition Language (DDL) statements and all security-related statements. Depending on the capabilities of the DBMS and the design of the database and associated applications, audit logging may be achieved by means of DBMS auditing features, database triggers, other mechanisms, or a combination of these. Note that it is particularly important to audit, and tightly control, any action that weakens the implementation of this requirement itself, since the objective is to have a complete audit trail of all administrative activity.
Checks: C-22125r401681_chk

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.

Fix: F-22114r401682_fix

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.

b
MarkLogic Server must generate audit records when unsuccessful attempts to execute privileged activities or other system-level access occur.
AU-12 - Medium - CCI-000172 - V-220411 - SV-220411r961827_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-011400
Vuln IDs
  • V-220411
  • V-101067
Rule IDs
  • SV-220411r961827_rule
  • SV-110171
Without tracking privileged activity, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. System documentation should include a definition of the functionality considered privileged. A privileged function in this context is any operation that modifies the structure of the database, its built-in logic, or its security settings. This would include all Data Definition Language (DDL) statements and all security-related statements. Depending on the capabilities of the DBMS and the design of the database and associated applications, audit logging may be achieved by means of DBMS auditing features, database triggers, other mechanisms, or a combination of these. Note that it is particularly important to audit, and tightly control, any action that weakens the implementation of this requirement itself, since the objective is to have a complete audit trail of all administrative activity. To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.
Checks: C-22126r401684_chk

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.

Fix: F-22115r401685_fix

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.

b
MarkLogic Server must generate audit records when concurrent logons/connections by the same user from different workstations occur.
AU-12 - Medium - CCI-000172 - V-220412 - SV-220412r961833_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-011600
Vuln IDs
  • V-220412
  • V-101069
Rule IDs
  • SV-220412r961833_rule
  • SV-110173
For completeness of forensic analysis, it is necessary to track who logs on to the DBMS. Concurrent connections by the same user from multiple workstations may be valid uses of the system, such connections may be due to improper circumvention of the requirement to use the CAC for authentication, may indicate unauthorized account sharing, or may be because an account has been compromised. (If the fact of multiple, concurrent logons by a given user can be reliably reconstructed from the log entries for other events (logons/connections; voluntary and involuntary disconnections), then it is not mandatory to create additional log entries specifically for this.)
Checks: C-22127r401687_chk

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.

Fix: F-22116r401688_fix

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.

b
MarkLogic must be able to generate audit records when successful accesses to objects occur.
AU-12 - Medium - CCI-000172 - V-220413 - SV-220413r961836_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
ML09-00-011700
Vuln IDs
  • V-220413
  • V-101071
Rule IDs
  • SV-220413r961836_rule
  • SV-110175
Without tracking all or selected types of access to all or selected objects (tables, views, procedures, functions, etc.), it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.
Checks: C-22128r401690_chk

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.

Fix: F-22117r401691_fix

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.

b
MarkLogic Server must implement NIST FIPS 140-2 or 140-3 validated cryptographic modules to provision digital signatures.
SC-13 - Medium - CCI-002450 - V-220414 - SV-220414r961857_rule
RMF Control
SC-13
Severity
Medium
CCI
CCI-002450
Version
ML09-00-012000
Vuln IDs
  • V-220414
  • V-101081
Rule IDs
  • SV-220414r961857_rule
  • SV-110185
Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. For detailed information, refer to NIST FIPS Publication 140-2 or Publication 140-3, Security Requirements for Cryptographic Modules. Note that the product's cryptographic modules must be validated and certified by NIST as FIPS-compliant.
Checks: C-22129r863307_chk

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.

Fix: F-22118r863308_fix

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.

b
MarkLogic Server must implement NIST FIPS 140-2 or 140-3 validated cryptographic modules to generate and validate cryptographic hashes.
SC-13 - Medium - CCI-002450 - V-220415 - SV-220415r961857_rule
RMF Control
SC-13
Severity
Medium
CCI
CCI-002450
Version
ML09-00-012100
Vuln IDs
  • V-220415
  • V-101073
Rule IDs
  • SV-220415r961857_rule
  • SV-110177
Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. For detailed information, refer to NIST FIPS Publication 140-2 or Publication 140-3, Security Requirements for Cryptographic Modules. Note that the product's cryptographic modules must be validated and certified by NIST as FIPS-compliant.
Checks: C-22130r863310_chk

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.

Fix: F-22119r863311_fix

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.

b
MarkLogic Server must implement NIST FIPS 140-2 or 140-3 validated cryptographic modules to protect unclassified information requiring confidentiality and cryptographic protection, in accordance with the requirements of the data owner.
SC-13 - Medium - CCI-002450 - V-220416 - SV-220416r961857_rule
RMF Control
SC-13
Severity
Medium
CCI
CCI-002450
Version
ML09-00-012200
Vuln IDs
  • V-220416
  • V-101075
Rule IDs
  • SV-220416r961857_rule
  • SV-110179
Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. It is the responsibility of the data owner to assess the cryptography requirements in light of applicable federal laws, Executive Orders, directives, policies, regulations, and standards. For detailed information, refer to NIST FIPS Publication 140-2 or Publication 140-3, Security Requirements for Cryptographic Modules. Note that the product's cryptographic modules must be validated and certified by NIST as FIPS-compliant.
Checks: C-22131r863313_chk

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.

Fix: F-22120r863314_fix

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.

a
MarkLogic Server must off-load audit data to a separate log management facility; this must be continuous and in near real time for systems with a network connection to the storage facility and weekly or more often for stand-alone systems.
AU-4 - Low - CCI-001851 - V-220417 - SV-220417r961860_rule
RMF Control
AU-4
Severity
Low
CCI
CCI-001851
Version
ML09-00-012300
Vuln IDs
  • V-220417
  • V-101077
Rule IDs
  • SV-220417r961860_rule
  • SV-110181
Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading is a common process in information systems with limited audit storage capacity. The DBMS may write audit records to database tables, to files in the file system, to other kinds of local repository, or directly to a centralized log management system. Whatever the method used, it must be compatible with off-loading the records to the centralized system.
Checks: C-22132r401702_chk

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.

Fix: F-22121r401703_fix

Configure the system to offload MarkLogic audit records. Add the MarkLogic Server instance under the monitoring of a third-party audit management tool.

b
MarkLogic Server must be configured in accordance with the security configuration settings based on DoD security configuration and implementation guidance, including STIGs, NSA configuration guides, CTOs, DTMs, and IAVMs.
CM-6 - Medium - CCI-000366 - V-220418 - SV-220418r961863_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ML09-00-012400
Vuln IDs
  • V-220418
  • V-101079
Rule IDs
  • SV-220418r961863_rule
  • SV-110183
Configuring the DBMS to implement organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DoD that reflects the most restrictive security posture consistent with operational requirements. In addition to this SRG, sources of guidance on security and information assurance exist. These include NSA configuration guides, CTOs, DTMs, and IAVMs. The DBMS must be configured in compliance with guidance from all such relevant sources.
Checks: C-22133r401705_chk

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.

Fix: F-22122r401706_fix

From the list of applicable DoD security configuration and implementation guidance, address the items that the MarkLogic Server configuration does not meet.

c
MarkLogic Server must be a version supported by the vendor.
SA-22 - High - CCI-003376 - V-265874 - SV-265874r999528_rule
RMF Control
SA-22
Severity
High
CCI
CCI-003376
Version
ML09-00-012500
Vuln IDs
  • V-265874
Rule IDs
  • SV-265874r999528_rule
Unsupported commercial and database systems should not be used because fixes to newly identified bugs will not be implemented by the vendor. The lack of support can result in potential vulnerabilities. Systems at unsupported servicing levels or releases will not receive security updates for new vulnerabilities, which leaves them subject to exploitation. When maintenance updates and patches are no longer available, the database software is no longer considered supported and should be upgraded or decommissioned.
Checks: C-69793r999526_chk

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.

Fix: F-69697r999527_fix

Remove or decommission all unsupported software products. Upgrade unsupported DBMS or unsupported components to a supported version of the product.