What changed in MarkLogic Server v9 STIG V3R3V3R3 changes

Discussion

Authentication with a DoDDoW-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 DoDDoW-approved PKIs, all DoDDoW systems, including databases, must be properly configured to implement access control policies. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system. This requirement is applicable to access control enforcement applications, a category that includes database management systems. If the DBMS does not follow applicable policy when approving access, it may be in conflict with networks or other applications in the information system. This may result in users either gaining or being denied access inappropriately and in conflict with applicable policy. MarkLogic Server uses a role-based security model. A user’s privileges and permissions are based on the roles assigned to the user. For background information on understanding the security model in MarkLogic Server, see Security Guide.

V-220341 in V3R3

Check text

Review the configuration of audit logs to determine whether auditing includes details identifying the individual user. If it does not, this is a finding. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit-enabled field. A value of false means there is no auditing identifying the individual user and this is a finding. 5. If audit enabled field is true, but the settings do not meet the DoDDoW minimum requirements for non-repudiation, this is a finding.

Fix text

Configure MarkLogic audit logs to ensure auditing includes details identifying the individual user. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Configure the settings to meet DoDDoW minimum requirements for protection against a user falsely repudiating.

V-220342 in V3R3

Title

MarkLogic Server must be configured to provide audit record generation capability for DoDW-defined auditable events within all DBMS/database components.

Check text

Check DBMS auditing to determine whether organization-defined auditable events are being audited by the system. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Inspect the audit enabled field. A value of false means there is no auditing and this is a finding. 5. If audit enabled field is true, but the selected auditable events do not meet DoDDoW minimum requirements, this is a finding.

Fix text

Configure MarkLogic to generate audit records for at least the DoDDoW minimum or organization-defined set of events. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Groups icon. 2. Click the group in which the configuration to check resides (e.g., Default). 3. Click the Auditing icon on the left tree menu. 4. Set the audit enabled field to true. 5. Configure the auditable events to meet DoDDoW minimum requirements.

Discussion

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

V-220343 in V3R3

Fix text

Implement procedures to monitor for unauthorized changes to DBMS software libraries, related software application libraries, and configuration files. If a third-party automated tool is not employed, an automated job that reports file information on the directories and files of interest and compares them to the baseline report for the same will meet the requirement. The supplemental file "ml-filechange-mon.sh" can be used to meet this requirement. - Edit the ml-filechange-mon.sh script with the correct email addresses and notification level. - Place the script in a location that can be accessed by the cron daemon. - Edit the crontab, and configure the script to run frequently enough to meet DoDDoW minimum requirements.

V-220355 in V3R3

Title

If MarkLogic Server authentication using passwords is employed, MarkLogic Server must enforce the DODoW standards for password complexity and lifetime.

Check text

Review MarkLogic settings to see if password authentication is being used, and whether password complexity and lifetime rules are being enforced. Check for MarkLogic Password Plugin from the MarkLogic Query Console with a user that holds administrative-level privileges. 1. Select "XQuery" in the Query Type drop down and copy the following code into the window: xquery version "1.0-ml"; import module namespace plugin = "http://marklogic.com/extension/plugin" at "/MarkLogic/plugin/plugin.xqy"; plugin:plugins("http://marklogic.com/xdmp/security/password-check") 2. Run the script. If the script returns "your query returned an empty sequence", then no password plugin is present. 3. If the script returns a file name or file names (e.g., password-check-minimum-length.xqy), then review the file/(s) in the &ltMarkLogic Home>/Plugins directory to verify compliance with DODDoW minimum password requirements. 4. Log in to the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 5. Click the Groups icon. 6. Click the group in which the App Server to be checked resides (e.g., Default). 7. Click the App Servers icon on the left tree menu. 8. Select each of the App Servers. 9. Inspect the selected authentication method, if "basic", "digestbasic", or "digest" is selected and there is not a custom password plugin, or if the password plugin does not meet DODDoW minimum requirements, this is a finding.

Fix text

If the use of passwords is not needed, configure MarkLogic to prevent password use. If the DBMS can inherit password complexity rules from the operating system or access control program, configure it to do so using one of the following methods: 1. Configure the MarkLogic server to use Kerberos, SAML, or Certificate based authentication. 2. Develop plugin to enforce password complexity. Examples can be found in MarkLogic Application Developers Guide. Plugins must enforce the following rules for passwords: a. minimum of 15 characters, including at least one of each of the following character sets: - Uppercase - Lowercase - Numeric - Special characters (e.g., ~ ! @ # $ % ^ & * ( ) _ + = - ' [ ] / ? > &lt) b. Minimum number of characters changed from previous password: 50 percent of the minimum password length (eight) c. Password lifetime limits for interactive accounts: Minimum 24 hours, maximum 60180 days d. Password lifetime limits for non-interactive accounts: Minimum 24 hours, maximum 365 days e. Number of password changes before an old one may be reused: Minimum of five Develop a custom extension that enforces the password complexity and lifetime. SeeRefer to https://docs.marklogic.com/guide/app-dev/plugins#id_91783

Discussion

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 Authorizingauthorizing Officialofficial (AO)-approved. The DODDoW standard for authentication is DODDoW-approved PKI certificates. Authentication based on User ID and Password may be used only when it is not possible to employ a PKI certificate, and requires AO approval. In such cases, the DODDoW standards for password complexity and lifetime must be implemented. DBMS products that can inherit the rules for these from the operating system or access control program (e.g., Microsoft Active Directory) must be configured to do so. For other DBMSs, the rules must be enforced using available configuration parameters or custom code. Types of Authentication Control the authentication scheme for HTTP, WebDAV, ODBC, and XDBC App Servers. - Basic authentication is the typical authentication scheme for web applications. A user is prompted for a username and password when accessing an application page. In basic mode, the password is obfuscated but not encrypted. - Digest authentication works the same way as basic, but offers encryption of passwords sent over the network. A user is prompted for a username and password when accessing an application page. - The digest-basic authentication scheme uses the more secure digest scheme whenever possible, but reverts to basic authentication when needed. Some older browsers, for example, do not support digest authentication. The digest-basic scheme is also useful if basic authentication was previously used, but must be migrated to digest. The first time a user accesses the server after changing from basic to digest-basic authentication scheme, the server computes the digest password by extracting the relevant information from the credentials supplied in basic mode. - Certificate-based authentication requires internal and external users and HTTPS clients to authenticate to MarkLogic Server via a client certificate, either in addition to, or rather than a password. - Application-level authentication bypasses all authentication and automatically logs all users in as a specified default user. Specify the default user in the Admin Interface, and any users accessing the server automatically inherit the security attributes (roles, privileges, default permissions) of the default user. Application-level authentication is available on HTTP, ODBC, and WebDAV servers. - In Kerberos Ticket, the user is authenticated by Kerberos and a Kerberos session ticket is used to authenticate the user to access MarkLogic Server. - When SAML authentication is used, a client requests a resource from MarkLogic Server with no security context. MarkLogic redirects the authentication request to an Identity Provider, the Identity Provider prompts the user to login, if necessary, and sends the authentication request back to MarkLogic Server (the Service Provider) for validation.

V-220364 in V3R3

Discussion

The DoDDoW standard for authentication is DoDDoW-approved PKI certificates. Authentication based on User ID and Password may be used only when it is not possible to employ a PKI certificate, and requires AO approval. In such cases, passwords must be protected at all times, and encryption is the standard method for protecting passwords during transmission. DBMS passwords sent in clear text format across the network are vulnerable to discovery by unauthorized users. Disclosure of passwords may easily lead to unauthorized access to the database. MarkLogic Types of Authentication: Basic* Digest Digest-Basic* Certificate Application Level Kerberos Ticket SAML * Indicates that the authentication method allows the username and password to be transmitted in clear text. For more information on the types of authentication MarkLogic offers, follow this link: https://docs.marklogic.com/9.0/guide/security/authentication#id_14250

V-220365 in V3R3

Discussion

The DoDDoW standard for authentication is DoDDoW-approved PKI certificates. A certificate’s certification path is the path from the end entity certificate to a trusted root certification authority (CA). Certification path validation is necessary for a relying party to make an informed decision regarding acceptance of an end entity certificate. Certification path validation includes checks such as certificate issuer trust, time validity, and revocation status for each certificate in the certification path. Revocation status information resource/or CA and subject certificates in a certification path is commonly provided via certificate revocation lists (CRLs) or online certificate status protocol (OCSP) responses. Database Management Systems that do not validate certificates by performing RFC 5280-compliant certification path validation are in danger of accepting certificates that are invalid and/or counterfeit. This could allow unauthorized access to the database.

V-220366 in V3R3

Discussion

The DoDDoW standard for authentication is DoDDoW-approved PKI certificates. PKI certificate-based authentication is performed by requiring the certificate holder to cryptographically prove possession of the corresponding private key. If the private key is stolen, an attacker can use the private key(s) to impersonate the certificate holder. In cases where the DBMS-stored private keys are used to authenticate the DBMS to the system’s clients, loss of the corresponding private keys would allow an attacker to successfully perform undetected man-in-the-middle attacks against the DBMS system and its clients. Both the holder of a digital certificate and the issuing authority must take careful measures to protect the corresponding private key. Private keys should always be generated and protected in FIPS 140-2 or 140-3 validated cryptographic modules. All access to the private key(s) of the DBMS must be restricted to authorized and authenticated users. If unauthorized users have access to one or more of the DBMS's private keys, an attacker could gain access to the key(s) and use them to impersonate the database on the network or otherwise perform unauthorized actions.

V-220367 in V3R3

Title

MarkLogic Server must only accept end-entity certificates issued by DoDDoW PKI or DoDDoW-approved PKI Certification Authorities (CAs) for the establishment of all encrypted sessions.

Check text

Review MarkLogic settings to determine whether the server will accept non-DoDDoW approved PKI end-entity certificates, this is a finding. Perform the check from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Security icon. 2. Click the Certificate Authorities icon. 3. If there are any PKI end-entity certificates that are not DoDDoW approved, this is a finding.

Fix text

Configure MarkLogic to accept only DoDDoW and DoDDoW-approved PKI end-entity certificates by revoking trust in any certificates not issued by a DoDDoW-approved certificate authority. Perform the fix from the MarkLogic Server Admin Interface with a user that holds administrative-level privileges. 1. Click the Security icon. 2. Click the Certificate Authorities icon. 3. Remove all PKI end-entity certificates not approved by DoDDoW.

Discussion

Only DoDDoW-approved external PKIs have been evaluated to ensure that they have security controls and identity vetting procedures in place sufficient for DoDDoW systems to rely on the identity asserted in the certificate. PKIs lacking sufficient security controls and identity vetting procedures risk being compromised and issuing certificates that enable adversaries to impersonate legitimate users. The authoritative list of DoDDoW-approved PKIs is published at https://public.cyber.mil/pki-pke/interoperability/. This requirement focuses on communications protection for the DBMS session rather than for the network packet.

V-220386 in V3R3

Title

MarkLogic Server must be configured in accordance with the security configuration settings based on DoDDoW security configuration and implementation guidance, including STIGs, NSA configuration guides, CTOs, DTMs, and IAVMs.

Check text

Determine the applicable DoDDoW security configuration and implementation guidance for the deployment environment. Asses the MarkLogic Server documentation and configuration in accordance with the applicable guidance. If MarkLogic is not configured in accordance with security configuration settings, this is a finding.

Fix text

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

Discussion

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 DoDDoW that reflects the most restrictive security posture consistent with operational requirements. In addition to this SRG, sources of guidance on security and information assurance exist. These include NSA configuration guides, CTOs, DTMs, and IAVMs. The DBMS must be configured in compliance with guidance from all such relevant sources.

V-220418 in V3R3