{"stig":{"title":"MarkLogic Server v9 Security Technical Implementation Guide","version":"3","release":"2"},"checks":[{"vulnId":"V-220339","ruleId":"SV-220339r960735_rule","severity":"low","ruleTitle":"MarkLogic Server must limit the number of concurrent sessions to an organization-defined number per user for all accounts and/or account types.","description":"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.\n\nThis 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.\n\nThe 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.\n\nThe 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.\n\n(Sessions may also be referred to as connections or logons, which for the purposes of this requirement are synonyms.)\n\nLimiting Concurrent Requests with User Session Limits\nThere 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.\n\nSetting 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.\n\nWhen the limit is reached, the application will throw a 403 (forbidden) error with the XDMP-REQUESTLIMIT exception.","checkContent":"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.\n\nCheck the concurrent-sessions settings in the MarkLogic. \n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the App Server to be checked resides (e.g., Default).\n3. Click the App Servers icon on the left tree menu.\n4. Select the App Server in which in which to check session limits. The App Server Configuration page displays.\n5. Inspect the concurrent request limit field; a value of 0 means there is no concurrent request limit (unlimited), and this is a finding. \n6. If a value other than 0 but not equal to the organization-defined number is set, this is a finding.\n7. Repeat for all App Servers.","fixText":"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.\n\nFix the concurrent-sessions settings in MarkLogic.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the App Server to be fixed resides (e.g., Default).\n3. Click the App Servers icon on the left tree menu.\n4. Select the App Server in which in which to fix session limits. The App Server Configuration page displays.\n5. In the concurrent request limit field, enter a value corresponding to the organization-defined maximum number of concurrent user sessions to allow.\n6. Repeat for all App Servers.","ccis":["CCI-000054"]},{"vulnId":"V-220340","ruleId":"SV-220340r960768_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nA comprehensive application account management process that includes automation helps to ensure accounts designated as requiring attention are consistently and promptly addressed. \n\nExamples 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.\n\nThe DBMS must be configured to automatically utilize organization-level account management functions and these functions must immediately enforce the organization's current account policy. \n\nAutomation may be comprised of differing technologies that when placed together contain an overall mechanism supporting an organization's automated account management requirements.\n\nMarkLogic 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.\n\nMarkLogic Server can be configured with multiple external security providers. A user only needs to authenticate with one of them to gain access.","checkContent":"If all accounts are authenticated by the organization-level authentication/access mechanism and not by the MarkLogic, this is not a finding.\n\nIf there are any accounts managed by MarkLogic, review the system documentation for justification and approval of these accounts.\n\nIf any MarkLogic-managed accounts exist that are not documented and approved, this is a finding.\n\nCheck to see if MarkLogic is configured to use External Security from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the click the Security icon in the left tree menu.\n2. Click the External Security icon.\n3. If no External Security Configuration Object exists, this is a finding.\n4. If at least one External Security Configuration Object exists, proceed to check all existing user accounts below.\n5. Click the Security icon in the left tree menu.\n6. Click the Users icon.\n7. Select the user to check. \n8. 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.\n9. Repeat for all users.","fixText":"If there are any accounts managed by MarkLogic, update the system documentation for justification and approval of these accounts.\n\nConfigure MarkLogic to use External Security from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Security icon in the left tree menu.\n2. Click the External Authentication icon.\n3. Click the Create tab at the top of the External Authentication Summary window.\n4. Complete the External Security Configuration Object for the available organization-level security provider.\n5. Click the Security icon in the left tree menu.\n6. Click the Users icon.\n7. Select the user to fix.\n8. In the User Configuration window, enter the external name for the user in the field in the External Name section.","ccis":["CCI-000015"]},{"vulnId":"V-220341","ruleId":"SV-220341r960792_rule","severity":"high","ruleTitle":"MarkLogic Server must enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.","description":"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. \n\nSuccessful 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. \n\nAccess 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. \n\nThis 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.\n\nMarkLogic 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.","checkContent":"Check MarkLogic settings to determine whether users are restricted from accessing objects and data they are not authorized to access.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click on the Security Icon.\n2. Click the Users Icon.\n3. Click on a User, and then click the Describe tab.\n4. Verify the User has the appropriate Roles assigned per organization/user requirements and system documentation.\n5. If the User is missing a required role or possesses a Role they do not require, this is a finding.\n6. Repeat for all added Users.","fixText":"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.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Security Icon.\n2. Click the Users Icon.\n3. Select one of the added Users with a misconfigured set of Security Roles.\n4. Either add or remove Security Role(s) as required per organization/user requirements and system documentation.\n5. Click OK.\n6. Repeat actions above for all misconfigured Users.","ccis":["CCI-000213"]},{"vulnId":"V-220342","ruleId":"SV-220342r960864_rule","severity":"medium","ruleTitle":"MarkLogic Server must protect against a user falsely repudiating having performed organization-defined actions.","description":"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. \n\nNon-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.\n\nIn 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.\n\nMarkLogic 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. \n\nMore information on auditing can be found here:\nhttps://docs.marklogic.com/guide/security/auditing","checkContent":"Review the configuration of audit logs to determine whether auditing includes details identifying the individual user. If it does not, this is a finding.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit-enabled field. A value of false means there is no auditing identifying the individual user and this is a finding. \n5. If audit enabled field is true, but the settings do not meet the DoD minimum requirements for non-repudiation, this is a finding.","fixText":"Configure MarkLogic audit logs to ensure auditing includes details identifying the individual user.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Configure the settings to meet DoD minimum requirements for protection against a user falsely repudiating.","ccis":["CCI-000166"]},{"vulnId":"V-220343","ruleId":"SV-220343r960879_rule","severity":"medium","ruleTitle":"MarkLogic Server must be configured to provide audit record generation capability for DoD-defined auditable events within all DBMS/database components.","description":"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. \n\nAudit 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.\n\nDoD has defined the list of events for which the DBMS will provide an audit record generation capability as the following: \n\n(i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n\n(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\n\n(iii) All account creation, modification, disabling, and termination actions.\n\nOrganizations may define additional events requiring continuous or ad hoc auditing.\n\nMarkLogic 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:\n- Startup and shutdown of MarkLogic Server\n- Adding or removing roles from a user\n- Usage of amps\n- Starting and stopping the auditing system\n\nFor the complete list of auditable events and their descriptions, see Auditing Events in the Administrator's Guide:\nhttps://docs.marklogic.com/guide/admin/auditing","checkContent":"Check DBMS auditing to determine whether organization-defined auditable events are being audited by the system.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means there is no auditing and this is a finding. \n5. If audit enabled field is true, but the selected auditable events do not meet DoD minimum requirements, this is a finding.","fixText":"Configure MarkLogic to generate audit records for at least the DoD minimum or organization-defined set of events.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Configure the auditable events to meet DoD minimum requirements.","ccis":["CCI-000169"]},{"vulnId":"V-220344","ruleId":"SV-220344r960882_rule","severity":"medium","ruleTitle":"MarkLogic Server must allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.","description":"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.\n\nSuppression of auditing could permit an adversary to evade detection.\n\nMisconfigured 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.\n\nMarkLogic 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:\n- Startup and shutdown of MarkLogic Server\n- Adding or removing roles from a user\n- Usage of amps\n- Starting and stopping the auditing system\n\nFor the complete list of auditable events and their descriptions, see Auditing Events in the Administrator's Guide:\nhttps://docs.marklogic.com/guide/admin/auditing","checkContent":"Check MarkLogic settings and documentation to determine whether designated personnel are able to select which auditable events are being audited.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Security icon.\n2. Click the Users icon on the left tree menu.\n3. Inspect the Roles assigned to the Users. If a User who is designated personnel does not have the admin role, this is a finding.\n4. Inspect the Roles assigned to the Users. If a User who is not designated personnel has the admin role, this is a finding.","fixText":"Configure the DBMS's settings to allow designated personnel to select which auditable events are audited.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Security icon.\n2. Click the Users icon on the left tree menu.\n3. Inspect the Roles assigned to the Users. For designated personnel, assign the admin role and change user roles as necessary.\n4. Inspect the Roles assigned to the Users. For non-designated personnel, remove the admin role and change user roles as necessary.","ccis":["CCI-000171"]},{"vulnId":"V-220345","ruleId":"SV-220345r960885_rule","severity":"medium","ruleTitle":"MarkLogic Server must be able to generate audit records when privileges/permissions are retrieved.","description":"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.\n\nThis 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.","checkContent":"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.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means there is no auditing and this is a finding. \n5. If audit enabled field is true, but the security-access audit event is not selected, this is a finding.\n6. 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.","fixText":"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.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the security-access audit event.\n6. Enable \"both\" under the outcome setting in the audit restrictions section.","ccis":["CCI-000172"]},{"vulnId":"V-220346","ruleId":"SV-220346r960885_rule","severity":"medium","ruleTitle":"MarkLogic Server must be able to generate audit records when unsuccessful attempts to retrieve privileges/permissions occur.","description":"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.\n\nThis 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.\n\nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.\n\nMarkLogic 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:\n- Startup and shutdown of MarkLogic Server\n- Adding or removing roles from a user\n- Usage of amps\n- Starting and stopping the auditing system\n\nFor the complete list of auditable events and their descriptions, see Auditing Events in the Administrator's Guide:\nhttps://docs.marklogic.com/guide/admin/auditing","checkContent":"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.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means there is no auditing and this is a finding. \n5. If audit enabled field is true, but the security-access audit event is not selected, this is a finding.\n6. 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.","fixText":"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.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the security-access audit event.\n6. Enable \"both\" under the outcome setting in the audit restrictions section.","ccis":["CCI-000172"]},{"vulnId":"V-220347","ruleId":"SV-220347r960888_rule","severity":"medium","ruleTitle":"MarkLogic Server must initiate session auditing upon startup.","description":"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.","checkContent":"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.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field, a value of false means there is no auditing, this is a finding.","fixText":"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.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.","ccis":["CCI-001464"]},{"vulnId":"V-220348","ruleId":"SV-220348r960915_rule","severity":"medium","ruleTitle":"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.","description":"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. \n\nWhen 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.\n\nSystems 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.","checkContent":"If the application owner has determined the need for system availability outweighs the need for a complete audit trail, this is not applicable.\n\nIf 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.\n\nThe following are the minimum configuration requirements for HA:\n- Failover enabled = True for the Group\n- Security database forests are configured with replica forests\n- Databases associated with the users application are configured with replica forests\n\nIf HA is a requirement for Administrative functions:\n- App Services database forests are configured with replica forests\n- Modules database forests are configured with replica forests \n- Documents database forests are configured with replica forests\n- Triggers database forests are configured with replica forests\n\nPerform the check for HA from the MarkLogic Admin Interface with a user that holds administrative-level privileges: \n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. On the Configuration tab, check the value of \"failover enabled\".\nTrue = HA can be enabled\nFalse = HA cannot be enabled\n4. Click the Databases icon in the left tree menu.\n5. Click the Security Database.\n6. Click the Status Tab.\n7. Review the Forest section:\na. Count the number of forests with a state of \"open\".\nb. Count the number of forests with a state of \"[sync|async|wait] replicating\".\nc. The number of replicating forests should be greater than or equal to the number of open forests.\n8. Repeat steps 4-7 for the user application databases (data/content, modules, triggers, etc.).\n9. Repeat steps 4-7 for the following databases if HA is required for Administrative functions:\n- App Services\n- Modules\n- Documents\n- Triggers","fixText":"Configure the database to go offline, rolling back all in-flight transactions, in the case of an auditing failure due to insufficient disk space.\n\nPerform the fix from the MarkLogic Admin Interface with a user that holds administrative-level privileges: \n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. On the Configuration tab set the value of \"failover enabled\" to \"false\".\n4. Click OK to save the configuration.","ccis":["CCI-000140"]},{"vulnId":"V-220349","ruleId":"SV-220349r960930_rule","severity":"medium","ruleTitle":"The audit information produced by MarkLogic Server must be protected from unauthorized read access.","description":"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.\n\nTo 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.\n\nThis 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. \n\nAdditionally, 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.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.\n\nWhen 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:\n- Writes messages to AuditLog.txt file for various events.\n- 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.\n- How often to rotate the audit files (similar to the log files, as described in Log Files) can be configured.\n- 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 <marklogic-data-dir>/Logs directory. These files are private to the host in which the audit event occurred.\n- 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.","checkContent":"Review controls and permissions are sufficient to protect audit log files from unauthorized access at the operating-system level.\n\nVerify User ownership, Group ownership, and permissions on the \"audit\" file:\n> ls -al /var/opt/MarkLogic/Logs/AuditLog.txt\n\nIf the User owner is not \"daemon\", this is a finding\nIf the Group owner is not \"daemon\", this is a finding.\nIf the directory is more permissive than 700, this is a finding.","fixText":"Apply controls and modify permissions to protect audit log files from unauthorized access at the operating-system level.\n\nChange owner and group of /var/opt/MarkLogic/Logs to user daemon from the command line with a privileged user:\n> chown daemon.daemon /var/opt/MarkLogic/Logs\n\nChange permissions of /var/opt/MarkLogic/Logs to 700 (rwx by owner only) from the command line\n> chmod 700 /var/opt/MarkLogic/Logs","ccis":["CCI-000162"]},{"vulnId":"V-220350","ruleId":"SV-220350r960933_rule","severity":"medium","ruleTitle":"The audit information produced by MarkLogic Server must be protected from unauthorized modification.","description":"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. \n\nTo ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized modification. \n\nThis 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. \n\nApplications 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.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. \n\nModification of database audit data could mask the theft of, or the unauthorized modification of, sensitive data stored in the database.\n\nWhen 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:\n- Writes messages to AuditLog.txt file for various events.\n- 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.\n- How often to rotate the audit files (similar to the log files, as described in Log Files) can be configured.\n- 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 <marklogic-data-dir>/Logs directory. These files are private to the host in which the audit event occurred.\n- 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.","checkContent":"Review controls and permissions are sufficient to protect audit log files from unauthorized access at the operating-system level.\n\nVerify User ownership, Group ownership, and permissions on the \"audit\" file:\n> ls -al /var/opt/MarkLogic/Logs/AuditLog.txt\n\nIf the User owner is not \"daemon\", this is a finding\nIf the Group owner is not \"daemon\", this is a finding.\nIf the directory is more permissive than 700, this is a finding.","fixText":"Apply controls and modify permissions to protect audit log files from unauthorized access at the operating-system level.\n\nChange owner and group of /var/opt/MarkLogic/Logs to user daemon from the command line with a privileged user:\n> chown daemon.daemon /var/opt/MarkLogic/Logs\n\nChange permissions of /var/opt/MarkLogic/Logs to 700 (rwx by owner only) from the command line\n> chmod 700 /var/opt/MarkLogic/Logs","ccis":["CCI-000163"]},{"vulnId":"V-220351","ruleId":"SV-220351r960936_rule","severity":"medium","ruleTitle":"The audit information produced by MarkLogic Server must be protected from unauthorized deletion.","description":"If audit data becomes compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve.\n\nTo 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.\n\nSome 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.\n\nApplications 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.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.\n\nWhen 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:\n- Writes messages to AuditLog.txt file for various events.\n- 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.\n- How often to rotate the audit files (similar to the log files, as described in Log Files) can be configured.\n- 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 <marklogic-data-dir>/Logs directory. These files are private to the host in which the audit event occurred.\n- 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.\n\nDeletion of database audit data could mask the theft of, or the unauthorized modification of, sensitive data stored in the database.","checkContent":"Review controls and permissions are sufficient to protect audit log files from unauthorized access at the operating-system level.\n\nVerify User ownership, Group ownership, and permissions on the \"audit\" file:\n> ls -al /var/opt/MarkLogic/Logs/AuditLog.txt\n\nIf the User owner is not \"daemon\", this is a finding\nIf the Group owner is not \"daemon\", this is a finding.\nIf the directory is more permissive than 700, this is a finding.","fixText":"Apply controls and modify permissions to protect audit log files from unauthorized access at the operating-system level.\n\nChange owner and group of /var/opt/MarkLogic/Logs to user daemon from the command line with a privileged user:\n> chown daemon.daemon /var/opt/MarkLogic/Logs\n\nChange permissions of /var/opt/MarkLogic/Logs to 700 (rwx by owner only) from the command line\n> chmod 700 /var/opt/MarkLogic/Logs","ccis":["CCI-000164"]},{"vulnId":"V-220352","ruleId":"SV-220352r960939_rule","severity":"medium","ruleTitle":"MarkLogic Server must protect its audit features from unauthorized access.","description":"Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. \n\nDepending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. Access to audit tools must be controlled and protected from unauthorized access. \n\nApplications 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.\n\nAudit 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. \n\nIf 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.\n\nWhen 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:\n- Writes messages to AuditLog.txt file for various events.\n- 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.\n- How often to rotate the audit files (similar to the log files, as described in Log Files) can be configured.\n- 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 <marklogic-data-dir>/Logs directory. These files are private to the host in which the audit event occurred.\n- 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.","checkContent":"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.\n\nAlternatively, 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.\n\nIf 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.\n\nPerform the check from the MarkLogic Admin Interface with a user that holds administrative-level privileges.\n1. Click the Clusters icon on the left tree menu.\n2. Click the Keystore tab.\n3. If \"logs encryption\" is set to \"off\", this is a finding.","fixText":"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.\n\nAlternatively, Encryption-at-Rest for system logs may be enabled to prevent unauthorized disclosure of contained information. \n\nPerform the fix from the MarkLogic Admin Interface with a user that holds administrative-level privileges.\n1. Click the Clusters icon on the left tree menu.\n2. Click the Keystore tab.\n3. Change \"logs encryption\" setting to \"on\".","ccis":["CCI-001493"]},{"vulnId":"V-220353","ruleId":"SV-220353r960942_rule","severity":"medium","ruleTitle":"MarkLogic Server must protect its audit configuration from unauthorized modification.","description":"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.\n\nApplications 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.\n\nAudit 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.","checkContent":"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.\n\nAlternatively, 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.\n\nIf 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.\n\nPerform the check from the MarkLogic Admin Interface with a user that holds administrative-level privileges.\n1. Click the Clusters icon on the left tree menu.\n2. Click the Keystore tab.\n3. If \"logs encryption\" is set to \"off\", this is a finding.","fixText":"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.\n\nAlternatively, Encryption-at-Rest for system logs may be enabled to prevent unauthorized disclosure of contained information. \n\nPerform the fix from the MarkLogic Admin Interface with a user that holds administrative-level privileges.\n1. Click the Clusters icon on the left tree menu.\n2. Click the Keystore tab.\n3. Change \"logs encryption\" setting to \"on\".","ccis":["CCI-001494"]},{"vulnId":"V-220354","ruleId":"SV-220354r960945_rule","severity":"medium","ruleTitle":"MarkLogic Server must protect its audit features from unauthorized removal.","description":"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.\n\nApplications 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.\n\nAudit 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.","checkContent":"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.\n\nAlternatively, 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.\n\nIf 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.\n\nPerform the check from the MarkLogic Admin Interface with a user that holds administrative-level privileges.\n1. Click the Clusters icon on the left tree menu.\n2. Click the Keystore tab.\n3. If \"logs encryption\" is set to \"off\", this is a finding.","fixText":"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.\n\nAlternatively, Encryption-at-Rest for system logs may be enabled to prevent unauthorized disclosure of contained information. \n\nPerform the fix from the MarkLogic Admin Interface with a user that holds administrative-level privileges.\n1. Click the Clusters icon on the left tree menu.\n2. Click the Keystore tab.\n3. Change \"logs encryption\" setting to \"on\".","ccis":["CCI-001495"]},{"vulnId":"V-220355","ruleId":"SV-220355r960960_rule","severity":"medium","ruleTitle":"MarkLogic Server must limit privileges to change software modules, including stored procedures, functions, and triggers, and links to software external to the DBMS.","description":"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.\n\nAccordingly, only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to the database software libraries or configuration can lead to unauthorized or compromised installations.","checkContent":"Review monitoring procedures and implementation evidence to verify monitoring of changes to MarkLogic software libraries, related applications, and configuration files is done.\n\nIf a third-party file automated tool is used, this is not a finding.\n\nTo check for automated monitoring, issue the following command at a command prompt with a user that has administrative privileges:\n\nCheck to see if the crond service is running for scheduling recurring tasks. \n\nIf it is not running, this is a finding.\n> sudo systemctl status crond\n\nCheck 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.\n> sudo crontab -l | grep ml-filechange\n\nCheck 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.\n> grep \"EMAIL_LIST\" /path/to/ml-filechange-mon.sh","fixText":"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. \n\nThe supplemental file \"ml-filechange-mon.sh\" can be used to meet this requirement. \n- Edit the ml-filechange-mon.sh script with the correct email addresses and notification level.\n- Place the script in a location that can be accessed by the cron daemon.\n- Edit the crontab, and configure the script to run frequently enough to meet DoD minimum requirements.","ccis":["CCI-001499"]},{"vulnId":"V-220356","ruleId":"SV-220356r960960_rule","severity":"medium","ruleTitle":"MarkLogic Server software installation account must be restricted to authorized users.","description":"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. \n\nIf 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.\n\nAccordingly, only qualified and authorized individuals must be allowed access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nDBA 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.","checkContent":"Review procedures for controlling, granting access to, and tracking use of the MarkLogic software installation account.\n\nIf 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.\n\nAt a command prompt, on the system where MarkLogic is installed run the following command:\n> ls -al /var/opt/MarkLogic \n\nIf files are owned by the user \"daemon\", this is not a finding.\n\nIf user is not \"daemon\", verify that Organization policy and system documentation states that a separate user is needed and approved.","fixText":"Review procedures for controlling, granting access to, and tracking the use of the MarkLogic software installation account.\n\nEnsure use of this account is restricted to the minimum number of personnel required and no unauthorized access to the account has been granted.\n\nMarkLogic 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:\n> sudo yum install /path/to/MarkLogic-version.rpm \nor\n> sudo rpm -i /path/to/MarkLogic-version.rpm\n\nEither of these commands will install MarkLogic with the owner set correctly to \"daemon\".\n\nIf user is not \"daemon\", ensure Organization policy and system documentation states that a separate user is needed and approved.","ccis":["CCI-001499"]},{"vulnId":"V-220357","ruleId":"SV-220357r960960_rule","severity":"medium","ruleTitle":"MarkLogic Server software, including configuration files, must be stored in dedicated directories, or DASD pools, separate from the host OS and other applications.","description":"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.\n\nMultiple 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.","checkContent":"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.\n\nIf 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.\n\nAt a command prompt on the MarkLogic system, run the following commands:\n> ls /opt/MarkLogic\n\nIf any directories exist that are not in the list below, this is a finding.\nAdmin bin FlexRep include Lang Messages \nApps Config HealthCheck Installer mlcmd Plugins\nAssets Converters java lib Modules Samples\n\nAt a command prompt on the MarkLogic system, run the following commands:\n> ls /var/opt/MarkLogic\n\nIf any directories exist that are not in the list below, this is a finding.\nkms Lib run Stage\nForests Journals Label Logs Temp\n\nIf other software is installed in those directories and is not approved by Org Policy, this is a finding.","fixText":"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.\n\nRemove any other applications, including third-party applications that use MarkLogic that are not approved by Org Policy.\n\nAt a command prompt on the MarkLogic system, run the following commands:\nIf the software was installed via yum/rpm\n> sudo yum remove [Software-Package-Name]\nIf the software was installed via unzip/untar.\n> sudo rm -r [/path/to/unauthorized/software]","ccis":["CCI-001499"]},{"vulnId":"V-220358","ruleId":"SV-220358r960960_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nConversely, if critical tables or other objects rely on unauthorized owner accounts, these objects may be lost when an account is removed.","checkContent":"Review system documentation to identify accounts authorized to own database objects. Review accounts that own objects in the database(s).\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Security icon.\n2. Click the Users icon on the left tree menu.\n3. Inspect the Users. If there is a User who is not authorized to own database objects, this is a finding.","fixText":"Assign ownership of authorized objects to authorized object owner accounts.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Security icon.\n2. Click the Users icon on the left tree menu.\n3. Inspect the Users. For users who are not authorized to own database objects, remove the users.","ccis":["CCI-001499"]},{"vulnId":"V-220359","ruleId":"SV-220359r960960_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nAccordingly, only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to the database software libraries or configuration can lead to unauthorized or compromised installations.","checkContent":"Identify the group(s)/role(s) established for MarkLogic modification and the list of users in those group(s)/roles.\n\nIdentify the individuals authorized to modify the DBMS.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Security icon.\n2. Click the Users icon on the left tree menu.\n3. Inspect the Users. If there is a User who is not authorized to own database objects, this is a finding.","fixText":"Revoke unauthorized memberships in the MarkLogic modification group(s)/role(s).\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Security icon.\n2. Click the Users icon on the left tree menu.\n3. Inspect the Users. For users who are not authorized to own database objects, remove the users.","ccis":["CCI-001499"]},{"vulnId":"V-220360","ruleId":"SV-220360r960963_rule","severity":"medium","ruleTitle":"Unused database components, DBMS software, and database objects must be removed.","description":"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).\n\nIt is detrimental for software products to provide, or install by default, functionality exceeding requirements or mission objectives. \n\nDBMSs must adhere to the principles of least functionality by providing only essential capabilities.","checkContent":"Review the list of components and features installed with MarkLogic, and check for unused components or features.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Databases icon.\n2. Inspect the list of databases. If there is an unused database, this is a finding.\n3. Click the Forests icon.\n4. Inspect the list of forests. If there is an unused forest, this is a finding.\n5. Click the Groups >> [GroupName] >> App Servers \n6. Inspect the list of app servers. If there is an unused database, this is a finding.","fixText":"Remove any database objects and applications that are installed to support them.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Databases icon.\n2. Inspect the list of databases and select an unused database.\n3. Click Delete and confirm the deletion.\n4. Click the Forests icon.\n5. Inspect the list of forests and select an unused forest.\n6. Click Delete and confirm the deletion.\n7. Click the Groups >> [GroupName] >> App Servers. \n8. Inspect the list of app servers and select an unused app server.\n9. Click Delete and confirm the deletion.","ccis":["CCI-000381"]},{"vulnId":"V-220361","ruleId":"SV-220361r960963_rule","severity":"medium","ruleTitle":"Access to external executables must be disabled or restricted.","description":"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). \n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. \n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nDBMSs 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.","checkContent":"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.\n\nIf it is not, this is a finding.\n\nTo check for Converters, issue the following command at a command prompt with a user that has administrative privileges.\n> sudo yum info MarkLogicConverters\n\nIf the command returns information on the version of MarkLogic converters installed, and use of this package has not been authorized, this is a finding.\n\nTo check for MLSQL/odbc client, issue the following command at a command prompt with a user that has administrative privileges.\n> sudo yum info mlsqlodbc\n\nIf 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.","fixText":"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.\n\nTo remove Converters, issue the following command at a command prompt with a user that has administrative privileges.\n> sudo yum remove MarkLogicConverters\n\nTo remove MLSQL/odbc client, issue the following command at a command prompt with a user that has administrative privileges.\n> sudo yum info mlsqlodbc","ccis":["CCI-000381"]},{"vulnId":"V-220362","ruleId":"SV-220362r960966_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nApplications 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. \n\nTo 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.\n\nDatabase 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.","checkContent":"Review the DBMS settings and local documentation for functions, ports, protocols, and services that are approved. \n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the App Server to check resides (e.g., Default).\n3. Click the App Servers icon on the left tree menu.\n4. Inspect the list of App Servers and associated Protocols and Ports.\n5. If any App Server has an associated protocol or port that is not approved, this is a finding.","fixText":"Disable functions, ports, protocols, and services that are not approved.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the App Server to check resides (e.g., Default).\n3. Click the App Servers icon on the left tree menu.\n4. Inspect the list of App Servers and associated Protocols and Ports.\n5. 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\".","ccis":["CCI-000382"]},{"vulnId":"V-220363","ruleId":"SV-220363r960969_rule","severity":"medium","ruleTitle":"MarkLogic Server must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).","description":"To ensure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of the system. \n\nOrganizational 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:\n\n(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 \n(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.","checkContent":"Review DBMS settings to determine whether organizational users are uniquely identified and authenticated when logging on/connecting to the system.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the App Server to be checked resides (e.g., Default).\n3. Click the App Servers icon on the left tree menu.\n4. Select each of the App Servers.\n5. 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.","fixText":"Configure MarkLogic settings to uniquely identify and authenticate all organizational users who log on/connect to the system.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the App Server to be checked resides (e.g., Default).\n3. Click the App Servers icon on the left tree menu.\n4. Select each of the App Servers.\n5. 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\".","ccis":["CCI-000764"]},{"vulnId":"V-220364","ruleId":"SV-220364r1018604_rule","severity":"medium","ruleTitle":"If MarkLogic Server authentication using passwords is employed, MarkLogic Server must enforce the DOD standards for password complexity and lifetime.","description":"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.\n\nThe 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.\n\nIn 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.\n\nTypes of Authentication\nControl the authentication scheme for HTTP, WebDAV, ODBC, and XDBC App Servers.\n- 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.\n- 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.\n- 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.\n- 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.\n- 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.\n- In Kerberos Ticket, the user is authenticated by Kerberos and a Kerberos session ticket is used to authenticate the user to access MarkLogic Server.\n- 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.","checkContent":"Review MarkLogic settings to see if password authentication is being used, and whether password complexity and lifetime rules are being enforced.\n\nCheck for MarkLogic Password Plugin from the MarkLogic Query Console with a user that holds administrative-level privileges.\n1. Select \"XQuery\" in the Query Type drop down and copy the following code into the window:\nxquery version \"1.0-ml\"; \nimport module namespace plugin = \"http://marklogic.com/extension/plugin\" at \"/MarkLogic/plugin/plugin.xqy\";\n\nplugin:plugins(\"http://marklogic.com/xdmp/security/password-check\")\n2. Run the script. If the script returns \"your query returned an empty sequence\", then no password plugin is present.\n3. 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.\n4. Log in to the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n5. Click the Groups icon.\n6. Click the group in which the App Server to be checked resides (e.g., Default).\n7. Click the App Servers icon on the left tree menu.\n8. Select each of the App Servers.\n9. 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.","fixText":"If the use of passwords is not needed, configure MarkLogic to prevent password use.\n\nIf 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: \n1. Configure the MarkLogic server to use Kerberos, SAML, or Certificate based authentication. \n2. Develop plugin to enforce password complexity. Examples can be found in MarkLogic Application Developers Guide.\n\nPlugins must enforce the following rules for passwords:\n\na. minimum of 15 characters, including at least one of each of the following character sets:\n- Uppercase\n- Lowercase\n- Numeric\n- Special characters (e.g., ~ ! @ # $ % ^ & * ( ) _ + = - ' [ ] / ? > <)\nb. Minimum number of characters changed from previous password: 50 percent of the minimum password length (eight)\nc. Password lifetime limits for interactive accounts: Minimum 24 hours, maximum 60 days\nd. Password lifetime limits for non-interactive accounts: Minimum 24 hours, maximum 365 days\ne. Number of password changes before an old one may be reused: Minimum of five\n\nDevelop a custom extension that enforces the password complexity and lifetime.\nSee https://docs.marklogic.com/guide/app-dev/plugins#id_91783","ccis":["CCI-004066","CCI-000192"]},{"vulnId":"V-220365","ruleId":"SV-220365r961029_rule","severity":"high","ruleTitle":"If passwords are used for authentication, the MarkLogic Server must transmit only encrypted representations of passwords.","description":"The DoD standard for authentication is DoD-approved PKI certificates.\n\nAuthentication based on User ID and Password may be used only when it is not possible to employ a PKI certificate, and requires AO approval.\n\nIn such cases, passwords must be protected at all times, and encryption is the standard method for protecting passwords during transmission.\n\nDBMS 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.\n\nMarkLogic Types of Authentication:\nBasic*\nDigest\nDigest-Basic*\nCertificate\nApplication Level\nKerberos Ticket\nSAML\n* Indicates that the authentication method allows the username and password to be transmitted in clear text.\n\nFor more information on the types of authentication MarkLogic offers, follow this link:\nhttps://docs.marklogic.com/9.0/guide/security/authentication#id_14250","checkContent":"Review MarkLogic configuration settings for encrypting passwords in transit across the network.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the App Server to be checked resides (e.g., Default).\n3. Click the App Servers icon on the left tree menu.\n4. Select each of the App Servers.\n5. Inspect the selected authentication method, if \"basic\" or \"digest-basic\" is selected, this is a finding.\n\nIf Application Level is selected and the application server is not configured for SSL, this is a finding","fixText":"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. \n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the App Server to be checked resides (e.g., Default).\n3. Click the App Servers icon on the left tree menu.\n4. Select each of the App Servers.\n5. Inspect the selected authentication method, if \"basic\" or \"digest-basic\" is selected, change the authentication method to something other than those two.\n\nIf Application Level is selected, ensure the application server is configured for SSL.","ccis":["CCI-000197"]},{"vulnId":"V-220366","ruleId":"SV-220366r961038_rule","severity":"medium","ruleTitle":"MarkLogic Server, when utilizing PKI-based authentication, must validate certificates by performing RFC 5280-compliant certification path validation.","description":"The DoD standard for authentication is DoD-approved PKI certificates.\n\nA 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.\n\nDatabase 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.","checkContent":"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.\n\nTo check for existing CRLs, use the MarkLogic QConsole and execute the following XQuery command against the Security Database:\n\ncts:uri-match(\"http://marklogic.com/xdmp/pki/crls/*\")\n\nIf there are CRLs, then it will return which CRLs are loaded, if not then it will return an empty sequence.\n\nIf any required CRLs are missing, this is a finding.","fixText":"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.\n\nUse one of the following two methods to add a CRL to MarkLogic:\n\nOption 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)\nUsing a compatible HTTP request generator (i.e., Postman or curl) construct an HTTP PUT request:\nEXAMPLE:\n curl -X PUT --anyauth --user admin:admin --header \"Content-Type:text/html\" \\\n -d \"http://crl.verisign.com/pca3.crl\" \\\n http://localhost:8002/manage/v2/certificate-revocation-lists?url=url\nNOTE: 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.\n\nOption 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)\nEXAMPLE:\nxquery version \"1.0-ml\"; \nimport module namespace pki = \"http://marklogic.com/xdmp/pki\" at \"/MarkLogic/pki.xqy\";\nlet $URI := \"http://crl.verisign.com/pca3.crl\"\n return\n pki:insert-certificate-revocation-list(\n $URI, \n xdmp:document-get($URI)/binary() )","ccis":["CCI-000185"]},{"vulnId":"V-220367","ruleId":"SV-220367r961041_rule","severity":"high","ruleTitle":"MarkLogic Server must enforce authorized access to all PKI private keys stored/utilized by the DBMS.","description":"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.\n\nIf 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.\n\nBoth 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.\n\nAll 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.","checkContent":"Review MarkLogic configuration to determine whether SSL FIPS has been enabled.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Clusters icon on the left tree menu.\n2. Select the local cluster. Click the Configure tab and verify \"ssl fips enabled\" is set to true. If not, this is a finding.","fixText":"Ensure SSL FIPS has been enabled in MarkLogic server.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Clusters icon on the left tree menu.\n2. Select the local cluster. Click the Configure tab.\n3. Set the \"ssl fips enabled\" setting to true and click \"ok\".","ccis":["CCI-000186"]},{"vulnId":"V-220368","ruleId":"SV-220368r961050_rule","severity":"high","ruleTitle":"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.","description":"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.\n\nApplications, 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. \n\nNSA Type-X (where X=1, 2, 3, 4) products are NSA-certified, hardware-based encryption modules.\n\nThe standard for validating cryptographic modules will transition to the NIST FIPS 140-3 publication.\n\nFIPS 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:\nhttps://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules\n\nMore information on the FIPS 140-3 transition can be found here: \nhttps://csrc.nist.gov/Projects/fips-140-3-transition-effort/\n\nSatisfies: SRG-APP-000179-DB-000114, SRG-APP-000416-DB-000380","checkContent":"Review MarkLogic configuration to determine whether SSL FIPS has been enabled.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Clusters icon.\n2. In the Summary tab, if the value for \"ssl fips enabled\" is \"false\", this is a finding.","fixText":"Ensure SSL FIPS has been enabled in MarkLogic server.\n\nPerform the fix operation from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Clusters icon.\n2. Click the Configure tab.\n3. Set the value for \"ssl fips enabled\" to \"true\" and click OK.","ccis":["CCI-000803","CCI-002450"]},{"vulnId":"V-220369","ruleId":"SV-220369r961053_rule","severity":"medium","ruleTitle":"MarkLogic Server must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).","description":"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). \n\nNon-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. \n\nAccordingly, a risk assessment is used in determining the authentication needs of the organization. \n\nScalability, 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.","checkContent":"Review MarkLogic settings to determine if non-organizational users are uniquely identified and authenticated.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Security icon.\n2. Click the Users icon on the left tree menu.\n3. Inspect the Users; if there is a non-organizational user who is not uniquely identified, this is a finding.","fixText":"If non-organizational users are not uniquely identified and authenticated, implement the steps below.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Security icon.\n2. Click the Users icon on the left tree menu.\n3. Inspect the Users, and remove any non-organizational users who are not uniquely identified.","ccis":["CCI-000804"]},{"vulnId":"V-220370","ruleId":"SV-220370r961095_rule","severity":"medium","ruleTitle":"MarkLogic Server must separate user functionality (including user interface services) from database management functionality.","description":"Information system management functionality includes functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. \n\nThe 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. \n\nAn 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. \n\nThis may include isolating the administrative interface on a different domain and with additional access controls.\n\nIf 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.","checkContent":"Validate MarkLogic User accounts to verify only Administrators have Administrative roles assigned and each Administrator has an individual account.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Security icon.\n2. Click the Users icon on the left tree menu.\n3. Inspect the Users. If administrator and general user accounts are not separated, this is a finding.","fixText":"Configure MarkLogic user roles so that only actual Administrators are assigned Administrative roles and each Administrator has an individual account.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Security icon.\n2. Click the Users icon on the left tree menu.\n3. Inspect the Users.\n4. Remove administrative privileges from general user accounts, and ensure administrators have separate administrative accounts.","ccis":["CCI-001082"]},{"vulnId":"V-220371","ruleId":"SV-220371r961119_rule","severity":"medium","ruleTitle":"MarkLogic Server must maintain the authenticity of communications sessions by guarding against man-in-the-middle attacks that guess at Session ID values.","description":"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.\n\nThe 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.\n\nHowever, 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.\n\nMarkLogic Server uses OpenSSL to implement the Secure Sockets Layer (SSL v3) and Transport Layer Security (TLS v1) protocols.","checkContent":"Review MarkLogic settings to determine whether protections against man-in-the-middle attacks that guess at session identifier values are enabled.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the App Server to check resides (e.g., Default).\n3. Click the App Servers icon on the left tree menu.\n4. If any of the application servers has a \"no\" under the SSL column, this is a finding.","fixText":"Configure MarkLogic settings to enable protections against man-in-the-middle attacks that guess at session identifier values.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\nSee: https://docs.marklogic.com/guide/security/SSL\n\n1. Click the Groups icon.\n2. Click the group in which the App Server to check resides (e.g., Default).\n3. Click the App Servers icon on the left tree menu.\n4. 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.","ccis":["CCI-001188"]},{"vulnId":"V-220372","ruleId":"SV-220372r961128_rule","severity":"high","ruleTitle":"MarkLogic Server must protect the confidentiality and integrity of all information at rest.","description":"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. \n\nUser 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. \n\nIf the confidentiality and integrity of application data is not protected, the data will be open to compromise and unauthorized modification.\n\nEncryption 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.\n\nEncryption 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.\n\nMore information can be found here:\nhttps://docs.marklogic.com/guide/security/encryption","checkContent":"If the application owner and Authorizing Official have determined that encryption of data at rest is NOT required, this is not a finding.\n\nIf full-disk encryption is being used, this is not a finding. \n\nReview 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.\n\nReview MarkLogic settings to determine whether controls exist to protect the confidentiality and integrity of data at rest in the database.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Databases icon.\n2. Click the database to be checked.\n3. If the \"data encryption\" drop-down is set to ON, this is not a finding, and no further checks need to be performed.\n4. If the \"data encryption\" drop-down is set to OFF, continue the check.\n5. If the \"data encryption\" drop-down is set to default-cluster, continue the check with the steps below:\na. Click the Clusters icon.\nb. Click [Cluster Name].\nc. Click the Keystore Tab.\nd. If the Cluster Default Encryption configuration is OFF, this is a finding.\n\nFindings Matrix\n-------------------------------------------------------\nDatabase Cfg. | Cluster Cfg | Finding\n--------------------------------------------------------\nON | *Any* | No\n*Any* | Force | No\nDefault-cluster | Default-on | No\nDefault-cluster | Default-off | Yes\nOff | Default-on | Yes\nOff | Default-off | Yes","fixText":"Apply appropriate controls to protect the confidentiality and integrity of data at rest in the database.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Databases icon.\n2. Click the database to be fixed.\n3. Select ON from the data encryption drop-down.","ccis":["CCI-001199"]},{"vulnId":"V-220373","ruleId":"SV-220373r961149_rule","severity":"medium","ruleTitle":"Access to MarkLogic Server files must be limited to relevant processes and to authorized, administrative users.","description":"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.\n\nEncryption 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.\n\nEncryption 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.\n\nFor more information:\nSee: https://docs.marklogic.com/guide/security/encryption","checkContent":"If the application owner and Authorizing Official have determined that encryption of data at rest is NOT required, this is not a finding.\n\nIf full-disk encryption is being used, this is not a finding.\n\nReview 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.\n\nReview MarkLogic settings to determine whether controls exist to protect the confidentiality and integrity of data at rest in the database.\n\nFrom a command line at the OS level, verify User ownership, Group ownership, and permissions on the files:\n> ls -al /var/opt/MarkLogic/\n\nIf the User owner is not \"daemon\", and encryption at rest is not enabled, this is a finding.\n\nIf the Group owner is not \"daemon\", and encryption at rest is not enabled, this is a finding.\n\nIf the directory is more permissive than 750, and encryption at rest is not enabled, this is a finding.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Databases icon.\n2. Click the database to be checked.\n3. If the \"data encryption\" drop-down is set to ON, this is not a finding, and no further checks need to be performed.\n4. If the \"data encryption\" drop-down is set to OFF, continue the check.\n5. If the \"data encryption\" drop-down is set to default-cluster, continue the check with the steps below:\na. Click the Clusters icon.\nb. Click [Cluster Name].\nc. Click the Configure Tab.\nd. If the Cluster Default Encryption configuration is OFF, this is a finding.\n\nFindings Matrix\n-------------------------------------------------------\nDatabase Cfg. | Cluster Cfg | Finding\n--------------------------------------------------------\nON | *Any* | No\n*Any* | Force | No\nDefault-cluster | Default-on | No\nDefault-cluster | Default-off | Yes\nOff | Default-on | Yes\nOff | Default-off | Yes","fixText":"Apply appropriate controls to protect the confidentiality and integrity of data at rest in the database.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Databases icon.\n2. Click the database to be fixed.\n3. Select ON from the data encryption drop-down.\n\nOR\n\nChange owner and group of /var/opt/MarkLogic to user daemon from the command line with a privileged user:\n> chown -R daemon.daemon /var/opt/MarkLogic\n\nChange permissions of /var/opt/MarkLogic to 750 (rwx by owner only) from the command line\n> chmod 750 /var/opt/MarkLogic","ccis":["CCI-001090"]},{"vulnId":"V-220374","ruleId":"SV-220374r961167_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nDatabases 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.\n\nCarefully 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.\n\nThis 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.","checkContent":"Check MarkLogic settings and custom database code to verify that error messages do not contain information beyond what is needed for troubleshooting the issue.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group that is to be checked.\n3. Check settings for \"file log level\" and \"system log level\".\n\nIf \"file log level\" is set to \"debug\", \"finer\", or \"finest\", this is a finding.\n\nIf \"system log level\" is set to \"debug\", \"finer\", or \"finest\", this is a finding.","fixText":"Configure MarkLogic log settings not to divulge sensitive information or information useful for system identification in error messages.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group that is to be fixed.\n3. Set the \"system log level\" to \"notice\" and the \"file log level\" to \"info\".","ccis":["CCI-001312"]},{"vulnId":"V-220375","ruleId":"SV-220375r961272_rule","severity":"medium","ruleTitle":"MarkLogic Server must associate organization-defined types of security labels having organization-defined security label values with information in process.","description":"Without the association of security labels to information, there is no basis for the DBMS to make security-related access-control decisions.\n\nSecurity labels are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. \n\nThese 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. \n\nOne 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.\n\nThe mechanism used to support security labeling may be a feature of the DBMS product, a third-party product, or custom application code.","checkContent":"MarkLogic supports role-based access control for all entities/documents maintained within the database. User roles and applied document permissions determine access.\n\nFor 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.\n\nAdding 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.\n\n1. Verify applicable roles are configured with the necessary access Compartments for the specified role.\n2. Verify all documents inserted into the MarkLogic database have the applicable permission (Compartment) applied.\n\nIf applicable roles do not have Compartments defined, this is a finding.\n\nIf documents inserted into the database do not have the applicable document permissions (Compartments) applied, this is a finding.\n\nAdditionally, 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.\n\nElement 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.\n\nWhen/where applicable:\n1. Navigate to the MarkLogic Admin page >> Security >> Protected Paths.\n2. Verify the applicable elements requiring additional protections are defined using an XQuery path expression (applicable for both XML and JSON document types).\n3. Verify the applicable role(s) are added against the specified path expression.\n\nIf specific document elements require additional protections and no Protected Paths or Protect Path roles are defined, this is a finding.","fixText":"See specific MarkLogic documentation regarding Compartment level security for necessary steps.\n\nApplying Document Compartment Security:\n1. Navigate to the MarkLogic Admin page >> Security >> Roles.\n2. Create a new role and assign applicable roles/permissions.\n3. Provide a Compartment name to the role.\n4. Ensure all data ingestion mechanisms (i.e., document insertion code/logic) apply the necessary applicable security permissions.\n\nApplying Element-Level Security:\n1. Navigate to the MarkLogic Admin page >> Security >> Protected Paths.\n2. Create a Protected Path by specifying an XQuery path expression identifying the element requiring specific protections.\n3. Add one or more applicable roles, specify their capability, and then save the configuration.\n4. Repeat step 3 for each element requiring additional protections.","ccis":["CCI-002263"]},{"vulnId":"V-220376","ruleId":"SV-220376r961275_rule","severity":"medium","ruleTitle":"MarkLogic Server must associate organization-defined types of security labels having organization-defined security label values with information in transmission.","description":"Without the association of security labels to information, there is no basis for the DBMS to make security-related access-control decisions.\n\nSecurity labels are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. \n\nThese 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. \n\nOne 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.\n\nThe mechanism used to support security labeling may be a feature of the DBMS product, a third-party product, or custom application code.","checkContent":"MarkLogic supports role-based access control for all entities/documents maintained within the database. User roles and applied document permissions determine access.\n\nFor 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.\n\nAdding 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.\n\n1. Verify applicable roles are configured with the necessary access Compartments for the specified role.\n2. Verify all documents inserted into the MarkLogic database have the applicable permission (Compartment) applied.\n\nIf applicable roles do not have Compartments defined, this is a finding.\n\nIf documents inserted into the database do not have the applicable document permissions (Compartments) applied, this is a finding.\n\nAdditionally, 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.\n\nElement-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.\n\nWhen/where applicable:\n1. Navigate to the MarkLogic Admin page >> Security >> Protected Paths.\n2. Verify the applicable elements requiring additional protections are defined using an XQuery path expression (applicable for both XML and JSON document types).\n3. Verify the applicable role(s) are added against the specified path expression.\n\nIf specific document elements require additional protections and no Protected Paths or Protect Path roles are defined, this is a finding.","fixText":"See specific MarkLogic documentation regarding Compartment level security for necessary steps.\n\nApplying Document Compartment Security:\n1. Navigate to the MarkLogic Admin page >> Security >> Roles.\n2. Create a new role and assign applicable roles/permissions.\n3. Provide a Compartment name to the role.\n4. Ensure all data ingestion mechanisms (i.e., document insertion code/logic) apply the necessary applicable security permissions.\n\nApplying Element-Level Security:\n1. Navigate to the MarkLogic Admin page >> Security >> Protected Paths.\n2. Create a Protected Path by specifying an XQuery path expression identifying the element requiring specific protections.\n3. Add one or more applicable roles and specify their capability then save the configuration.\n4. Repeat step 3 for each element requiring additional protections.","ccis":["CCI-002264"]},{"vulnId":"V-220377","ruleId":"SV-220377r961353_rule","severity":"medium","ruleTitle":"MarkLogic Server must prevent non-privileged users from executing privileged functions, to include disabling, circumventing, or altering implemented security safeguards/countermeasures.","description":"Preventing non-privileged users from executing privileged functions mitigates the risk that unauthorized individuals or processes may gain unnecessary access to information or privileges. \n\nSystem documentation should include a definition of the functionality considered privileged.\n\nDepending 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.\n\nA 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: \nCREATE\nALTER\nDROP\nGRANT\nREVOKE\nDENY\n\nThere may also be Data Manipulation Language (DML) statements that, subject to context, should be regarded as privileged. Possible examples include:\n\nTRUNCATE TABLE;\nDELETE, or\nDELETE affecting more than n rows, for some n, or\nDELETE without a WHERE clause;\n\nUPDATE or\nUPDATE affecting more than n rows, for some n, or\nUPDATE without a WHERE clause;\n\nany SELECT, INSERT, UPDATE, or DELETE to an application-defined security table executed by other than a security principal.\n\nDepending 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.","checkContent":"Review the MarkLogic system documentation to obtain the definition of the database/DBMS functionality considered privileged in the context of the system in question.\n\nReview MarkLogic users and assigned roles\n1. Navigate to the MarkLogic Admin page >> Security >> Roles.\n2. Validate user-created roles have appropriate permissions/roles applied.\n3. Navigate to the MarkLogic Admin page >> Security >> Users.\n4. Verify user-created Users are only granted roles meeting their specific requirements and do not allow for unnecessary elevated privileges.\n\nIf Users are assigned roles providing unnecessary elevated or privileged permissions, this is a finding.\n\nIf Roles are defined with unnecessary elevated permissions, this is a finding.","fixText":"Review MarkLogic User and Role configurations to ensure correct privileges are assigned and update as required.\n\n1. Navigate to the MarkLogic Admin page >> Security >> Roles.\n2. Select specific roles (usually custom defined roles by administrator) and only apply privileges with the least amount of permissions required for a given role.\n3. Navigate to the MarkLogic Admin Page >> Security >> Users.\n4. 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.\n5. Save configuration and repeat for each user-defined User/Role.","ccis":["CCI-002235"]},{"vulnId":"V-220378","ruleId":"SV-220378r961359_rule","severity":"medium","ruleTitle":"Execution of software modules (to include stored procedures, functions, and triggers) with elevated privileges must be restricted to necessary cases only.","description":"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.\n\nPrivilege elevation must be utilized only where necessary and protected from misuse.\n\nThis 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.","checkContent":"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.\n\nAll read, update, or execute privileges are defined by specifying applicable system roles/permissions.\n\n1. Verify MarkLogic user-defined modules are created and stored with applicable document permissions.\n2. Verify users interacting with the system are assigned to roles with the least amount of privileges required for a given user.\n3. Navigate to the MarkLogic Admin page >> Security >> Users.\n4. 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.\n\nIf a user is assigned roles exceeding their required access/privilege level, this is a finding.\n\nIf custom modules are stored with unnecessary elevated document permissions, this is finding.","fixText":"Correcting issues with unnecessary elevated privileges, and access to or execution of system resources, is a two-step process.\n\nCorrecting custom code/module permissions:\nWhen 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)\n\nCorrecting User privileges:\n1. Navigate to the MarkLogic Admin page >> Security >> Roles.\n2. Select a role under consideration and add/remove specific roles or permissions allowing the required level of permissions for a given role.\n3. Save the configuration.\n4. Navigate to the MarkLogic Admin page >> Security >> Users.\n5. 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.\n6. Repeat as required for each User and Role (usually these are user-defined roles or users).","ccis":["CCI-002233"]},{"vulnId":"V-220380","ruleId":"SV-220380r961392_rule","severity":"medium","ruleTitle":"MarkLogic Server must allocate audit record storage capacity in accordance with organization-defined audit record storage requirements.","description":"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.\n\nThe 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.\n\nIn 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.","checkContent":"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.\n\nIf there have been, this is a finding.","fixText":"All MarkLogic logs, including audits, are stored within the Data directory (i.e., /var/opt/MarkLogic/Logs). \n\nMarkLogic requires the lesser of 2x the content forest size, or 96GB of free space. \n\nSystem Administrators must ensure/configure between 1.5 and 3x free disk space for normal operations.","ccis":["CCI-001849"]},{"vulnId":"V-220381","ruleId":"SV-220381r961398_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nIf support personnel are not notified immediately upon storage volume utilization reaching 75 percent, they are unable to plan for storage capacity expansion. \n\nThe appropriate support staff include, at a minimum, the ISSO and the DBA/SA.","checkContent":"Review system configuration to determine if appropriate support staff are not notified immediately upon storage volume utilization reaching 75 percent.\n\nIf the Organization is not using Ops Director, or a third-party tool for storage volume utilization/alerting, this is a finding.","fixText":"Configure the system to notify appropriate support staff immediately upon storage volume utilization reaching 75 percent.\n\nUse MarkLogic Ops Director with Alerts, or third-party tool to monitor storage Volume utilization/alerting.","ccis":["CCI-001855"]},{"vulnId":"V-220382","ruleId":"SV-220382r961401_rule","severity":"medium","ruleTitle":"MarkLogic Server must provide an immediate real-time alert to appropriate support staff of all audit failures.","description":"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. \n\nThe appropriate support staff include, at a minimum, the ISSO and the DBA/SA.\n\nA 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.\n\nAlerts 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).","checkContent":"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.\n\nIf real-time alerts are not sent upon auditing failure, this is a finding.","fixText":"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.","ccis":["CCI-001858"]},{"vulnId":"V-220383","ruleId":"SV-220383r1018605_rule","severity":"medium","ruleTitle":"MarkLogic Server must produce audit records of its enforcement of access restrictions associated with changes to the configuration of the DBMS or database(s).","description":"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. \n\nEnforcement 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.","checkContent":"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).\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field, a value of false means auditing is not enabled, this is a finding. \n5. If the following audit events are not enabled, this is a finding:\n- Audit Configuration Change\n- Configuration Change\n- User Configuration Change\n6. If the Audit Restrictions - Outcome is not Both, this is a finding.\n7. If any Audit Restriction Inclusions/Exclusions are not documented in the System Security Plan, this is a finding.","fixText":"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).\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the following audit events:\n- Audit Configuration Change\n- Configuration Change\n- User Configuration Change\n6. Set the Audit Restrictions - Outcome to Both.\n7. If any Audit Restriction - Inclusions/Exclusions are approved in the SSP, ensure they have been applied.","ccis":["CCI-003938","CCI-001814"]},{"vulnId":"V-220384","ruleId":"SV-220384r961470_rule","severity":"medium","ruleTitle":"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.","description":"Use of nonsecure network functions, ports, protocols, and services exposes the system to avoidable threats.","checkContent":"Review the network functions, ports, protocols, and services supported by MarkLogic for any that are prohibited by the PPSM guidance.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the App Servers icon on the left tree menu.\n4. Inspect the Summary screen for the Type/Port/ and SSL configuration.\n5. If any of the App Servers uses a protocol or port prohibited by the PPSM guidance, this is a finding.","fixText":"Disable each prohibited network function, port, protocol, or service in MarkLogic.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the App Servers icon on the left tree menu.\n4. For any App Server that uses a prohibited port or protocol either disable the App Server or reconfigure to be compliant with the PPSM.","ccis":["CCI-001762"]},{"vulnId":"V-220385","ruleId":"SV-220385r961521_rule","severity":"medium","ruleTitle":"MarkLogic Server must prohibit the use of cached authenticators after an organization-defined time period.","description":"If cached authentication information is out-of-date, the validity of the authentication information may be questionable.","checkContent":"Review MarkLogic settings to determine whether the organization-defined limit for cached authentication is implemented.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Security icon.\n2. Click the External Security icon.\n3. Select each of the External Security providers.\n4. For each of the providers inspect the cache timeout field, a value that does not match the organization-defined time limit is a finding.","fixText":"Modify MarkLogic settings to implement the organization-defined limit on the lifetime of cached authenticators.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Security icon.\n2. Click the External Security icon.\n3. Select each of the External Security providers.\n4. For each of the providers set the cache timeout field to the organization-defined time limit.","ccis":["CCI-002007"]},{"vulnId":"V-220386","ruleId":"SV-220386r961596_rule","severity":"medium","ruleTitle":"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.","description":"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. \n\nThe authoritative list of DoD-approved PKIs is published at https://public.cyber.mil/pki-pke/interoperability/.\n\nThis requirement focuses on communications protection for the DBMS session rather than for the network packet.","checkContent":"Review MarkLogic settings to determine whether the server will accept non-DoD approved PKI end-entity certificates, this is a finding.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Security icon.\n2. Click the Certificate Authorities icon.\n3. If there are any PKI end-entity certificates that are not DoD approved, this is a finding.","fixText":"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.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Security icon.\n2. Click the Certificate Authorities icon.\n3. Remove all PKI end-entity certificates not approved by DoD.","ccis":["CCI-002470"]},{"vulnId":"V-220387","ruleId":"SV-220387r1018556_rule","severity":"high","ruleTitle":"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.","description":"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.\n\nSelection 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). \n\nThe 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.","checkContent":"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.\n\nIf no information is identified as requiring such protection, this is not a finding.\n\nReview 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.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Databases icon.\n2. Click the database that is to be checked.\n3. If the \"data encryption\" drop-down is set to ON, this is not a finding, and no further checks need to be performed.\n4. If the \"data encryption\" drop-down is set to OFF, continue the check.\n5. If the \"data encryption\" drop-down is set to default-cluster, continue the check with the steps below:\na. Click on the Clusters icon.\nb. Click [Cluster Name].\nc. Click the Keystore Tab.\nd. If the Cluster Default Encryption configuration is OFF, this is a finding.\n\nFindings Matrix\n-------------------------------------------------------\nDatabase Cfg. | Cluster Cfg | Finding\n--------------------------------------------------------\nON | *Any* | No\n*Any* | Force | No\nDefault-cluster | Default-on | No\nDefault-cluster | Default-off | Yes\nOff | Default-on | Yes\nOff | Default-off | Yes","fixText":"Configure MarkLogic to provide the required level of cryptographic protection.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Databases icon.\n2. Click the database that is to be fixed.\n3. Select ON from the data encryption drop-down.","ccis":["CCI-002475"]},{"vulnId":"V-220388","ruleId":"SV-220388r1018557_rule","severity":"high","ruleTitle":"MarkLogic Server must implement cryptographic mechanisms preventing the unauthorized disclosure of organization-defined information at rest on organization-defined information system components.","description":"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.\n\nSelection 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). \n\nThe 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.","checkContent":"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.\n\nIf no information is identified as requiring such protection, this is not a finding.\n\nReview 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.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Databases icon.\n2. Click the database to be checked.\n3. If the data encryption drop-down is set to ON, this is not a finding, and no further checks need to be performed.\n4. If the data encryption drop-down is set to OFF, continue the check.\n5. If the data encryption drop-down is set to default-cluster, continue the check with the steps below:\na. Click the Clusters icon.\nb. Click [Cluster Name].\nc. Click the Configure Tab.\nd. If the Cluster Default Encryption configuration is OFF, this is a finding.\n\nFindings Matrix\n-------------------------------------------------------\nDatabase Cfg. | Cluster Cfg | Finding\n--------------------------------------------------------\nON | *Any* | No\n*Any* | Force | No\nDefault-cluster | Default-on | No\nDefault-cluster | Default-off | Yes\nOff | Default-on | Yes\nOff | Default-off | Yes","fixText":"Configure MarkLogic to provide the required level of cryptographic protection.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Databases icon.\n2. Click the database is to be fixed.\n3. Select ON from the data encryption drop-down.","ccis":["CCI-002476"]},{"vulnId":"V-220389","ruleId":"SV-220389r1001008_rule","severity":"medium","ruleTitle":"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).","description":"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. \n\nOrganization-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). \n\nThis 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.\n\nThe 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).\n\nMarkLogic 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.","checkContent":"Obtain evidence that package updates are consistently applied to MarkLogic within the time frame defined for each patch.\n\nThe most recent releases of MarkLogic Server can be found at https://help.marklogic.com. \n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. \n\nCheck the MarkLogic version identified in the upper left side of the Admin Interface and compare it to the versions found on the MarkLogic website.\n\nObtain evidence that package updates are consistently applied to MarkLogic within the time frame defined for each patch. \n\nIf such evidence cannot be obtained, or the evidence that is obtained indicates a pattern of noncompliance, this is a finding.","fixText":"Institute and adhere to policies and procedures to ensure that package updates are consistently applied to MarkLogic within the time allowed.\n\nMarkLogic 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.","ccis":["CCI-002605"]},{"vulnId":"V-220390","ruleId":"SV-220390r961791_rule","severity":"medium","ruleTitle":"MarkLogic Server must be able to generate audit records when security objects are accessed.","description":"Changes to the security configuration must be tracked.\n\nThis requirement applies to situations where security data is retrieved or modified via data manipulation operations, as opposed to via specialized security functionality.","checkContent":"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.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Verify audit enabled field is set to true. If the setting is not true, this is a finding. \n5. 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.","fixText":"Configure MarkLogic to produce audit records when security objects are accessed, to include reads, creations, modifications and deletions of data, and execution of logic.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the security-access event for auditing.\n6. Under the Audit Restrictions section, enable \"both\" under the Outcome selection.","ccis":["CCI-000172"]},{"vulnId":"V-220391","ruleId":"SV-220391r961791_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when unsuccessful attempts to access security objects occur.","description":"Changes to the security configuration must be tracked.\n\nThis requirement applies to situations where security data is retrieved or modified via data manipulation operations, as opposed to via specialized security functionality.\n\nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.","checkContent":"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.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Verify audit enabled field is set to true. If the setting is not true, this is a finding. \n5. 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.","fixText":"Configure MarkLogic to produce audit records when security objects are accessed, to include reads, creations, modifications and deletions of data, and execution of logic.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the security-access event for auditing.\n6. Under the Audit Restrictions section, enable \"both\" under the Outcome selection.","ccis":["CCI-000172"]},{"vulnId":"V-220392","ruleId":"SV-220392r961797_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when categories of information (e.g., classification levels/security levels) are accessed.","description":"Changes in categories of information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected.\n\nFor 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.","checkContent":"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.\n\nIf they are not produced, this is a finding.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field, a value of false means there is no auditing identifying the individual user, this is a finding. \n5. If audit enabled field is true but the document-read event is not selected, this is a finding.\n6. 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.\n7. If the role that has been configured for the category of information is not included under the audit restriction roles, this is a finding.","fixText":"Configure MarkLogic to produce audit records when categories of information are accessed, to include reads, creations, modifications, and deletions.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the document-read event for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.\n7. 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.","ccis":["CCI-000172"]},{"vulnId":"V-220393","ruleId":"SV-220393r961797_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when unsuccessful attempts to access categories of information (e.g., classification levels/security levels) occur.","description":"Changes in categories of information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected.\n\nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.\n\nFor 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.","checkContent":"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.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field, a value of false means there is no auditing identifying the individual user, this is a finding. \n5. If audit enabled field is true, but the document-read event is not selected, this is a finding.\n6. 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.\n7. If the role that has been configured for the category of information is not included under the audit restriction roles, this is a finding.","fixText":"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.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the document-read event for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.\n7. 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.","ccis":["CCI-000172"]},{"vulnId":"V-220394","ruleId":"SV-220394r961800_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when privileges/permissions are added.","description":"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.","checkContent":"Review MarkLogic security and audit configurations to verify that audit records are produced when privileges/permissions/role memberships are added.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means there is no auditing identifying the individual user and this is a finding. \n5. If audit enabled field is true, but the user-role-addition event is not selected, this is a finding.\n6. 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.","fixText":"Configure MarkLogic to produce audit records when privileges/permissions/role memberships are added.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the user-role-addition event for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.","ccis":["CCI-000172"]},{"vulnId":"V-220395","ruleId":"SV-220395r961800_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when unsuccessful attempts to add privileges/permissions occur.","description":"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. \n\nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.","checkContent":"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.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field, a value of false means auditing is not enabled, this is a finding. \n5. If audit enabled field is true but the user-role-addition event is not selected, this is a finding.\n6. 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.","fixText":"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.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the user-role-addition event for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.","ccis":["CCI-000172"]},{"vulnId":"V-220396","ruleId":"SV-220396r961800_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when privileges/permissions are modified.","description":"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.","checkContent":"Check MarkLogic audit configurations to verify that audit records are produced when privileges/permissions/role memberships are modified.\n\nIf they are not produced, this is a finding.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. \n5. 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.\n6. 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.\n7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.","fixText":"Configure MarkLogic to produce audit records when privileges/permissions/role memberships are modified.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the permission-change, user-role-addition, and user-role-removal events for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.\n7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.","ccis":["CCI-000172"]},{"vulnId":"V-220397","ruleId":"SV-220397r961800_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when unsuccessful attempts to modify privileges/permissions occur.","description":"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. \n\nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.","checkContent":"Check MarkLogic audit configurations to verify that audit records are produced when attempts to modify privileges/permissions/role memberships are denied.\n\nIf they are not produced, this is a finding.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field, a value of false means auditing is not enabled, this is a finding. \n5. 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.\n6. 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.\n7. If any roles, URIs, or users are identified in audit restrictions, and not documented in the System Security Plan, this is a finding.","fixText":"Configure MarkLogic to produce audit records when attempts to modify privileges/permissions/role memberships are denied.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the permission-change, user-role-addition, and user-role-removal events for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.\n7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.","ccis":["CCI-000172"]},{"vulnId":"V-220398","ruleId":"SV-220398r961803_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when security objects are modified.","description":"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.","checkContent":"Check MarkLogic audit configurations to verify that audit records are produced when security objects are modified.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. \n5. If audit enabled field is true, but the security-access event are not selected, this is a finding.\n6. 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.\n7. If any roles, URIs, or users are identified in audit restrictions, and not documented in the System Security Plan, this is a finding.","fixText":"Configure MarkLogic to produce audit records when security objects are modified.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the security-access event for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.\n7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.","ccis":["CCI-000172"]},{"vulnId":"V-220399","ruleId":"SV-220399r961803_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when unsuccessful attempts to modify security objects occur.","description":"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.\n\nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.","checkContent":"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.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. \n5. If audit enabled field is true but the security-access event are not selected, this is a finding.\n6. 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.\n7. If any roles, URIs, or users are identified in audit restrictions, and not documented in the System Security Plan, this is a finding.","fixText":"Configure MarkLogic to produce audit records when it denies attempts to modify security objects, or other errors prevent attempts to modify security objects\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the security-access event for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.\n7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.","ccis":["CCI-000172"]},{"vulnId":"V-220400","ruleId":"SV-220400r961809_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when categories of information (e.g., classification levels/security levels) are modified.","description":"Changes in categories of information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected.\n\nFor 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.","checkContent":"Check MarkLogic audit configurations to verify that audit records are produced when categories of information are modified.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field, a value of false means auditing is not enabled, this is a finding. \n5. If audit enabled field is true but the document-update event is not selected, this is a finding.\n6. 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.\n7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.","fixText":"Configure MarkLogic to produce audit records when categories of information are modified.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the document-update event for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.\n7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.\n\nSee 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.","ccis":["CCI-000172"]},{"vulnId":"V-220401","ruleId":"SV-220401r961809_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when unsuccessful attempts to modify categories of information (e.g., classification levels/security levels) occur.","description":"Changes in categories of information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected.\n\nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.\n\nFor 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.","checkContent":"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.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. \n5. If audit enabled field is true but the document-update event is not selected, this is a finding.\n6. 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.\n7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.","fixText":"Configure MarkLogic to produce audit records when the system denies attempts, other errors prevent attempts to modify categories of information.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. If audit enabled field is true but the document-update event is not selected, this is a finding.\n6. Enable \"both\" for the audit restriction under the outcome selection.\n7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.","ccis":["CCI-000172"]},{"vulnId":"V-220402","ruleId":"SV-220402r961812_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when privileges/permissions are deleted.","description":"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.","checkContent":"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.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. \n5. If audit enabled field is true but the user-role-removal event is not selected, this is a finding.\n6. 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.\n7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.","fixText":"Configure MarkLogic audit settings to generate an audit record when privileges/permissions/role memberships are removed, revoked, or denied to any user or role.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable user-role-removal event for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.\n7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.","ccis":["CCI-000172"]},{"vulnId":"V-220403","ruleId":"SV-220403r961812_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when unsuccessful attempts to delete privileges/permissions occur.","description":"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. \n\nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.","checkContent":"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.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. \n5. If audit enabled field is true, but the user-role-removal event is not selected, this is a finding.\n6. 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.\n7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.","fixText":"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.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable user-role-removal event for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.\n7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.","ccis":["CCI-000172"]},{"vulnId":"V-220404","ruleId":"SV-220404r961818_rule","severity":"medium","ruleTitle":"MarkLogic Server DBMS must generate audit records when security objects are deleted.","description":"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.","checkContent":"Check MarkLogic audit configurations to verify that audit records are produced when security objects are dropped.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. \n5. If audit enabled field is true, but the user-role-removal and security-access events are not selected, this is a finding.\n6. 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.\n7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.","fixText":"Configure MarkLogic to produce audit records when security objects are deleted.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable user-role-removal and security-access events for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.\n7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.","ccis":["CCI-000172"]},{"vulnId":"V-220405","ruleId":"SV-220405r961818_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when unsuccessful attempts to delete security objects occur.","description":"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.\n\nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.","checkContent":"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.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. \n5. If audit enabled field is true, but the user-role-removal and security-access events are not selected, this is a finding.\n6. 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.\n7. If any roles, URIs, or users are identified in audit restrictions, and not documented in the System Security Plan, this is a finding.","fixText":"Configure MarkLogic to produce audit records when the system denies attempts, or when other errors prevent attempts to drop security objects.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable user-role-removal event for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.\n7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.","ccis":["CCI-000172"]},{"vulnId":"V-220406","ruleId":"SV-220406r961821_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when categories of information (e.g., classification levels/security levels) are deleted.","description":"Changes in categories of information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected.\n\nFor 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.","checkContent":"Check MarkLogic audit configurations to verify that audit records are produced when categories of information are deleted.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. \n5. If audit enabled field is true, but the document-update event is not selected, this is a finding.\n6. 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.\n7. If any roles, URIs, or users are identified in audit restrictions, and not documented in the System Security Plan, this is a finding.","fixText":"Configure MarkLogic to produce audit records when categories of information are deleted.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the document-update event for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.\n7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan. \n\nSee 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.","ccis":["CCI-000172"]},{"vulnId":"V-220407","ruleId":"SV-220407r961821_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when unsuccessful attempts to delete categories of information (e.g., classification levels/security levels) occur.","description":"Changes in categories of information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected.\n\nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.\n\nFor 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.","checkContent":"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.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. \n5. If audit enabled field is true, but the document-update event is not selected, this is a finding.\n6. 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.\n7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.","fixText":"Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the document-update event for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.\n7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan. \n\nSee 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.","ccis":["CCI-000172"]},{"vulnId":"V-220408","ruleId":"SV-220408r961824_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when successful logons or connections occur.","description":"For completeness of forensic analysis, it is necessary to track who/what (a user or other principal) logs on to the DBMS.","checkContent":"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.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. \n5. If audit enabled field is true, but the authentication-failure event is not selected, this is a finding.\n6. 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.\n7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.","fixText":"Configure MarkLogic audit settings to generate an audit record each time a user (or other principal) logs on or connects to the DBMS. \n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the authentication-failure event for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.\n7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.","ccis":["CCI-000172"]},{"vulnId":"V-220409","ruleId":"SV-220409r961824_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when unsuccessful logons or connection attempts occur.","description":"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.","checkContent":"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).\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means auditing is not enable and this is a finding. \n5. If audit enabled field is true but the authentication-failure event is not selected, this is a finding.\n6. 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.\n7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.","fixText":"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).\n\nInclude 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).\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the authentication-failure event for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.\n7. Ensure no roles, URIs or users are identified in the audit restrictions, unless documented in the System Security Plan.","ccis":["CCI-000172"]},{"vulnId":"V-220410","ruleId":"SV-220410r961827_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records for all privileged activities or other system-level access.","description":"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. \n\nSystem documentation should include a definition of the functionality considered privileged.\n\nA 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.\n\nDepending 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.\n\nNote 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.","checkContent":"Check MarkLogic audit configuration to verify audit records are generated when privileged actions occur.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. \n5. If audit enabled field is true but the security-access event is not selected, this is a finding.\n6. 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.\n7. If any roles, URIs, or users are identified in audit restrictions, and not documented in the System Security Plan, this is a finding.","fixText":"Configure MarkLogic to produce audit records when privileged actions occur.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the security-access event for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.\n7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.","ccis":["CCI-000172"]},{"vulnId":"V-220411","ruleId":"SV-220411r961827_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when unsuccessful attempts to execute privileged activities or other system-level access occur.","description":"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. \n\nSystem documentation should include a definition of the functionality considered privileged.\n\nA 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.\n\nDepending 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.\n\nNote 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.\n\nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.","checkContent":"Review MarkLogic security and audit configurations to verify that audit records are produced when the DBMS prevents attempted privileged actions.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. \n5. If audit enabled field is true, but the security-access event is not selected, this is a finding.\n6. 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.\n7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.","fixText":"Configure MarkLogic to produce audit records when the DBMS prevents attempted privileged actions.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the security-access event for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.\n7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.","ccis":["CCI-000172"]},{"vulnId":"V-220412","ruleId":"SV-220412r961833_rule","severity":"medium","ruleTitle":"MarkLogic Server must generate audit records when concurrent logons/connections by the same user from different workstations occur.","description":"For completeness of forensic analysis, it is necessary to track who logs on to the DBMS.\n\nConcurrent 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.\n\n(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.)","checkContent":"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.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. \n5. If audit enabled field is true, but the security-access event is not selected, this is a finding.\n6. 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.\n7. If any roles, URIs, or users are identified in audit restrictions and not documented in the System Security Plan, this is a finding.","fixText":"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.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable the security-access and concurrent-request-denial events for auditing.\n6. Enable \"both\" for the audit restriction under the outcome selection.\n7. Ensure no roles, URIs, or users are identified in the audit restrictions, unless documented in the System Security Plan.","ccis":["CCI-000172"]},{"vulnId":"V-220413","ruleId":"SV-220413r961836_rule","severity":"medium","ruleTitle":"MarkLogic must be able to generate audit records when successful accesses to objects occur.","description":"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.","checkContent":"Review audit settings to verify objects identified by the application owner, for which access must be audited, are being audited.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to be checked resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Inspect the audit enabled field. A value of false means auditing is not enabled and this is a finding. \n5. If any audit events identified in the System Security Plan are not enabled, this is a finding.\n6. If the Audit Restrictions - Outcome is not Both, this is a finding.\n7. If any Audit Restriction Inclusions/Exclusions are not documented in the System Security Plan, this is a finding.","fixText":"Configure audit settings to create audit records when the specified access to the specified objects occurs.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Groups icon.\n2. Click the group in which the configuration to check resides (e.g., Default).\n3. Click the Auditing icon on the left tree menu.\n4. Set the audit enabled field to true.\n5. Enable any audit events identified as required in the System Security Plan (SSP).\n6. Set the Audit Restrictions - Outcome to Both.\n7. If any Audit Restriction - Inclusions/Exclusions are approved in the SSP, ensure they have been applied.","ccis":["CCI-000172"]},{"vulnId":"V-220414","ruleId":"SV-220414r961857_rule","severity":"medium","ruleTitle":"MarkLogic Server must implement NIST FIPS 140-2 or 140-3 validated cryptographic modules to provision digital signatures.","description":"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.\n\nFor 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.","checkContent":"Check MarkLogic configuration to verify use of NIST FIPS validated cryptographic modules to provision digital signatures.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Clusters icon.\n2. Click the local cluster.\n3. If SSL FIPS enabled button is false, this is a finding.","fixText":"Configure MarkLogic to use NIST FIPS validated cryptographic modules to provision digital signatures.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Clusters icon.\n2. Click the local cluster.\n3. Enable SSL FIPS option.","ccis":["CCI-002450"]},{"vulnId":"V-220415","ruleId":"SV-220415r961857_rule","severity":"medium","ruleTitle":"MarkLogic Server must implement NIST FIPS 140-2 or 140-3 validated cryptographic modules to generate and validate cryptographic hashes.","description":"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.\n\nFor 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.","checkContent":"Check MarkLogic configuration to verify use of a NIST FIPS validated cryptographic modules to generate and verify cryptographic hashes.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level-privileges.\n\n1. Click the Clusters icon.\n2. Click the local cluster.\n3. If SSL FIPS enabled button is false, this is a finding.","fixText":"Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\nConfigure MarkLogic to use a NIST FIPS validated cryptographic module for generation and verification of cryptographic hashes.\n\n1. Click the Clusters icon.\n2. Click the local cluster.\n3. Enable SSL FIPS option.","ccis":["CCI-002450"]},{"vulnId":"V-220416","ruleId":"SV-220416r961857_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nIt 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.\n\nFor 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.","checkContent":"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.\n\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Clusters icon.\n2. Click the local cluster.\n3. If SSL FIPS enabled button is false, this is a finding.","fixText":"Configure MarkLogic to use NIST FIPS validated cryptographic modules to provide cryptographic protection for the unclassified information that requires it.\n\nPerform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\n\n1. Click the Clusters icon.\n2. Click the local cluster.\n3. Enable SSL FIPS option.","ccis":["CCI-002450"]},{"vulnId":"V-220417","ruleId":"SV-220417r961860_rule","severity":"low","ruleTitle":"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.","description":"Information stored in one location is vulnerable to accidental or incidental deletion or alteration.\n\nOff-loading is a common process in information systems with limited audit storage capacity. \n\nThe 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.","checkContent":"Review the system documentation to determine how audit records are offloaded.\n\nIf the MarkLogic Server instance is not monitored by a third-party audit management tool, this is a finding.","fixText":"Configure the system to offload MarkLogic audit records.\n\nAdd the MarkLogic Server instance under the monitoring of a third-party audit management tool.","ccis":["CCI-001851"]},{"vulnId":"V-220418","ruleId":"SV-220418r961863_rule","severity":"medium","ruleTitle":"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.","description":"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. \n\nIn 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.","checkContent":"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.\n\nIf MarkLogic is not configured in accordance with security configuration settings, this is a finding.","fixText":"From the list of applicable DoD security configuration and implementation guidance, address the items that the MarkLogic Server configuration does not meet.","ccis":["CCI-000366"]},{"vulnId":"V-265874","ruleId":"SV-265874r999528_rule","severity":"high","ruleTitle":"MarkLogic Server must be a version supported by the vendor.","description":"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.\n\nSystems at unsupported servicing levels or releases will not receive security updates for new vulnerabilities, which leaves them subject to exploitation.\n\nWhen maintenance updates and patches are no longer available, the database software is no longer considered supported and should be upgraded or decommissioned.","checkContent":"Review the system documentation and interview the database administrator.\n\nIdentify all database software components.\n\nReview the current version and release information; execute the following from the query console:\nxdmp:version();\n--OR--\nPerform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges.\nVersion is displayed in the upper left corner of the console.\n\nAccess the MarkLogic website to validate that the version is currently supported:\nhttps://developer.marklogic.com/products/support-matrix/\n\nIf the DBMS or any of the software components are not supported by the vendor, this is a finding.","fixText":"Remove or decommission all unsupported software products.\n\nUpgrade unsupported DBMS or unsupported components to a supported version of the product.","ccis":["CCI-003376"]}]}