MongoDB Enterprise Advanced 3.x Security Technical Implementation Guide
Pick two releases to diff their requirements.
Open a previous version of this STIG.
Digest of Updates +43 −44
Comparison against the immediately-prior release (V1R2). Rule matching uses the Group Vuln ID. Content-change detection compares the rule’s description, check, and fix text after stripping inline markup — cosmetic-only edits aren’t flagged.
Added rules 43
- V-221158 High MongoDB must integrate with an organization-level authentication/access mechanism providing account management and automation for all users, groups, roles, and any other principals.
- V-221159 High MongoDB must enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.
- V-221160 Medium MongoDB must provide audit record generation for DoD-defined auditable events within all DBMS/database components.
- V-221161 Medium The audit information produced by MongoDB must be protected from unauthorized read access.
- V-221162 Medium MongoDB must protect its audit features from unauthorized access.
- V-221163 High MongoDB software installation account must be restricted to authorized users.
- V-221164 Medium Database software, including DBMS configuration files, must be stored in dedicated directories, or DASD pools, separate from the host OS and other applications.
- V-221165 Medium The role(s)/group(s) used to modify database structure (including but not necessarily limited to tables, indexes, storage, etc.) and logic modules (stored procedures, functions, triggers, links to software external to MongoDB, etc.) must be restricted to authorized users.
- V-221166 Medium Unused database components, DBMS software, and database objects must be removed.
- V-221167 Medium Unused database components that are integrated in MongoDB and cannot be uninstalled must be disabled.
- V-221168 Medium MongoDB must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).
- V-221169 High If DBMS authentication using passwords is employed, MongoDB must enforce the DoD standards for password complexity and lifetime.
- V-221170 High If passwords are used for authentication, MongoDB must store only hashed, salted representations of passwords.
- V-221171 High If passwords are used for authentication, MongoDB must transmit only encrypted representations of passwords.
- V-221172 High MongoDB must enforce authorized access to all PKI private keys stored/utilized by MongoDB.
- V-221173 Medium MongoDB must map the PKI-authenticated identity to an associated user account.
- V-221174 High MongoDB must use NIST FIPS 140-2-validated cryptographic modules for cryptographic operations.
- V-221175 Medium MongoDB must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).
- V-221176 Medium MongoDB must maintain the authenticity of communications sessions by guarding against man-in-the-middle attacks that guess at Session ID values.
- V-221177 Medium MongoDB must fail to a secure state if system initialization fails, shutdown fails, or aborts fail.
- V-221178 High MongoDB must protect the confidentiality and integrity of all information at rest.
- V-221179 Medium Database contents must be protected from unauthorized and unintended information transfer by enforcement of a data-transfer policy.
- V-221180 Medium MongoDB must prevent unauthorized and unintended information transfer via shared system resources.
- V-221181 Medium MongoDB must check the validity of all data inputs except those specifically identified by the organization.
- V-221182 Medium MongoDB and associated applications must reserve the use of dynamic code execution for situations that require it.
- V-221183 Medium MongoDB must provide non-privileged users with error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries.
- V-221184 Medium MongoDB must reveal detailed error messages only to the ISSO, ISSM, SA, and DBA.
- V-221185 Medium MongoDB must associate organization-defined types of security labels having organization-defined security label values with information in storage.
- V-221186 Medium MongoDB must enforce discretionary access control policies, as defined by the data owner, over defined subjects and objects.
- V-221188 Medium MongoDB must utilize centralized management of the content captured in audit records generated by all components of MongoDB.
- V-221189 Medium MongoDB must allocate audit record storage capacity in accordance with site audit record storage requirements.
- V-221190 Medium MongoDB must provide a warning to appropriate support staff when allocated audit record storage volume reaches 75% of maximum audit record storage capacity.
- V-221191 Medium MongoDB must prohibit user installation of logic modules (stored procedures, functions, triggers, views, etc.) without explicit privileged status.
- V-221192 Medium MongoDB must enforce access restrictions associated with changes to the configuration of MongoDB or database(s).
- V-221193 Medium MongoDB must require users to reauthenticate when organization-defined circumstances or situations require reauthentication.
- V-221194 Medium MongoDB must prohibit the use of cached authenticators after an organization-defined time period.
- V-221195 Medium MongoDB must only accept end entity certificates issued by DoD PKI or DoD-approved PKI Certification Authorities (CAs) for the establishment of all encrypted sessions.
- V-221196 Medium MongoDB 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.
- V-221197 Medium MongoDB must maintain the confidentiality and integrity of information during preparation for transmission.
- V-221198 Medium MongoDB must maintain the confidentiality and integrity of information during reception.
- V-221199 Medium When invalid inputs are received, MongoDB must behave in a predictable and documented manner that reflects organizational and system objectives.
- V-221200 High MongoDB must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.
- V-221201 Medium MongoDB 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.
Removed rules 44
- V-81843 Medium MongoDB must integrate with an organization-level authentication/access mechanism providing account management and automation for all users, groups, roles, and any other principals.
- V-81845 Medium MongoDB must enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.
- V-81847 Medium MongoDB must provide audit record generation for DoD-defined auditable events within all DBMS/database components.
- V-81849 Medium The audit information produced by MongoDB must be protected from unauthorized read access.
- V-81851 Medium MongoDB must protect its audit features from unauthorized access.
- V-81853 Medium MongoDB software installation account must be restricted to authorized users.
- V-81855 Medium Database software, including DBMS configuration files, must be stored in dedicated directories, or DASD pools, separate from the host OS and other applications.
- V-81857 Medium The role(s)/group(s) used to modify database structure (including but not necessarily limited to tables, indexes, storage, etc.) and logic modules (stored procedures, functions, triggers, links to software external to MongoDB, etc.) must be restricted to authorized users.
- V-81859 Medium Unused database components, DBMS software, and database objects must be removed.
- V-81861 Medium Unused database components that are integrated in MongoDB and cannot be uninstalled must be disabled.
- V-81863 Medium MongoDB must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).
- V-81865 Medium If DBMS authentication, using passwords, is employed, MongoDB must enforce the DoD standards for password complexity and lifetime.
- V-81867 Medium If passwords are used for authentication, MongoDB must store only hashed, salted representations of passwords.
- V-81869 Medium If passwords are used for authentication, MongoDB must transmit only encrypted representations of passwords.
- V-81871 High MongoDB must enforce authorized access to all PKI private keys stored/utilized by MongoDB.
- V-81873 Medium MongoDB must map the PKI-authenticated identity to an associated user account.
- V-81875 High MongoDB must use NIST FIPS 140-2-validated cryptographic modules for cryptographic operations.
- V-81877 Medium MongoDB must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).
- V-81879 Medium MongoDB must maintain the authenticity of communications sessions by guarding against man-in-the-middle attacks that guess at Session ID values.
- V-81881 Medium MongoDB must fail to a secure state if system initialization fails, shutdown fails, or aborts fail.
- V-81883 Medium MongoDB must protect the confidentiality and integrity of all information at rest.
- V-81885 Medium Database contents must be protected from unauthorized and unintended information transfer by enforcement of a data-transfer policy.
- V-81887 Medium MongoDB must prevent unauthorized and unintended information transfer via shared system resources.
- V-81889 Medium MongoDB must check the validity of all data inputs except those specifically identified by the organization.
- V-81891 Medium MongoDB and associated applications must reserve the use of dynamic code execution for situations that require it.
- V-81893 Medium MongoDB must provide non-privileged users with error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries.
- V-81895 Medium MongoDB must reveal detailed error messages only to the ISSO, ISSM, SA, and DBA.
- V-81897 Medium MongoDB must associate organization-defined types of security labels having organization-defined security label values with information in storage.
- V-81899 Medium MongoDB must enforce discretionary access control policies, as defined by the data owner, over defined subjects and objects.
- V-81901 Medium MongoDB must provide the means for individuals in authorized roles to change the auditing to be performed on all application components, based on all selectable event criteria within organization-defined time thresholds.
- V-81903 Medium MongoDB must utilize centralized management of the content captured in audit records generated by all components of MongoDB.
- V-81905 Medium MongoDB must allocate audit record storage capacity in accordance with site audit record storage requirements.
- V-81907 Medium MongoDB must provide a warning to appropriate support staff when allocated audit record storage volume reaches 75% of maximum audit record storage capacity.
- V-81909 Medium MongoDB must prohibit user installation of logic modules (stored procedures, functions, triggers, views, etc.) without explicit privileged status.
- V-81911 Medium MongoDB must enforce access restrictions associated with changes to the configuration of MongoDB or database(s).
- V-81913 Medium MongoDB must require users to reauthenticate when organization-defined circumstances or situations require reauthentication.
- V-81915 Medium MongoDB must prohibit the use of cached authenticators after an organization-defined time period.
- V-81917 Medium MongoDB must only accept end entity certificates issued by DoD PKI or DoD-approved PKI Certification Authorities (CAs) for the establishment of all encrypted sessions.
- V-81919 Medium MongoDB 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.
- V-81921 Medium MongoDB must maintain the confidentiality and integrity of information during preparation for transmission.
- V-81923 Medium MongoDB must maintain the confidentiality and integrity of information during reception.
- V-81925 Medium When invalid inputs are received, MongoDB must behave in a predictable and documented manner that reflects organizational and system objectives.
- V-81927 High MongoDB must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.
- V-81929 Medium MongoDB 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.
- RMF Control
- AC-2
- Severity
- H
- CCI
- CCI-000015
- Version
- MD3X-00-000010
- Vuln IDs
-
- V-221158
- V-81843
- Rule IDs
-
- SV-221158r822434_rule
- SV-96557
Checks: C-22873r410968_chk
Verify that the MongoDB configuration file (default location: /etc/mongod.conf) contains the following: security: authorization: "enabled" If this parameter is not present, this is a finding.
Fix: F-22862r410969_fix
Edit the MongoDB configuration file (default location: /etc/mongod.con) to include the following: security: authorization: "enabled" This will enable SCRAM-SHA-1 authentication (default). Instruction on configuring the default authentication is provided here: https://docs.mongodb.com/v3.4/tutorial/enable-authentication/ The high-level steps described by the above will require the following: 1. Start MongoDB without access control. 2. Connect to the instance. 3. Create the user administrator. 4. Restart the MongoDB instance with access control. 5. Connect and authenticate as the user administrator. 6. Create additional users as needed for your deployment.
- RMF Control
- AC-3
- Severity
- H
- CCI
- CCI-000213
- Version
- MD3X-00-000020
- Vuln IDs
-
- V-221159
- V-81845
- Rule IDs
-
- SV-221159r822435_rule
- SV-96559
Checks: C-22874r410971_chk
Review the system documentation to determine the required levels of protection for DBMS server securables by type of login. Review the permissions actually in place on the server. If the actual permissions do not match the documented requirements, this is a finding. MongoDB commands to view roles in a particular database: db.getRoles( { rolesInfo: 1, showPrivileges:true, showBuiltinRoles: true } )
Fix: F-22863r410972_fix
Use createRole(), updateRole(), dropRole(), grantRole() statements to add and remove permissions on server-level securables, bringing them into line with the documented requirements. MongoDB commands for role management can be found here: https://docs.mongodb.com/v3.4/reference/method/js-role-management/
- RMF Control
- AU-3
- Severity
- M
- CCI
- CCI-000130
- Version
- MD3X-00-000040
- Vuln IDs
-
- V-221160
- V-81847
- Rule IDs
-
- SV-221160r410976_rule
- SV-96561
Checks: C-22875r410974_chk
Check the MongoDB configuration file (default location: '/etc/mongod.conf)' for a key named 'auditLog:'. Example shown below: auditLog: destination: syslog If an "auditLog:" key is not present, this is a finding indicating that auditing is not turned on. If the "auditLog:" key is present and contains a subkey of "filter:" with an associated filter value string, this is a finding. The site auditing policy must be reviewed to determine if the "filter:" being applied meets the site auditing requirements. If not, then the filter being applied will need to be modified to comply. Example show below: auditLog: destination: syslog filter: '{ atype: { $in: [ "createCollection", "dropCollection" ] } }'
Fix: F-22864r410975_fix
If the "auditLog" setting was not present in the MongoDB configuration file (default location: '/etc/mongod.conf)' edit this file and add a configured "auditLog" setting: auditLog: destination: syslog Stop/start (restart) the mongod or mongos instance using this configuration. If the "auditLog" setting was present and contained a "filter:" parameter, ensure the "filter:" expression does not prevent the auditing of events that should be audited or remove the "filter:" parameter to enable auditing all events.
- RMF Control
- AU-9
- Severity
- M
- CCI
- CCI-000162
- Version
- MD3X-00-000190
- Vuln IDs
-
- V-221161
- V-81849
- Rule IDs
-
- SV-221161r410979_rule
- SV-96563
Checks: C-22876r410977_chk
Verify User ownership, Group ownership, and permissions on the "<MongoDB auditLog directory>": > ls –ald <MongoDB auditLog data directory> If the User owner is not "mongod", this is a finding. If the Group owner is not "mongod", this is a finding. If the directory is more permissive than "700", this is a finding. (The path for the MongoDB auditLog directory will vary according to local circumstances. The auditLog directory will be found in the MongoDB configuration file whose default location is '/etc/mongod.conf'.) To find the auditLog directory name, view and search for the entry in the MongoDB configuration file for the auditLog.path: Example: auditLog: destination: file format: BSON path: /var/lib/mongo/auditLog.bson Given the example above, to find the auditLog directory name run the following command: > dirname /var/lib/mongo/auditLog.bson the output will be the "<MongoDB auditLog directory>" /var/lib/mongo
Fix: F-22865r410978_fix
Run these commands: "chown mongod <MongoDB auditLog directory>" "chgrp mongod <MongoDB auditLog directory>" "chmod 700 <<MongoDB auditLog directory>" (The path for the MongoDB auditLog directory will vary according to local circumstances. The auditLog directory will be found in the MongoDB configuration file whose default location is '/etc/mongod.conf'.) To find the auditLog directory name, view and search for the entry in the MongoDB configuration file for the auditLog.path: Example: auditLog: destination: file format: BSON path: /var/lib/mongo/auditLog.bson Given the example above, to find the auditLog directory name run the following command: > dirname /var/lib/mongo/auditLog.bson the output will be the "<MongoDB auditLog directory>" /var/lib/mongo
- RMF Control
- AU-9
- Severity
- M
- CCI
- CCI-001493
- Version
- MD3X-00-000220
- Vuln IDs
-
- V-221162
- V-81851
- Rule IDs
-
- SV-221162r410982_rule
- SV-96565
Checks: C-22877r410980_chk
Verify User ownership, Group ownership, and permissions on the “<MongoDB configuration file>": (default name and location is '/etc/mongod.conf') (The name and location for the MongoDB configuration file will vary according to local circumstances.) Using the default name and location the command would be: > ls –ald /etc/mongod.conf If the User owner is not "mongod", this is a finding. If the Group owner is not "mongod", this is a finding. If the filename is more permissive than "700", this is a finding.
Fix: F-22866r410981_fix
Run these commands: "chown mongod <MongoDB configuration file>" "chgrp mongod <MongoDB configuration file>" "chmod 700 <<MongoDB configuration file>" (The name and location for the MongoDB configuration file will vary according to local circumstances. The default name and location is '/etc/mongod.conf'.) Using the default name and location the commands would be: > chown mongod /etc/mongod.conf > chgrp mongod /etc/mongod.conf > chmod 700 /etc/mongod.conf
- RMF Control
- CM-5
- Severity
- H
- CCI
- CCI-001499
- Version
- MD3X-00-000250
- Vuln IDs
-
- V-221163
- V-81853
- Rule IDs
-
- SV-221163r822436_rule
- SV-96567
Checks: C-22878r410983_chk
Review procedures for controlling, granting access to, and tracking use of the DBMS software installation account. If access or use of this account is not restricted to the minimum number of personnel required or if unauthorized access to the account has been granted, this is a finding.
Fix: F-22867r410984_fix
Develop, document, and implement procedures to restrict and track use of the DBMS software installation account.
- RMF Control
- CM-5
- Severity
- M
- CCI
- CCI-001499
- Version
- MD3X-00-000260
- Vuln IDs
-
- V-221164
- V-81855
- Rule IDs
-
- SV-221164r410988_rule
- SV-96569
Checks: C-22879r410986_chk
Review the MongoDB software library directory and note other root directories located on the same disk directory or any subdirectories. If any non-MongoDB 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 the MongoDB this is a finding. Only applications that are required for the functioning and administration, not use, of the MongoDB should be located in the same disk directory as the MongoDB software libraries. If other applications are located in the same directory as the MongoDB database this is a finding.
Fix: F-22868r410987_fix
Install all applications on directories separate from the MongoDB software library directory. Relocate any directories or reinstall other application software that currently shares the MongoDB software library directory.
- RMF Control
- CM-5
- Severity
- M
- CCI
- CCI-001499
- Version
- MD3X-00-000270
- Vuln IDs
-
- V-221165
- V-81857
- Rule IDs
-
- SV-221165r531244_rule
- SV-96571
Checks: C-22880r410989_chk
Run the following command to get the roles from a MongoDB database. For each database in MongoDB: use <database> db.getRoles( { rolesInfo: 1, showPrivileges:true, showBuiltinRoles: true } ) Run the following command to the roles assigned to users: use admin db.system.users.find() Analyze the output and if any roles or users have unauthorized access, this is a finding.
Fix: F-22869r410990_fix
Use the following commands to remove unauthorized access to a MongoDB database. db.revokePrivilegesFromRole() db. revokeRolesFromUser() MongoDB commands for role management can be found here: https://docs.mongodb.com/v3.4/reference/method/js-role-management/
- RMF Control
- CM-7
- Severity
- M
- CCI
- CCI-000381
- Version
- MD3X-00-000280
- Vuln IDs
-
- V-221166
- V-81859
- Rule IDs
-
- SV-221166r410994_rule
- SV-96573
Checks: C-22881r410992_chk
Review the list of components and features installed with the MongoDB database. If unused components are installed and are not documented and authorized, this is a finding. RPM can also be used to check to see what is installed: yum list installed | grep mongodb This returns MongoDB database packages that have been installed. If any packages displayed by this command are not being used, this is a finding.
Fix: F-22870r410993_fix
On data-bearing nodes and arbiter nodes, the mongodb-enterprise-tools, mongodb-enterprise-shell and mongodb-enterprise-mongos can be removed (or not installed). On applications servers that typically run the mongos process when connecting to a shared cluster, the only package required is the mongodb-enterprise-mongos package.
- RMF Control
- CM-7
- Severity
- M
- CCI
- CCI-000381
- Version
- MD3X-00-000290
- Vuln IDs
-
- V-221167
- V-81861
- Rule IDs
-
- SV-221167r410997_rule
- SV-96575
Checks: C-22882r410995_chk
In the MongoDB database configuration file (default location: /etc/mongod.conf), review the following parameters: net: http: enabled: true JSONPEnabled: true RESTInterfaceEnabled: true If any of the <booleans> are "True" or "Enabled", this is a finding.
Fix: F-22871r410996_fix
In the MongoDB database configuration file (default location: /etc/mongod.conf), ensure the following parameters either: Does not exist in the file OR Are set to "false" as shown below: http: enabled: false JSONPEnabled: false RESTInterfaceEnabled: false
- RMF Control
- IA-2
- Severity
- M
- CCI
- CCI-000764
- Version
- MD3X-00-000310
- Vuln IDs
-
- V-221168
- V-81863
- Rule IDs
-
- SV-221168r411000_rule
- SV-96577
Checks: C-22883r410998_chk
To view another user’s information, you must have the "viewUser" action on the other user’s database. For each database in the system, run the following command: db.getUsers() Ensure each user identified is a member of an appropriate organization that can access the database. If a user is found not be a member or an appropriate organization that can access the database, this is a finding. Verify that the MongoDB configuration file (default location: /etc/mongod.conf) contains the following: security: authorization: "enabled" If this parameter is not present, this is a finding.
Fix: F-22872r410999_fix
Prereq: To drop a user from a database, must have the "dropUser" action on the database. For any user not a member of an appropriate organization and has access to a database in the system run the following command: // Change to the appropriate database use <database> db.dropUser(<username>, {w: "majority", wtimeout: 5000} If the MongoDB configuration file (default location: /etc/mongod.conf) does not contain security: authorization: "enabled" Edit the MongoDB configuration file, add these parameters, stop/start (restart) any mongod or mongos process using this MongoDB configuration file.
- RMF Control
- IA-5
- Severity
- H
- CCI
- CCI-000192
- Version
- MD3X-00-000320
- Vuln IDs
-
- V-221169
- V-81865
- Rule IDs
-
- SV-221169r822437_rule
- SV-96579
Checks: C-22884r411001_chk
If MongoDB is using Native LDAP authentication where the LDAP server is configured to enforce password complexity and lifetime, this is not a finding. If MongoDB is using Kerberos authentication where Kerberos is configured to enforce password complexity and lifetime, this is not a finding. If MongoDB is configured for SCRAM-SHA1, MONGODB-CR, LDAP Proxy authentication, this is a finding. See: https://docs.mongodb.com/v3.4/core/authentication/#authentication-methods
Fix: F-22873r411002_fix
Either configure MongoDB for Native LDAP authentication where LDAP is configured to enforce password complexity and lifetime. OR Configure MongoDB Kerberos authentication where Kerberos is configured to enforce password complexity and lifetime.
- RMF Control
- IA-5
- Severity
- H
- CCI
- CCI-000196
- Version
- MD3X-00-000330
- Vuln IDs
-
- V-221170
- V-81867
- Rule IDs
-
- SV-221170r822438_rule
- SV-96581
Checks: C-22885r411004_chk
MongoDB supports x.509 certificate authentication for use with a secure TLS/SSL connection. The x.509 client authentication allows clients to authenticate to servers with certificates rather than with a username and password. If X.509 authentication is not used, a SCRAM-SHA-1 authentication protocol is also available. The SCRAM-SHA-1 protocol uses one-way, salted hash functions for passwords as documented here: https://docs.mongodb.com/v3.4/core/security-scram-sha-1/ To authenticate with a client certificate, you must first add a MongoDB user that corresponds to the client certificate. See Add x.509 Certificate subject as a User as documented here: https://docs.mongodb.com/v3.4/tutorial/configure-x509-client-authentication/ To authenticate, use the db.auth() method in the $external database, specifying "MONGODB-X509" for the mechanism field, and the user that corresponds to the client certificate for the user field. If the mechanism field is not set to "MONGODB-X509", this is a finding.
Fix: F-22874r411005_fix
Do the following: - Create local CA and signing keys. - Generate and sign server certificates for member authentication. - Generate and sign client certificates for client authentication. - Start MongoDB cluster in non-auth mode. - Set up replica set and initial users. - Restart MongoDB replica set in X.509 mode using server certificates. Example shown here for x.509 Authentication: https://www.mongodb.com/blog/post/secure-mongodb-with-x-509-authentication Additionally, SSL/TLS must be on as documented here: https://docs.mongodb.com/v3.4/tutorial/configure-ssl/
- RMF Control
- IA-5
- Severity
- H
- CCI
- CCI-000185
- Version
- MD3X-00-000340
- Vuln IDs
-
- V-221171
- V-81869
- Rule IDs
-
- SV-221171r822440_rule
- SV-96583
Checks: C-22886r411007_chk
In the MongoDB database configuration file (default location: /etc/mongod.conf), review the following parameters: net: ssl: mode: requireSSL PEMKeyFile: /etc/ssl/mongodb.pem CAFile: /etc/ssl/mongodbca.pem If the "CAFile" parameter is not present, this is a finding. If the "allowInvalidCertificates" parameter is found, this is a finding. net: ssl: allowInvalidCertificates: true
Fix: F-22875r822439_fix
In the MongoDB database configuration file (default location: /etc/mongod.conf) ensure the following parameters are set and configured correctly: net: ssl: mode: requireSSL PEMKeyFile: /etc/ssl/mongodb.pem CAFile: /etc/ssl/mongodbca.pem Remove any occurrence of the "allowInvalidCertificates" parameter: net: ssl: allowInvalidCertificates: true Stop/start (restart) the mongod or mongos instance using this configuration.
- RMF Control
- IA-5
- Severity
- H
- CCI
- CCI-000186
- Version
- MD3X-00-000360
- Vuln IDs
-
- V-221172
- V-81871
- Rule IDs
-
- SV-221172r457869_rule
- SV-96585
Checks: C-22887r457867_chk
In the MongoDB database configuration file (default location: /etc/mongod.conf), review the following parameters: net: ssl: mode: requireSSL PEMKeyFile: /etc/ssl/mongodb.pem CAFile: /etc/ssl/mongodbca.pem Verify ownership, group ownership, and permissions on the file given for PEMKeyFile (default 'mongodb.pem'). Run following command and review its output: ls -al /etc/mongod.conf typical output: -rw------- 1 mongod mongod 566 Apr 26 20:20 /etc/mongod.conf If the user owner is not "mongod", this is a finding. If the group owner is not "mongod", this is a finding. If the file is more permissive than "600", this is a finding. Verify ownership, group ownership, and permissions on the file given for CAFile (default 'ca.pem'). If the user owner is not "mongod", this is a finding. If the group owner is not "mongod", this is a finding. If the file is more permissive than "600", this is a finding.
Fix: F-22876r457868_fix
Run these commands: "chown mongod:mongod /etc/ssl/mongodb.pem" "chmod 600 /etc/ssl/mongodb.pem" "chown mongod:mongod /etc/ssl/mongodbca.pem" "chmod 600 /etc/ssl/mongodbca.pem"
- RMF Control
- IA-5
- Severity
- M
- CCI
- CCI-000187
- Version
- MD3X-00-000370
- Vuln IDs
-
- V-221173
- V-81873
- Rule IDs
-
- SV-221173r411015_rule
- SV-96587
Checks: C-22888r411013_chk
To authenticate with a client certificate, you must first add the value of the subject from the client certificate as a MongoDB user. Each unique x.509 client certificate corresponds to a single MongoDB user; i.e. you cannot use a single client certificate to authenticate more than one MongoDB user. Login to MongoDB and run the following command: use $external db.getUsers() If the output does not contain a Relative Distinguished Name (RDN) for an authorized user, this is a finding. If the output shows a Relative Distinguished Name (RDN) for users that are not authorized, this is a finding.
Fix: F-22877r411014_fix
Add x.509 Certificate subject as an authorized user. To authenticate with a client certificate, you must first add the value of the subject from the client certificate as a MongoDB user. Each unique x.509 client certificate corresponds to a single MongoDB user; i.e. you cannot use a single client certificate to authenticate more than one MongoDB user. Note: The RDNs in the subject string must be compatible with the RFC2253 standard. Retrieve the RFC2253 formatted subject from the client certificate with the following command: openssl x509 -in <pathToClient PEM> -inform PEM -subject -nameopt RFC2253 The command returns the subject string as well as certificate: subject= CN=myName,OU=myOrgUnit,O=myOrg,L=myLocality,ST=myState,C=myCountry -----BEGIN CERTIFICATE----- # ... -----END CERTIFICATE----- Add the RFC2253 compliant value of the subject as a user. Omit spaces as needed. For example, in the mongo shell, to add the user with both the "readWrite" role in the test database and the "userAdminAnyDatabase" role which is defined only in the admin database: db.getSiblingDB("$external").runCommand( { createUser: "CN=myName,OU=myOrgUnit,O=myOrg,L=myLocality,ST=myState,C=myCountry", roles: [ { role: 'readWrite', db: 'test' }, { role: 'userAdminAnyDatabase', db: 'admin' } ], writeConcern: { w: "majority" , wtimeout: 5000 } } ) In the above example, to add the user with the "readWrite" role in the test database, the role specification document specified "test" in the "db" field. To add "userAdminAnyDatabase" role for the user, the above example specified "admin" in the "db" field. Note: Some roles are defined only in the admin database, including: clusterAdmin, readAnyDatabase, readWriteAnyDatabase, dbAdminAnyDatabase, and userAdminAnyDatabase. To add a user with these roles, specify "admin" in the "db" field. See Manage Users and Roles for details on adding a user with roles. To remove a user that is not authorized run the following command: use $external db.dropUser("<RDN of user>")
- RMF Control
- IA-7
- Severity
- H
- CCI
- CCI-000803
- Version
- MD3X-00-000380
- Vuln IDs
-
- V-221174
- V-81875
- Rule IDs
-
- SV-221174r411018_rule
- SV-96589
Checks: C-22889r411016_chk
If MongoDB is deployed in a classified environment: In the MongoDB database configuration file (default location: /etc/mongod.conf), search for and review the following parameters: net: ssl: FIPSMode: true If this parameter is not present in the configuration file, this is a finding. If "FIPSMode" is set to "false", this is a finding. Check the server log file for a message that FIPS is active: Search the log for the following text ""FIPS 140-2 mode activated"". If this text is not found, this is a finding. Verify that FIPS has been enabled at the operating system. The following will return "1" if FIPS is enabled: cat /proc/sys/crypto/fips_enabled If the above command does not return "1", this is a finding.
Fix: F-22878r411017_fix
Enable FIPS 140-2 mode for MongoDB Enterprise. Edit the MongoDB database configuration file (default location: /etc/mongod.conf) to contain the following parameter setting: net: ssl: FIPSMode: true Stop/start (restart) the mongod or mongos instance using this configuration. For the operating system finding, please refer to the appropriate operating system documentation for the procedure to install, configure, and test FIPS mode.
- RMF Control
- IA-8
- Severity
- M
- CCI
- CCI-000804
- Version
- MD3X-00-000390
- Vuln IDs
-
- V-221175
- V-81877
- Rule IDs
-
- SV-221175r411021_rule
- SV-96591
Checks: C-22890r411019_chk
MongoDB grants access to data and commands through role-based authorization and provides built-in roles that provide the different levels of access commonly needed in a database system. You can additionally create user-defined roles. Check a user's role to ensure correct privileges for the function: Prereq: To view a user's roles, you must have the "viewUser" privilege. Connect to MongoDB. For each database in the system, identify the user's roles for the database: use <database> db.getUser("[username]") The server will return a document with the user's roles. View a role's privileges: Prereq: To view a user's roles, you must have the "viewUser" privilege. For each database, identify the privileges granted by a role: use <database> db.getRole( "read", { showPrivileges: true } ) The server will return a document with the "privileges" and "inheritedPrivileges" arrays. The "privileges returned document lists the privileges directly specified by the role and excludes those privileges inherited from other roles. The "inheritedPrivileges" returned document lists all privileges granted by this role, both directly specified and inherited. If the role does not inherit from other roles, the two fields are the same. If a user has a role with inappropriate privileges, this is a finding.
Fix: F-22879r411020_fix
Prereq: To view a user's roles, must have the "viewUser" privilege. Connect to MongoDB. For each database, identify the user's roles for the database. use <database> db.getUser("[username]") The server will return a document with the user's roles. To revoke a user's role from a database use the db.revokeRolesFromUser() method. To grant a role to a user use the db.grantRolesToUser() method.
- RMF Control
- SC-23
- Severity
- M
- CCI
- CCI-001188
- Version
- MD3X-00-000410
- Vuln IDs
-
- V-221176
- V-81879
- Rule IDs
-
- SV-221176r411024_rule
- SV-96593
Checks: C-22891r411022_chk
Check the MongoDB configuration file (default location: /etc/mongod.conf). The following should be set: net: ssl: mode: requireSSL If this is not found in the MongoDB configuration file, this is a finding.
Fix: F-22880r411023_fix
Follow the documentation guide at https://docs.mongodb.com/v3.4/tutorial/configure-ssl/. Stop/start (restart) and mongod or mongos using the MongoDB configuration file.
- RMF Control
- SC-24
- Severity
- M
- CCI
- CCI-001190
- Version
- MD3X-00-000420
- Vuln IDs
-
- V-221177
- V-81881
- Rule IDs
-
- SV-221177r411027_rule
- SV-96595
Checks: C-22892r411025_chk
Journaling is enabled by default in 64-bit systems. With journaling enabled, if mongod stops unexpectedly, the program can recover everything written to the journal. MongoDB will re-apply the write operations on restart and maintain a consistent state. By default, the greatest extent of lost writes, i.e., those not made to the journal, are those made in the last 100 milliseconds, plus the time it takes to perform the actual journal writes. Verify the mongod process startup options. If the mongod process was started with the "--nojournal" option, this is a finding.
Fix: F-22881r411026_fix
Modify the mongod startup command-line options by removing the "--nojournal" option. Edit the MongoDB database configuration file (default location: /etc/mongod.conf) to ensure it contains the following parameter setting: storage: journal: enabled: true Stop/start (restart) any or all mongod processes.
- RMF Control
- SC-28
- Severity
- H
- CCI
- CCI-001199
- Version
- MD3X-00-000440
- Vuln IDs
-
- V-221178
- V-81883
- Rule IDs
-
- SV-221178r822441_rule
- SV-96597
Checks: C-22893r411028_chk
If the MongoDB Encrypted Storage Engines is being used, ensure that the "security.enableEncryption" option is set to "true" in the MongoDB configuration file (default location: /etc/mongod.conf) or that MongoDB was started with the "--enableEncryption" command line option. Check the MongoDB configuration file (default location: /etc/mongod.conf). If the following parameter is not present, this is a finding. security: enableEncryption: "true" If any mongod process is started with "--enableEncryption false", this is a finding.
Fix: F-22882r411029_fix
Ensure that the MongoDB Configuration file (default location: /etc/mongod.conf) has the following set: security: enableEncryption: "true" Ensure that any mongod process that contains the option "--enableEcryption" has "true" as its parameter <boolean> value (e.g., "--enableEncryption true"). Stop/start (restart) and mongod process using either the MongoDB configuration file or that contains the "--enableEncryption" option.
- RMF Control
- SC-4
- Severity
- M
- CCI
- CCI-001090
- Version
- MD3X-00-000460
- Vuln IDs
-
- V-221179
- V-81885
- Rule IDs
-
- SV-221179r411033_rule
- SV-96599
Checks: C-22894r411031_chk
Review the procedures for the refreshing of development/test data from production. Review any scripts or code that exists for the movement of production data to development/test systems, or to any other location or for any other purpose. Verify that copies of production data are not left in unprotected locations. If the code that exists for data movement does not comply with the organization-defined data transfer policy and/or fails to remove any copies of production data from unprotected locations, this is a finding.
Fix: F-22883r411032_fix
Modify any code used for moving data from production to development/test systems to comply with the organization-defined data transfer policy, and to ensure copies of production data are not left in unsecured locations.
- RMF Control
- SC-4
- Severity
- M
- CCI
- CCI-001090
- Version
- MD3X-00-000470
- Vuln IDs
-
- V-221180
- V-81887
- Rule IDs
-
- SV-221180r411036_rule
- SV-96601
Checks: C-22895r411034_chk
Verify the permissions for the following database files or directories: MongoDB default configuration file: "/etc/mongod.conf" MongoDB default data directory: "/var/lib/mongo" If the owner and group are not both "mongod", this is a finding. If the file permissions are more permissive than "755", this is a finding.
Fix: F-22884r411035_fix
Correct the permission to the files and/or directories that are in violation. MongoDB Configuration file (default location): chown mongod:mongod /etc/mongod.conf chmod 755 /etc/mongod.conf MongoDB data file directory (default location): chown -R mongod:mongod/var/lib/mongo chmod -R 755/var/lib/mongo
- RMF Control
- SI-10
- Severity
- M
- CCI
- CCI-001310
- Version
- MD3X-00-000490
- Vuln IDs
-
- V-221181
- V-81889
- Rule IDs
-
- SV-221181r411039_rule
- SV-96603
Checks: C-22896r411037_chk
As a client program assembles a query in MongoDB, it builds a BSON object, not a string. Thus traditional SQL injection attacks are not a problem. However, MongoDB operations permit arbitrary JavaScript expressions to be run directly on the server. If the "security.javascriptEnabled" option is set to "true" in the config file, this is a finding. Starting with MongoDB 3.2, database-level document validation can be configured for specific collections. Configured validation rules for the selected database can be viewed via the db.getSisterDB("database_name").getCollectionInfos() command in mongo shell. If validation is desired, but no rules are set, the valdiationAction is not "error" or the "bypassDocumentValidation" option is used for write commands on the application side, this is a finding.
Fix: F-22885r411038_fix
Disable the javascriptEnabled option in the config file. security: javascriptEnabled: false If document validation is needed, it should be configured according to the documentation page at https://docs.mongodb.com/manual/core/document-validation/.
- RMF Control
- SI-10
- Severity
- M
- CCI
- CCI-001310
- Version
- MD3X-00-000500
- Vuln IDs
-
- V-221182
- V-81891
- Rule IDs
-
- SV-221182r411042_rule
- SV-96605
Checks: C-22897r411040_chk
MongoDB operations permit arbitrary JavaScript expressions to be run directly on the server. If the following parameter is not present or not set as show below in the MongoDB configuration file (default location: /etc/mongod.conf), this is a finding. security: javascriptEnabled: "false"
Fix: F-22886r411041_fix
Disable the "javascriptEnabled" option. Edit the MongoDB configuration file (default location: /etc/mongod.conf" to include the following: security: javascriptEnabled: false
- RMF Control
- SI-11
- Severity
- M
- CCI
- CCI-001312
- Version
- MD3X-00-000520
- Vuln IDs
-
- V-221183
- V-81893
- Rule IDs
-
- SV-221183r411045_rule
- SV-96607
Checks: C-22898r411043_chk
Check custom database code to verify that error messages do not contain information beyond what is needed for troubleshooting the issue. If custom database errors contain PII data, sensitive business data, or information useful for identifying the host system or database structure, this is a finding. When attempting to login with incorrect credentials, the user will receive an error message that the operation was unauthorized. If a user is attempting to perform an operation for which they do not have privileges, the database will return an error message that the operation is not authorized.
Fix: F-22887r411044_fix
Configure custom database code and associated application code not to divulge sensitive information or information useful for system identification in error messages.
- RMF Control
- SI-11
- Severity
- M
- CCI
- CCI-001314
- Version
- MD3X-00-000530
- Vuln IDs
-
- V-221184
- V-81895
- Rule IDs
-
- SV-221184r411048_rule
- SV-96609
Checks: C-22899r411046_chk
A mongod or mongos running with "security.redactClientLogData" redacts any message accompanying a given log event before logging. This prevents the mongod or mongos from writing potentially sensitive data stored on the database to the diagnostic log. Metadata such as error or operation codes, line numbers, and source file names are still visible in the logs. Verify that the MongoDB configuration file (default location: /etc/mongod.conf) contains the following: security: redactClientLogData: "true" If this parameter is not present, this is a finding.
Fix: F-22888r411047_fix
Edit the MongoDB configuration file (default location: /etc/mongod.conf) and add the following parameter "redactClientLogData" in the security section of that file: security: redactClientLogData: "true" Stop/start (restart) any mongod or mongos using the MongoDB configuration file.
- RMF Control
- AC-16
- Severity
- M
- CCI
- CCI-002262
- Version
- MD3X-00-000540
- Vuln IDs
-
- V-221185
- V-81897
- Rule IDs
-
- SV-221185r411051_rule
- SV-96611
Checks: C-22900r411049_chk
MongoDB supports role-based access control at the collection level. If enabled, the database process should be started with "security.authorization:enabled" in the config file or with "--auth" in the command line. For documents that have been labeled (e.g., {"tag" : "classified"}), read-only views can be created and secured via access privileges such that a user can only view those documents that have a specific tag or tags (e.g., user x can only view records that are labeled with the tag of classified). Existing views can be listed using the db.getCollectionInfos() command for the selected database in mongo shell. If a view is not present for the collection requiring security labeling, this is a finding. MongoDB supports field-level redaction that allows the application to indicate to the database whether or not certain fields should be returned based on values in the field labels. If desired and aggregation queries in the application code are not using the $redact stage with appropriate logic, this is a finding.
Fix: F-22889r411050_fix
Follow the documentation page to setup RBAC:https://docs.mongodb.com/manual/core/authorization/. For the required collections, create specific read-only views that allow access to only a subset of the data in a collection as documented here: https://docs.mongodb.com/manual/core/views/. Permissions on the view are specified separately from the permissions on the underlying collection. Use the "$redact" operator to restrict the contents of the documents based on information stored in the documents themselves as documented here: https://docs.mongodb.com/master/reference/operator/aggregation/redact/
- RMF Control
- AC-3
- Severity
- M
- CCI
- CCI-002165
- Version
- MD3X-00-000570
- Vuln IDs
-
- V-221186
- V-81899
- Rule IDs
-
- SV-221186r411054_rule
- SV-96613
Checks: C-22901r411052_chk
Review the system documentation to obtain the definition of the database/DBMS functionality considered privileged in the context of the system in question. If any functionality considered privileged has access privileges granted to non-privileged users, this is a finding.
Fix: F-22890r411053_fix
Revoke any roles with unnecessary privileges to privileged functionality by executing the revoke command as documented here: https://docs.mongodb.com/v3.4/reference/method/db.revokeRolesFromUser/ Revoke any unnecessary privileges from any roles by executing the revoke command as document here: https://docs.mongodb.com/v3.4/reference/method/db.revokePrivilegesFromRole/ If a new role with associated privileges needs to be created, follow the documentation here: https://docs.mongodb.com/v3.4/reference/command/createRole/
- RMF Control
- AU-3
- Severity
- M
- CCI
- CCI-001844
- Version
- MD3X-00-000600
- Vuln IDs
-
- V-221188
- V-81903
- Rule IDs
-
- SV-221188r411060_rule
- SV-96617
Checks: C-22903r411058_chk
MongoDB can be configured to write audit events to the syslog in Linux, but this is not available in Windows. Audit events can also be written to a file in either JSON on BSON format. Through the use of third-party tools or via syslog directly, audit records can be pushed to a centralized log management system. If a centralized tool for log management is not installed and configured to collect audit logs or syslogs, this is a finding.
Fix: F-22892r411059_fix
Install a centralized syslog collecting tool and configured it as instructed in its documentation. To enable auditing and print audit events to the syslog in JSON format, specify the syslog for the --auditDestination setting: mongod --dbpath data/db --auditDestination syslog Alternatively, these options can also be specified in the configuration file: storage: dbPath: data/db auditLog: destination: syslog
- RMF Control
- AU-4
- Severity
- M
- CCI
- CCI-001849
- Version
- MD3X-00-000620
- Vuln IDs
-
- V-221189
- V-81905
- Rule IDs
-
- SV-221189r411063_rule
- SV-96619
Checks: C-22904r411061_chk
Investigate whether there have been any incidents where MongoDB ran out of audit log space since the last time the space was allocated or other corrective measures were taken. If there have been incidents where MongoDB ran out of audit log space, this is a finding. A MongoDB audit log that is configured to be stored in a file is identified in the MongoDB configuration file (default: /etc/mongod.conf) under the "auditLog:" key and subkey "destination:" where "destination" is "file". If this is the case then the "AuditLog:" subkey "path:" determines where (device/directory) that file will be located. View the mongodb configuration file (default location: /etc/mongod.conf) and identify how the "auditlog.destination" is configured. When the "auditlog.destination" is "file", this is a finding.
Fix: F-22893r411062_fix
View the mongodb configuration file (default location: /etc/mongod.conf) and view the "auditlog.path" to identify the storage volume. Allocate sufficient space to the storage volume hosting the file identified in the MongoDB configuration "auditLog.path" to support audit file peak demand.
- RMF Control
- AU-5
- Severity
- M
- CCI
- CCI-001855
- Version
- MD3X-00-000630
- Vuln IDs
-
- V-221190
- V-81907
- Rule IDs
-
- SV-221190r411066_rule
- SV-96621
Checks: C-22905r411064_chk
A MongoDB audit log that is configured to be stored in a file is identified in the MongoDB configuration file (default: /etc/mongod.conf) under the "auditLog:" key and subkey "destination:" where "destination" is "file". If this is the case then the "AuditLog:" subkey "path:" determines where (device/directory) that file will be located. View the mongodb configuration file (default location: /etc/mongod.conf) and identify how the "auditlog.destination" is configured. When the "auditlog.destination" is "file", this is a finding.
Fix: F-22894r411065_fix
View the mongodb configuration file (default location: /etc/mongod.conf) and view the "auditlog.path" to identify the storage volume. Install MongoDB Ops Manager or other organization approved monitoring software. Configure the required alert in the monitoring software to send an alert where storage volume holding the auditLog file utilization reaches 75%.
- RMF Control
- CM-11
- Severity
- M
- CCI
- CCI-001812
- Version
- MD3X-00-000650
- Vuln IDs
-
- V-221191
- V-81909
- Rule IDs
-
- SV-221191r411069_rule
- SV-96623
Checks: C-22906r411067_chk
If MongoDB supports only software development, experimentation, and/or developer-level testing (that is, excluding production systems, integration testing, stress testing, and user acceptance testing), this is not a finding. Review the MongoDB security settings with respect to non-administrative users' ability to create, alter, or replace functions or views. These MongoDB commands can help with showing existing roles and permissions of users of the databases. db.getRoles( { rolesInfo: 1, showPrivileges:true, showBuiltinRoles: true }) If any such permissions exist and are not documented and approved, this is a finding.
Fix: F-22895r411068_fix
Revoke any roles with unnecessary privileges to privileged functionality by executing the revoke command. Revoke any unnecessary privileges from any roles by executing the revoke command. Create, as needed, new role(s) with associated privileges.
- RMF Control
- CM-5
- Severity
- M
- CCI
- CCI-001813
- Version
- MD3X-00-000670
- Vuln IDs
-
- V-221192
- V-81911
- Rule IDs
-
- SV-221192r411072_rule
- SV-96625
Checks: C-22907r411070_chk
Review the security configuration of the MongoDB database(s). If unauthorized users can start the mongod or mongos processes or edit the MongoDB configuration file (default location: /etc/mongod.conf), this is a finding. If MongoDB does not enforce access restrictions associated with changes to the configuration of the database(s), this is a finding. To assist in conducting reviews of permissions, the following MongoDB commands describe permissions of databases and users: Permissions of concern in this respect include the following, and possibly others: - any user with a role of userAdminAnyDatabase role or userAdmin role - any database or with a user have a role or privilege with "C" (create) or "w" (update) privileges that are not necessary MongoDB commands to view roles in a particular database: db.getRoles( { rolesInfo: 1, showPrivileges:true, showBuiltinRoles: true })
Fix: F-22896r411071_fix
Prereq: To view a user's roles, must have the "viewUser" privilege. https://docs.mongodb.com/v3.4/reference/privilege-actions/ Connect to MongoDB. For each database, identify the user's roles for the database. use <database> db.getUser("[username]") The server will return a document with the user's roles. To revoke a user's role from a database use the db.revokeRolesFromUser() method. https://docs.mongodb.com/v3.4/reference/method/db.revokeRolesFromUser/ To grant a role to a user use the db.grantRolesToUser() method. https://docs.mongodb.com/v3.4/reference/method/db.grantRolesToUser/
- RMF Control
- IA-11
- Severity
- M
- CCI
- CCI-002038
- Version
- MD3X-00-000700
- Vuln IDs
-
- V-221193
- V-81913
- Rule IDs
-
- SV-221193r411075_rule
- SV-96627
Checks: C-22908r411073_chk
If organization-defined circumstances or situations require reauthentication, and these situations are not configured to terminate existing logins to require reauthentication, this is a finding.
Fix: F-22897r411074_fix
Determine the organization-defined circumstances or situations that require reauthentication and ensure that the mongod and mongos processes are stopped/started (restart).
- RMF Control
- IA-5
- Severity
- M
- CCI
- CCI-002007
- Version
- MD3X-00-000710
- Vuln IDs
-
- V-221194
- V-81915
- Rule IDs
-
- SV-221194r411078_rule
- SV-96629
Checks: C-22909r411076_chk
If MongoDB is configured to authenticate using SASL and LDAP/Active Directory check the saslauthd command line options in the system boot script that starts saslauthd (the location will be dependent on the specific Linux operating system and boot script layout and naming conventions). If the "-t" option is not set for the "saslauthd" process in the system boot script, this is a finding. If any mongos process is running (a MongoDB shared cluster) the "userCacheInvalidationIntervalSecs" option can be used to specify the cache timeout. The default is "30" seconds and the minimum is "1" second.
Fix: F-22898r411077_fix
If MongoDB is configured to authenticate using SASL and LDAP/Active Directory modify and restart the saslauthd command line options in the system boot script and set the "-t" option to the appropriate timeout in seconds. From the Linux Command line (with root/sudo privs) run the following command to restart the saslauthd process after making the change for the "-t" parameter: systemctl restart saslauthd If any mongos process is running (a MongoDB shared cluster) the "userCacheInvalidationIntervalSecs" option to adjust the timeout in seconds can be changed from the default "30" seconds. This is accomplished by modifying the mongos configuration file (default location: /etc/mongos.conf) and then restarting mongos.
- RMF Control
- SC-23
- Severity
- M
- CCI
- CCI-002470
- Version
- MD3X-00-000730
- Vuln IDs
-
- V-221195
- V-81917
- Rule IDs
-
- SV-221195r411081_rule
- SV-96631
Checks: C-22910r411079_chk
To run MongoDB in SSL mode, you have to obtain a valid certificate singed by a single certificate authority. Before starting the MongoDB database in SSL mode, verify that certificate used is issued by a valid DoD certificate authority (openssl x509 -in <path_to_certificate_pem_file> -text | grep -i "issuer"). If there is any issuer present in the certificate that is not a DoD approved certificate authority, this is a finding.
Fix: F-22899r411080_fix
Remove any certificate that was not issued by an approved DoD certificate authority. Contact the organization's certificate issuer and request a new certificate that is issued by a valid DoD certificate authorities.
- RMF Control
- SC-28
- Severity
- M
- CCI
- CCI-002475
- Version
- MD3X-00-000740
- Vuln IDs
-
- V-221196
- V-81919
- Rule IDs
-
- SV-221196r411084_rule
- SV-96633
Checks: C-22911r411082_chk
Review the documentation and/or specification for the organization-defined information. If any data is PII, classified or is deemed by the organization to be encrypted at rest, this is a finding. Verify the mongod command line contain the following options: --enableEncryption --kmipServerName <KMIP Server HostName> --kmipPort <KMIP server port> --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem If these above options are not part of the mongod command line, this is a finding. Items in the <> above and starting with kmip* are specific to the KMIP appliance and need to be set according to the KMIP appliance configuration.
Fix: F-22900r411083_fix
Configure MongoDB to use the Encrypted Storage Engine and a KMIP appliance as documented here: https://docs.mongodb.com/v3.4/core/security-encryption-at-rest/ https://docs.mongodb.com/v3.4/tutorial/configure-encryption/
- RMF Control
- SC-8
- Severity
- M
- CCI
- CCI-002420
- Version
- MD3X-00-000760
- Vuln IDs
-
- V-221197
- V-81921
- Rule IDs
-
- SV-221197r411087_rule
- SV-96635
Checks: C-22912r411085_chk
Review the system information/specification for information indicating a strict requirement for data integrity and confidentiality when data is being prepared to be transmitted. If such information is absent therein, this is not a finding. If such information is present, inspect the MongoDB configuration file (default location: /etc/mongod.conf) for the following entries: net: ssl: mode: requireSSL PEMKeyFile: /etc/ssl/mongodb.pem If net.ssl.mode is not set to "requireSSL", this is a finding.
Fix: F-22901r411086_fix
Stop the MongoDB instance if it is running. Obtain a certificate from a valid DoD certificate authority to be used for encrypted data transmission. Modify the MongoDB configuration file with ssl configuration options such as: net: ssl: mode: requireSSL PEMKeyFile: /etc/ssl/mongodb.pem Set "net.ssl.mode" to the "requireSSL". Set "net.ssl.KeyFile" to the full path of the certificate (.pem) file. Start/stop (restart) all mongod or mongos instances using the MongoDB configuration file (default location: /etc/mongod.conf).
- RMF Control
- SC-8
- Severity
- M
- CCI
- CCI-002422
- Version
- MD3X-00-000770
- Vuln IDs
-
- V-221198
- V-81923
- Rule IDs
-
- SV-221198r411090_rule
- SV-96637
Checks: C-22913r411088_chk
If the data owner does not have a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process, this is not a finding. If such strict requirement for ensure data integrity and confidentially is present, inspect the MongoDB configuration file (default location: /etc/mongod.conf) for the following entries: net: ssl: mode: requireSSL PEMKeyFile: /etc/ssl/mongodb.pem If net.ssl.mode is not set to "requireSSL", this is a finding.
Fix: F-22902r411089_fix
Obtain a certificate from a valid DoD certificate authority to be used for encrypted data transmission. Modify the MongoDB configuration file (default location: /etc/mongod.conf) with the network configuration options. net: ssl: mode: requireSSL PEMKeyFile: /etc/ssl/mongodb.pem Set "net.ssl.mode" to the "requireSSL". Set "net.ssl.KeyFile" to the full path of the certificate (.pem) file. Start/stop (restart) all mongod or mongos instances using the MongoDB configuration file (default location: /etc/mongod.conf).
- RMF Control
- SI-10
- Severity
- M
- CCI
- CCI-002754
- Version
- MD3X-00-000780
- Vuln IDs
-
- V-221199
- V-81925
- Rule IDs
-
- SV-221199r411093_rule
- SV-96639
Checks: C-22914r411091_chk
As a user with the "dbAdminAnyDatabase" role, execute the following on the database of interest: use myDB db.getCollectionInfos() Where "myDB" is the name of the database on which validator rules are to be inspected. This returns an array of documents containing all collections information within myDB. For each collection's information received. If the "options" sub-document within each does not contain a "validator" sub-document, this is a finding.
Fix: F-22903r411092_fix
Document validation can be added at the time of creation of a collection. Existing collections can also be modified with document validation rules. Use the "validator" option to create or update a collection with the desired validation rules.
- RMF Control
- IA-6
- Severity
- H
- CCI
- CCI-000206
- Version
- MD3X-00-000800
- Vuln IDs
-
- V-221200
- V-81927
- Rule IDs
-
- SV-221200r411096_rule
- SV-96641
Checks: C-22915r411094_chk
For the MongoDB command-line tools "mongo shell", "mongodump", "mongorestore", "mongoimport", "mongoexport", which cannot be configured not to accept a plain-text password, and any other essential tool with the same limitation, verify that the system documentation explains the need for the tool, who uses it, and any relevant mitigations and that AO approval has been obtained. If it is not documented, this is a finding. Request evidence that all users of these MongoDB command-line tools are trained in the use of the "-p" option plain-text password option and how to keep the password protected from unauthorized viewing/capture and that they adhere to this practice. If evidence of training does not exist, this is a finding.
Fix: F-22904r411095_fix
For the "mongo shell", "mongodump", "mongorestore", "mongoimport", "mongoexport", which can accept a plain-text password, and any other essential tool with the same limitation: Document the need for it, who uses it, and any relevant mitigations, and obtain AO approval. Train all users of the tool in the nature of using the plain-text password option and in how to keep the password protected from unauthorized viewing/capture and document they have been trained.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- MD3X-00-001100
- Vuln IDs
-
- V-221201
- V-81929
- Rule IDs
-
- SV-221201r411099_rule
- SV-96643
Checks: C-22916r411097_chk
Review the MongoDB documentation and configuration to determine it is configured in accordance with DoD security configuration and implementation guidance, including STIGs, NSA configuration guides, CTOs, DTMs, and IAVMs. If the MongoDB is not configured in accordance with security configuration settings, this is a finding.
Fix: F-22905r411098_fix
Configure MongoDB in accordance with security configuration settings by reviewing the Operation System and MongoDB documentation and applying the necessary configuration parameters to meet the configurations required by the STIG, NSA configuration guidelines, CTOs, DTMs, and IAVMs.