MarkLogic Server TOE is built with a blend of search engine and database architecture approaches specifically designed to index and retrieve XML content. The TOE’s native data format is XML and XML is accepted in an ‘as is’ form, while content in other formats can be converted to an XML representation or stored as is (in binary or text formats) when loaded into MarkLogic Server. As an XML database, MarkLogic Server manages its own content repository and is accessed using the W3C standard XQuery language, just as a relational database is a specialized server that manages its own repository and is accessed through Structured Query Language (SQL).
\r\nThe TOE is fully transactional, runs in a distributed environment and can scale to terabytes of indexed content. It is schema independent and all loaded documents can be immediately queried without normalizing the data in advance. MarkLogic Server provides developers with the functionality and programmability, using XQuery as its query language, to build content-centric applications. Developers build applications using XQuery both to search the content and as a programming language in which to develop applications. It is possible to create entire applications using only MarkLogic Server, and programmed entirely in XQuery. Application can also be created using Java or other programming languages that access MarkLogic Server.
\r\nThe security management functions of the TOE are performed via the Admin Interface, which is a web based browser GUI implemented as a MarkLogic Server web application. This interface allows authorized administrators to manage audit events, user accounts, access control and TOE sessions.
\r\nAuthorized administrators can also perform security management functions programmatically using the XQuery functions included in XQuery library modules that are included with MarkLogic Server. The programmatic libraries that support security management are the Admin API, the Security API, and the PKI API. The Admin API enables the scripting of administrative tasks that would otherwise need the Admin Interface to perform, including TOE security management tasks (for example, management of TOE sessions, configuration of auditing, and so on). For example, you can write a program using the Admin API to create and configure App Servers, including setting the type of authentication that the App Servers use. Most functions in this library perform administrative tasks and therefore require the user who runs an XQuery program executing these functions to be an authorized administrator. The Security API provide functions for managing objects stored in the security database (users, roles, amps, and privileges). For example, you can use the Security API to create and modify users (including passwords), roles, amps, and privileges. The PKI API provides functions that manage private keys and other cryptographic management functions used with SSL/TLS (HTTPS) in FIPS mode.
\r\nSecurity management functions include the ability to control the creation, management, and configuration of databases, forests, servers, and hosts. Documents are stored in forests. The name forests comes from the fact that XML documents are tree structures and a collection of trees is a forest. One or more forests are gathered together to form a database. Databases are logical units against which you can assign HTTP and XDBC servers and set various runtime configuration options. A host is a single instance of MarkLogic Server running on a single machine. Databases exist as a logical abstraction because in a distributed environment it can be useful to have the same logical database spread across different hosts, perhaps one host with two forests and another with three.
","evaluation_configuration":null,"security_evaluation_summary":"The evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) process and scheme. The criteria against which the MarkLogic Server Enterprise Edition 6.0-4 TOE was judged are described in the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 4, September 2012. The evaluation methodology used by the evaluation team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Version 3.1, Revision 4, September 2012. Leidos determined that the evaluation assurance level (EAL) for the product is EAL2 augmented with ALC_FLR.3 family of assurance requirements. The product, when configured as specified in the MarkLogic Server Installation Guide for All Platforms, MarkLogic Server Administrator’s Guide, and MarkLogic Common Criteria Evaluated Configuration Guide satisfies all of the security functional requirements stated in the MarkLogic Server Enterprise Edition 6.0 Security Target, Version 1.0, December XX, 2013. Two Validators on behalf of the CCEVS Validation Body monitored the evaluation carried out by LEIDOS. The evaluation was completed in December 2013. Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report, CCEVS-VR-VID10507-2013, dated 16 December 2013.
","environmental_strengths":"Mark Logic Server Enterprise Edition, Version 6.0-4 provides a low to moderate level of independently assured security in a conventional TOE and is suitable for a relatively benign environment with good physical access security and competent administrators. Within such environments it is assumed that attackers will have little attack potential. MarkLogic Server Enterprise Edition, Version 6.0-4 supports the following security functions:
\r\n\r\n
Security Audit: The TOE audit records that include date and time of the event, subject identity and outcome for security events. The TOE provides authorized administrators with the ability to include and exclude auditable events based on user identity, role, event type, object identity and success and failure of auditable security events. When appropriate, the TOE also associates audit events with the identity of the user that caused the event. The environment stores the audit records and also provides the system clock information that is used by the TOE to timestamp each audit record.
\r\nCryptographic Support: The Secure Sockets Layer protocol or Transport Layer Security (TLS 1.0) protocol (referred to in this document as SSL/TLS in FIPS mode) is used to provide protection of the communications surrounding the remote administrative sessions from disclosure and from modification (referred to as SSL/TLS in FIPS mode in this security target). For communication between a customer application on a network and the HTTP server, XDBC server, or ODBC server of the TOE, the TOE offers the use of a SSL/TLS session in FIPS mode to protect these communications. Finally, the TOE uses an SSL/TLS in FIPS mode protected channel to distribute TSF data when it is transmitted between distributed parts of the TOE (that is, hosts within a cluster).
\r\nThe TOE uses OpenSSL object module version 2.0 which has undergone a FIPS 140-2 certification (certificate #1747). The TOE includes an OpenSSL object module built without modification from the source code of the OpenSSL FIPS certification. All references to “the TOE” performing cryptographic operations in this security target are indicating that the TOE is performing the operation through its use of the OpenSSL object module.
\r\nUser Data Protection: The TOE enforces a Discretionary Access Control (DAC) policy which restricts access to TOE-controlled object(s). Users of the TOE are identified and authenticated by the TOE before any access to the system is granted. Once access to the system is granted, authorization provides the mechanism to control what functions a user is allowed to perform based on the user’s role membership. Access to all TOE-controlled objects is denied unless access, based on role membership, is explicitly allowed. The authorized administrator role shall be able to access any object regardless of the object’s permissions. The TOE also provides amplifications or “amps” which temporarily grant roles to a user only for the execution of a specific function. Therefore, the DAC policy can also be extended by a user who is temporarily granted the privileged role in order to perform a specific “amped” function. The TOE also ensures that any previous information content of a resource is made unavailable upon the allocation of the resource to an object. Memory or disk space is only allocated when the size of the new data is first known, so that all previous data is overwritten by the new data.
\r\nIdentification and Authentication: The TOE requires users to provide unique identification and authentication data before any access to the system is granted and further restricts access to DBMS-controlled objects based on role membership. The TOE maintains the following security attributes belonging to individual users: role membership, and password. The TOE uses these attributes to determine access.
\r\nThe TOE provides a password plug-in functionality that allows administrators to write custom code to require passwords to conform to specific rules (e.g., the number of characters, special characters, last change date).
\r\nSecurity Management: The security functions of the TOE are managed by authorized administrators via the web-based Admin Interface, or application written using the Admin API, Security API, PKI API, and built-in admin functions. The ST defines the security role of ‘authorized administrator’. Authorized administrators perform all security functions of the TOE including managing audit events, user accounts, access control and TOE sessions.
\r\nProtection of the TSF: The provides protection mechanisms for its security functions. One of the protection mechanisms is that users must authenticate and have the appropriate permissions before any administrative operations or access to TOE data and resources can be performed on the system. The TOE also maintains a security domain that protects it from interference and tampering by untrusted subjects within the TOE scope of control.
\r\nCommunication with remote administrators is protected by SSL/TLS in FIPS mode, protecting against the disclosure and undetected modification of data exchanged between the TOE and the administrator. Communication with remote customer applications can also utilize SSL/TLS in FIPS mode to protect against the disclosure and undetected modification of data exchanged between the TOE and the customer application. Customer applications must determine whether the use of SSL/TLS in FIPS mode is necessary for that specific customer application’s data.
\r\nThe TOE ensures that TSF data is encrypted and remains consistent when transmitted between parts of the TOE. The TOE provides consistency of TSF data between distributed parts of the TOE by regularly monitoring the configuration file and security database for changes and distributing the updated configuration file or security database to all parts of the cluster. The TOE utilizes a TLS protected channel to distribute TSF data among a cluster.
\r\nTOE Access: The TOE restricts the maximum number of concurrent sessions that belong to the same user by enforcing an administrator configurable number of sessions per user. The TOE also denies session establishment based on attributes that can be set explicitly by authorized administrators including role identity, time of day and day of week.
\r\nUpon successful session establishment, the TOE stores and retrieves the date and time of the last successful session establishment to the user. It also stores and retrieves the date and time of the last unsuccessful session establishment and the number of unsuccessful attempts since the last successful session establishment. This information is collected by the TOE Access security function, because the information pertains to user's attempts to access the TOE. The information gathered by the TOE pertains to historical session establishment actions by a user.
","features":[]}