CIS MongoDB 7 Benchmark v1.1.0 PDF

CIS MongoDB 7
Benchmark
v1.1.0 - 10-24-2024
Internal Only - General

Terms of Use
Please see the below link for our current terms of use:
https://www.cisecurity.org/cis-securesuite/cis-securesuite-membership-terms-of-use/
For information on referencing and/or citing CIS Benchmarks in 3rd party documentation
(including using portions of Benchmark Recommendations) please contact CIS Legal
(CISLegal@cisecurity.org) and request guidance on copyright usage.
NOTE: It is NEVER acceptable to host a CIS Benchmark in ANY format (PDF, etc.)
on a 3rd party (non-CIS owned) site.
Page 1

Table of Contents
Terms of Use ..................................................................................................................... 1
Table of Contents ............................................................................................................. 2
Overview ............................................................................................................................ 4
Important Usage Information .................................................................................................... 4
Target Technology Details ........................................................................................................ 5
Intended Audience ..................................................................................................................... 6
Consensus Guidance................................................................................................................. 7
Typographical Conventions ...................................................................................................... 8
Recommendation Definitions ......................................................................................... 9
Title............................................................................................................................................... 9
Assessment Status .................................................................................................................... 9
Automated ............................................................................................................................................... 9
Manual...................................................................................................................................................... 9
Profile ........................................................................................................................................... 9
Description .................................................................................................................................. 9
Rationale Statement ................................................................................................................... 9
Impact Statement...................................................................................................................... 10
Audit Procedure........................................................................................................................ 10
Remediation Procedure ........................................................................................................... 10
Default Value ............................................................................................................................. 10
References ................................................................................................................................ 10
CIS Critical Security Controls® (CIS Controls®) .................................................................... 10
Additional Information ............................................................................................................. 10
Profile Definitions ..................................................................................................................... 11
Acknowledgements .................................................................................................................. 12
Recommendations ......................................................................................................... 13
1 Installation and Patching ...................................................................................................... 13
1.1 Ensure the appropriate MongoDB software version/patches are installed (Manual).......... 14
2 Authentication ....................................................................................................................... 16
2.1 Ensure Authentication is configured (Automated) ............................................................... 17
2.2 Ensure that MongoDB does not bypass authentication via the localhost exception
(Automated) ............................................................................................................................... 20
2.3 Ensure authentication is enabled in the sharded cluster (Automated) ............................... 22
3 Authorization ......................................................................................................................... 26
3.1 Ensure least privilege for database accounts (Manual) ...................................................... 27
Page 2

3.2 Ensure that role-based access control is enabled and configured appropriately (Manual) 29
3.3 Ensure that MongoDB is run using a non-privileged, dedicated service account (Manual)31
3.4 Ensure that each role for each MongoDB database is needed and grants only the
necessary privileges (Manual) ................................................................................................... 33
3.5 Review Superuser/Admin Roles (Manual) .......................................................................... 35
4 Data Encryption ..................................................................................................................... 37
4.1 Ensure legacy TLS protocols are disabled (Automated)..................................................... 38
4.2 Ensure Weak Protocols are Disabled (Automated) ............................................................ 40
4.3 Ensure Encryption of Data in Transit TLS or SSL (Transport Encryption) (Automated) .... 42
4.4 Ensure Federal Information Processing Standard (FIPS) is enabled (Automated) ............ 45
4.5 Ensure Encryption of Data at Rest (Manual) ....................................................................... 47
5 Audit Logging ........................................................................................................................ 49
5.1 Ensure that system activity is audited (Automated) ............................................................ 50
5.2 Ensure that audit filters are configured properly (Manual) .................................................. 52
5.3 Ensure that logging captures as much information as possible (Automated) ..................... 54
5.4 Ensure that new entries are appended to the end of the log file (Automated) ................... 56
6 Operating System Hardening............................................................................................... 58
6.1 Ensure that MongoDB uses a non-default port (Automated) .............................................. 59
6.2 Ensure that operating system resource limits are set for MongoDB (Manual) ................... 61
6.3 Ensure that server-side scripting is disabled if not needed (Manual) ................................. 63
7 File Permissions .................................................................................................................... 65
7.1 Ensure appropriate key file permissions are set (Manual) .................................................. 66
7.2 Ensure appropriate database file permissions are set. (Manual) ....................................... 68
Appendix: Summary Table ............................................................................................ 70
Appendix: CIS Controls v7 IG 1 Mapped Recommendations ................................... 72
Appendix: CIS Controls v7 Unmapped Recommendations ...................................... 77
Appendix: CIS Controls v8 Unmapped Recommendations ...................................... 83
Appendix: Change History ............................................................................................ 84
Page 3

Overview
All CIS Benchmarks™ focus on technical configuration settings used to maintain and/or
increase the security of the addressed technology, and they should be used in
conjunction with other essential cyber hygiene tasks like:
• Monitoring the base operating system and applications for vulnerabilities and
quickly updating with the latest security patches.
• End-point protection (Antivirus software, Endpoint Detection and Response
(EDR), etc.).
• Logging and monitoring user and system activity.
In the end, the CIS Benchmarks™ are designed to be a key component of a

comprehensive cybersecurity program.
Important Usage Information

All CIS Benchmarks™ are available free for non-commercial use from the CIS Website.
They can be used to manually assess and remediate systems and applications. In lieu
of manual assessment and remediation, there are several tools available to assist with
assessment:
• CIS Configuration Assessment Tool (CIS-CAT® Pro Assessor)
• CIS Benchmarks™ Certified 3rd Party Tooling
These tools make the hardening process much more scalable for large numbers of
systems and applications.
NOTE: Some tooling focuses only on the CIS Benchmarks™ Recommendations that
can be fully automated (skipping ones marked Manual). It is important that
ALL Recommendations (Automated and Manual) be addressed, since all
are important for properly securing systems and are typically in scope for
audits.
In addition, CIS has developed CIS Build Kits for some common technologies to assist
in applying CIS Benchmarks™ Recommendations.
When remediating systems (changing configuration settings on

deployed systems as per the CIS Benchmarks™ Recommendations),
please approach this with caution and test thoroughly.
The following is a reasonable remediation approach to follow:
1. NEVER deploy a CIS Build Kit, or any internally developed remediation method,
to production systems without proper testing.
2. Proper testing consists of the following:
Page 4

a. Understand the configuration (including installed applications) of the
targeted systems.
b. Read the Impact section of the given Recommendation to help determine
if there might be an issue with the targeted systems.
c. Test the configuration changes on representative lab system(s). This way
if there is some issue it can be resolved prior to deploying to any
production systems.
d. When confident, initially deploy to a small sub-set of users and monitor
closely for issues. This way if there is some issue it can be resolved prior
to deploying more broadly.
e. When confident, iteratively deploy to additional groups and monitor closely
for issues until deployment is complete. This way if there is some issue it
can be resolved prior to continuing deployment.
NOTE: CIS and the CIS Benchmarks™ development communities in CIS WorkBench
do their best to test and have high confidence in the Recommendations, but
they cannot test potential conflicts with all possible system deployments.
Known potential issues identified during CIS Benchmarks™ development are
documented in the Impact section of each Recommendation.
By using CIS and/or CIS Benchmarks™ Certified tools, and being careful with
remediation deployment, it is possible to harden large numbers of deployed systems in
a cost effective, efficient, and safe manner.
NOTE: As previously stated, the PDF versions of the CIS Benchmarks™ are
available for free, non-commercial use on the CIS Website. All other formats
of the CIS Benchmarks™ (MS Word, Excel, and Build Kits) are available for
CIS SecureSuite® members.
CIS-CAT® Pro is also available to CIS SecureSuite® members.
Target Technology Details

This document, CIS MongoDB 7.0 Benchmark, provides prescriptive guidance for
establishing a secure configuration posture for MongoDB version/s 7.x.
This guide was tested against MongoDB 7.0.0 running on Ubuntu Linux, Linux Red hat,
and Windows but applies to other distributions as well.
To obtain the latest version of this guide, please visit http://benchmarks.cisecurity.org. If
you have questions, comments, or have identified ways to improve this guide, please
write to us at feedback@cisecurity.org.
Extracting Running Configuration File
To verify the MongoDB running configuration file we need to connect MongoDB
instance using MongoDB client with valid username/password and execute this
command:
Page 5

db.runCommand( { getCmdLineOpts: 1 } )
The response will contain MongoDB running configuration file location. For example:
"config" : "/etc/mongod.conf",
**MongoDB Configuration File Location
**
• For Windows: "\bin\mongod.cfg"

• For macOS: "/usr/local/etc/mongod.conf" (Intel processors) and
"/opt/homebrew/etc/mongod.conf" (Apple M1 processors)
• For Linux: "/etc/mongod.conf"
Important Information
• Automated Assessment Content is provided for Linux platforms only and is set to
look for mongod.conf in path /etc/mongod.conf.
• Mongod: The primary daemon process for the MongoDB system. It handles data
requests, manages data access, and performs background management
operations.
• Mongos: mongos is a routing service for MongoDB Sharded Clusters.mongos
requires mongod config, which stores the metadata of the cluster.MongoDB
Shard Utility, the controller and query router for sharded clusters. Sharding
partitions the data-set into discrete parts.
Intended Audience
This document is intended for system and application administrators, security
specialists, auditors, help desk, and platform deployment personnel who plan to
develop, deploy, assess, or secure solutions that incorporate MongoDB.
Page 6

Consensus Guidance
This CIS Benchmark™ was created using a consensus review process comprised of a
global community of subject matter experts. The process combines real world
experience with data-based information to create technology specific guidance to assist
users to secure their environments. Consensus participants provide perspective from a
diverse set of backgrounds including consulting, software development, audit and
compliance, security research, operations, government, and legal.
Each CIS Benchmark undergoes two phases of consensus review. The first phase
occurs during initial Benchmark development. During this phase, subject matter experts
convene to discuss, create, and test working drafts of the Benchmark. This discussion
occurs until consensus has been reached on Benchmark recommendations. The
second phase begins after the Benchmark has been published. During this phase, all
feedback provided by the Internet community is reviewed by the consensus team for
incorporation in the Benchmark. If you are interested in participating in the consensus
process, please visit https://workbench.cisecurity.org/.
Page 7

Typographical Conventions
The following typographical conventions are used throughout this guide:
Convention Meaning
Used for blocks of code, command, and

Stylized Monospace font script examples. Text should be interpreted
exactly as presented.
Used for inline code, commands, UI/Menu

Monospace font selections or examples. Text should be
interpreted exactly as presented.
Text set in angle brackets denote a variable

<Monospace font in brackets>
requiring substitution for a real value.
Used to reference other relevant settings,

CIS Benchmarks and/or Benchmark
Italic font
Communities. Also, used to denote the title
of a book, article, or other publication.
Additional information or caveats things like

Notes, Warnings, or Cautions (usually just
Bold font
the word itself and the rest of the text
normal).
Page 8

Recommendation Definitions
The following defines the various components included in a CIS recommendation as
applicable. If any of the components are not applicable it will be noted or the
component will not be included in the recommendation.
Title
Concise description for the recommendation's intended configuration.
Assessment Status
An assessment status is included for every recommendation. The assessment status
indicates whether the given recommendation can be automated or requires manual
steps to implement. Both statuses are equally important and are determined and
supported as defined below:
Automated
Represents recommendations for which assessment of a technical control can be fully
automated and validated to a pass/fail state. Recommendations will include the
necessary information to implement automation.
Manual
Represents recommendations for which assessment of a technical control cannot be
fully automated and requires all or some manual steps to validate that the configured
state is set as expected. The expected state can vary depending on the environment.
Profile
A collection of recommendations for securing a technology or a supporting platform.
Most benchmarks include at least a Level 1 and Level 2 Profile. Level 2 extends Level 1
recommendations and is not a standalone profile. The Profile Definitions section in the
benchmark provides the definitions as they pertain to the recommendations included for
the technology.
Description
Detailed information pertaining to the setting with which the recommendation is
concerned. In some cases, the description will include the recommended value.
Rationale Statement
Detailed reasoning for the recommendation to provide the user a clear and concise
understanding on the importance of the recommendation.
Page 9

Impact Statement
Any security, functionality, or operational consequences that can result from following
the recommendation.
Audit Procedure
Systematic instructions for determining if the target system complies with the
recommendation.
Remediation Procedure
Systematic instructions for applying recommendations to the target system to bring it
into compliance according to the recommendation.
Default Value
Default value for the given setting in this recommendation, if known. If not known, either
not configured or not defined will be applied.
References
Additional documentation relative to the recommendation.
CIS Critical Security Controls® (CIS Controls®)

The mapping between a recommendation and the CIS Controls is organized by CIS
Controls version, Safeguard, and Implementation Group (IG). The Benchmark in its
entirety addresses the CIS Controls safeguards of (v7) “5.1 - Establish Secure
Configurations” and (v8) '4.1 - Establish and Maintain a Secure Configuration Process”
so individual recommendations will not be mapped to these safeguards.
Additional Information
Supplementary information that does not correspond to any other field but may be
useful to the user.
Page 10

Profile Definitions
The following configuration profiles are defined by this Benchmark:
• Level 1- MongoDB
Items in this profile apply to MongoDB and intend to:
o be practical and prudent;

o provide a clear security benefit; and
o not inhibit the utility of the technology beyond acceptable means.
• Level 2 - MongoDB
This profile extends the “Level 1 - MongoDB” profile. Items in this profile apply to
MongoDB and exhibit one or more of the following characteristics:
o are intended for environments or use cases where security is paramount

o acts as defense in depth measure
o may negatively inhibit the utility or performance of the technology.
Page 11

Acknowledgements
This Benchmark exemplifies the great things a community of users, vendors, and
subject matter experts can accomplish through consensus collaboration. The CIS
community thanks the entire consensus team with special recognition to the following
individuals who contributed greatly to the creation of this guide:
Authors
Vinesh Redkar
Pralhad Chaskar
Editor
Randall Mowen
Contributors
James Scott
Emad Al-Mousa
Vinesh Redkar
Matthew Reagan
Tony Wilderwing
Page 12

Recommendations
1 Installation and Patching
This section provides guidance on ensuring that the MongoDB software is up to date to
eliminate easily avoidable vulnerabilities.
Page 13

1.1 Ensure the appropriate MongoDB software version/patches
are installed (Manual)
Profile Applicability:
Description:
The MongoDB installation version, along with the patch level, should be the most recent
that is compatible with the organization's operational needs. In addition, regularly view
latest minor security patch updates for security vulnerability fixes (CVE Related) from
MongoDB website: https://www.mongodb.com/alerts
Rationale:
Using the most recent MongoDB software version along with all applicable patches,
helps limit the possibilities for vulnerabilities in the software. The installation version
and/or patches applied should be selected according to the needs of the organization.
At a minimum, the software version should be supported.
Audit:
On Ubuntu:
Run the following command from within the MongoDB shell to determine if the
MongoDB software version complies with your organization’s operational needs:
mongo --version
db.version() #Inside mongo console
On Windows:
Navigate to the Installation directory of Mongo DB on the server and run below
command
mongod.exe --version
Remediation:
Upgrade to the latest version of the MongoDB software:
1. Backup the data set.

2. Download the binaries for the latest MongoDB revision from the MongoDB
Download Page and store the binaries in a temporary location. The binaries
download as compressed files that extract to the directory structure used by the
MongoDB installation.
3. Shutdown the MongoDB instance.
4. Replace the existing MongoDB binaries with the downloaded binaries.
5. Restart the MongoDB instance.
Page 14

Default Value:
Patches are not installed by default.
References:
1. https://www.mongodb.com/docs/v7.0/installation/
2. https://www.mongodb.com/docs/v7.0/release-notes/7.0/#std-label-release-notes-
7.0
3. https://www.mongodb.com/download-center#community
4. https://www.mongodb.com/support-policy
5. https://www.mongodb.com/alerts
CIS Controls:
Controls
Control IG 1 IG 2 IG 3
Version
2.3 Address Unauthorized Software

v8 Ensure that unauthorized software is either removed from use on enterprise ● ● ●
assets or receives a documented exception. Review monthly, or more frequently.
2.2 Ensure Software is Supported by Vendor

Ensure that only software applications or operating systems currently supported
v7 by the software's vendor are added to the organization's authorized software ● ● ●
inventory. Unsupported software should be tagged as unsupported in the inventory
system.
Page 15

2 Authentication
This section contains recommendations for requiring authentication before allowing
access to the MongoDB database.
Page 16

2.1 Ensure Authentication is configured (Automated)
Description:
This setting ensures that all clients, users, servers are required to authenticate before
being granted access to the MongoDB database.
Authentication is the process of verifying the identity of a client. When access control,
i.e. authorization, is enabled, MongoDB requires all clients to authenticate themselves in
order to determine their access.
from MongoDB documentation
Authentication Mechanisms
MongoDB supports a number of authentication mechanisms that clients
can use to verify their identity. These mechanisms allow MongoDB to
integrate into your existing authentication system.
MongoDB supports multiple authentication mechanisms:
• SCRAM (Default)
• x.509 Certificate Authentication.
Certificate Authority
For production use, your MongoDB deployment should use valid
certificates generated and signed by a certificate authority. You or your
organization can generate and maintain an independent certificate
authority, or use certificates generated by third-party TLS/SSL vendors.
In addition to supporting the aforementioned mechanisms, MongoDB
Enterprise also supports the following mechanisms:
• LDAP proxy authentication

• Kerberos authentication.
Rationale:
Failure to authenticate clients, users, servers can enable unauthorized access to the
MongoDB database and can prevent tracing actions back to their sources.
It's highly recommended that password length and complexity also be in-place. When
performing the traditional user/password authentication against MongoDB there is not
in-place intrinsic password complexity check and there is no LOCKING mechanism with
multiple failure logins. So, MongoDB is prone to brute force attacks compared to other
database systems.
Page 17

Audit:
Run the following command to verify whether an authorization is enabled on the
MongoDB server.
On Ubuntu:
cat /etc/mongod.conf | grep “authorization”
On Windows:
type mongod.conf | findstr “authorization”
The value for authorization must be set to enabled.

To authenticate using the mongo shell use the following approach
• Use the mongo command-line authentication options (--username, --password,

and --authenticationDatabase) when connecting to the mongod or mongos
instance
Or
• Connect first to the mongod or mongos instance, and then run the authenticate
command or the db.auth() method against the authentication database.
Remediation:
The authentication mechanism should be implemented before anyone accesses the
MongoDB Server.
To enable the authentication mechanism:
• Start the MongoDB instance without authentication.
mongod --port 27017 --dbpath /data/db1
Or
mongod.exe --port 27017 --dbpath db1
• Create the system user administrator, ensuring that its password meets
organizationally-defined password in terms of length and complexity
requirements as there is no in-place locking mechanism for multiple failed login
attempts against MongoDB.
Page 18

use admin
db.createUser(
{
user: "MongoAdmin",
pwd: "password",
roles: [ { role: "root", db: "admin" } ]
}
)
• Open mongod.conf and change for authorization value to enabled:
security:
authorization: "enabled"
• Restart the MongoDB instance
service mongod restart
Default Value:
By default, authorization is set to disable.
References:
1. https://www.mongodb.com/docs/v7.0/core/authentication/
CIS Controls:
Controls
Version
5.2 Use Unique Passwords

v8 Use unique passwords for all enterprise assets. Best practice implementation
includes, at a minimum, an 8-character password for accounts using MFA and a
● ● ●
14-character password for accounts not using MFA.
6.3 Require MFA for Externally-Exposed Applications

v8 Require all externally-exposed enterprise or third-party applications to enforce
MFA, where supported. Enforcing MFA through a directory service or SSO
● ●
provider is a satisfactory implementation of this Safeguard.
16.3 Require Multi-factor Authentication

v7 Require multi-factor authentication for all user accounts, on all systems, ● ●
whether managed onsite or by a third-party provider.
Page 19

2.2 Ensure that MongoDB does not bypass authentication via the
localhost exception (Automated)
Description:
MongoDB should not be set to bypass authentication via the localhost exception. The
localhost exception allows the user to enable authorization before creating the first user
in the system. When active, the localhost exception allows all connections from the
localhost interface to have full access to that instance. The exception applies only when
there are no users created in the MongoDB instance.
Note: This recommendation only applies when there are no users created in the
MongoDB instance.
Rationale:
Disabling this exception will prevent unauthorized local access to the MongoDB
database. It will also ensure the traceability of each database activity to a specific user.
Localhost Exception allows direct connect to Mongod’s without any UN/PW.
Audit:
Run the following command to extract the information about
enableLocalhostAuthBypass setting on Configuration File.
On Ubuntu:
cat /etc/mongod.conf |grep "enableLocalhostAuthBypass"
On Windows:
type mongod.conf | findstr "enableLocalhostAuthBypass"
The value for enableLocalhostAuthBypass must be false.
Remediation:
To disable local authentication on the MongoDB database.
Type OS Console Command
mongod --setParameter enableLocalhostAuthBypass=0
or
To manually configure use the setParameter option in the mongo configuration file to
set it to false.
Page 20

setParameter:
enableLocalhostAuthBypass: false
Default Value:
By default, localhost exception value (enableLocalhostAuthBypass) is true.
References:
1. https://www.mongodb.com/docs/v7.0/core/localhost-exception/
CIS Controls:
Controls
Version
6.3 Require MFA for Externally-Exposed Applications

v8 Require all externally-exposed enterprise or third-party applications to enforce
MFA, where supported. Enforcing MFA through a directory service or SSO
● ●
provider is a satisfactory implementation of this Safeguard.
16.3 Require Multi-factor Authentication

v7 Require multi-factor authentication for all user accounts, on all systems, ● ●
whether managed onsite or by a third-party provider.
Page 21

2.3 Ensure authentication is enabled in the sharded cluster
(Automated)
Description:
Authentication is enabled in a sharded cluster when the certificate or key files are
created and configured for all components. This ensures that every client that accesses
the cluster must provide credentials, to include MongoDB instances that access each
other within the cluster.
With keyfile authentication, each mongod or mongos instance in the sharded cluster
uses the contents of the keyfile as the shared password for authenticating other
members in the deployment. Only mongod or mongos instances with the correct keyfile
can join the sharded cluster.
For Production Environment: x.509 certificate authentication with secure TSL/SSL
connection must be used for authentication.
For Development Purpose: Key file can be used as an authentication mechanism
between the shared cluster. Keyfiles are bare-minimum forms of security and are best
suited for testing or development environments.
Rationale:
Enforcing a key or certificate on a sharded cluster prevents unauthorized access to the
MongoDB database and provides traceability of database activities to a specific user or
component. A MongoDB sharded cluster can enforce user authentication as well as
internal authentication of its components to secure against unauthorized access.
Audit:
Based on recommendations
•
PEMKeyFile, clusterFile, CAFile must be configured.
•
clusterAuthMode should be set to x509
•
authenticationMechanisms should be set to MONGODB-X509.
To Check That your Current MongoDB is configured for sharding setup, execute the
following command:
sh.status()
OR
Page 22

db.printShardingStatus()
Run the following command to verify that the certificate-based authentication is
configured:
On Ubuntu:
cat /etc/mongod.conf | grep "clusterAuthMode"
On Windows:
type mongod.conf | findstr “clusterAuthMode”
Run the following command to verify that the key file-based authentication is
configured: (Only for Development Purpose)
On Ubuntu:
cat /etc/mongod.conf | grep “keyFile”
On Windows:
type mongod.conf | findstr “keyFile”
Remediation:
To authenticate to servers, clients can use x.509 certificates instead of usernames and
passwords.
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.
Change the configuration file /etc/mongod.conf on each host, adding the following
rows:
Page 23

net:
port: 27017
tls:
mode: requireSSL
PEMKeyFile: /etc/mongodb/ssl/server1.pem
CAFile: /etc/mongodb/ssl/mongoCA.crt
clusterFile: /etc/mongodb/ssl/server1.pem
security:
authorization: enabled
clusterAuthMode: x509
security:
authorization: enabled
clusterAuthMode: x509
net:
tls:
mode: requireTLS
certificateKeyFile: <path to its TLS/SSL certificate and key file>
CAFile: <path to root CA PEM file to verify received certificate>
clusterFile: <path to its certificate key file for membership
authentication>
bindIp: localhost,<hostname(s)|ip address(es)>
Restart the daemon
sudo service mongodb restart
To enable authentication in the sharded cluster, perform the following steps:(Only for
Development Purpose)
•
Generate A Key File
• On each component in the shared cluster, enable authentication by editing the
configuration file /etc/mongod.conf. Set the keyFile option to the key file’s
path and then start the component with this command:
keyFile = /srv/mongodb/keyfile
• When starting the component, set --keyFile option, which is an option for both
mongos instances and mongod instances. Set the --keyFile to the key file’s
path.
Default Value:
Not configured
References:
1. https://www.mongodb.com/docs/v7.0/core/security-transport-encryption/#std-
label-transport-encryption
Page 24

2. https://www.mongodb.com/docs/v7.0/reference/security/
3. https://www.mongodb.com/docs/v7.0/tutorial/deploy-shard-cluster/
4. https://www.mongodb.com/docs/manual/tutorial/configure-x509-member-
authentication/
5. https://www.mongodb.com/docs/manual/tutorial/deploy-sharded-cluster-with-
keyfile-access-
control/#:~:text=With%20keyfile%20authentication%2C%20each%20mongod,ca
n%20join%20the%20sharded%20cluster.
CIS Controls:
Controls
Version
6.6 Establish and Maintain an Inventory of Authentication

and Authorization Systems
v8 Establish and maintain an inventory of the enterprise’s authentication and ● ●
authorization systems, including those hosted on-site or at a remote service
provider. Review and update the inventory, at a minimum, annually, or more
frequently.
1.8 Utilize Client Certificates to Authenticate Hardware

v7 Assets
Use client certificates to authenticate hardware assets connecting to the
●
organization's trusted network.
Page 25

3 Authorization
MongoDB grants access to data and commands through "role-based" approach ,
MongoDB is shipped with built-in roles that provide the different levels of access
commonly needed in a database system. In addition, you can create custom-roles.
Page 26

3.1 Ensure least privilege for database accounts (Manual)
Description:
MongoDB grants access to data and commands through "role-based" approach,
MongoDB is shipped with built-in roles that provide the different levels of access
commonly needed in a database system. In addition, you can create custom-roles.
The following roles provide the ability to assign any user any privilege on any database,
which means that users with one of these roles can assign themselves any privilege on
any database:
dbOwner role, when scoped to the admin database userAdmin role, when scoped to the
admin database userAdminAnyDatabase role
Rationale:
Ensuring highly privileged Roles are granted only for database administrators, and roles
are not scoped to "admin" databases will reduce attack surface and follows the least
privilege principle.
Audit:
To check accounts with database roles scoped in "admin" database, use the following
query:
db.system.users.find(
{"roles.role":{$in:["dbOwner","userAdmin","userAdminAnyDatabase"]},"roles.db"
: "admin" } )
Remediation:
If any accounts were listed with built in-roles:
dbOwner
userAdmin
userAdminAnyDatabase
in "admin" database role then drop them.
References:
1. https://www.mongodb.com/docs/v7.0/reference/built-in-roles/
Page 27

CIS Controls:
Controls
Version
5.4 Restrict Administrator Privileges to Dedicated

Administrator Accounts
v8 Restrict administrator privileges to dedicated administrator accounts on
enterprise assets. Conduct general computing activities, such as internet
● ● ●
browsing, email, and productivity suite use, from the user’s primary, non-privileged
account.
4.3 Ensure the Use of Dedicated Administrative Accounts

v7 Ensure that all users with administrative account access use a dedicated or
secondary account for elevated activities. This account should only be used for
● ● ●
administrative activities and not internet browsing, email, or similar activities.
Page 28

3.2 Ensure that role-based access control is enabled and
configured appropriately (Manual)
Description:
Role-based access control (RBAC) is a method of regulating access to resources based
on the roles of individual users within an enterprise. A user is granted one or more roles
that determine the user’s access to database resources and operations. Outside of role
assignments, the user has no access to the system. MongoDB can use RBAC to govern
access to MongoDB systems. MongoDB does not enable authorization by default.
Rationale:
When properly implemented, RBAC enables users to carry out a wide range of
authorized tasks by dynamically regulating their actions according to flexible functions.
This allows an organization to control employees’ access to all database tables through
RBAC.
Audit:
Connect to MongoDB with the appropriate privileges and run the following command:
Identify users' roles and privileges:

> db.getUser()
> db.getRole()
Verify that the appropriate role or roles have been configured for each user.
Remediation:
1. Establish roles for MongoDB.

2. Assign the appropriate privileges to each role.
3. Assign the appropriate users to each role.
4. Remove any individual privileges assigned to users that are now addressed by
the roles.
5. See the reference below for more Information.
References:
1. https://www.mongodb.com/docs/v7.0/tutorial/manage-users-and-roles/
Page 29

CIS Controls:
Controls
Version
6.8 Define and Maintain Role-Based Access Control

Define and maintain role-based access control, through determining and
v8 documenting the access rights necessary for each role within the enterprise to
successfully carry out its assigned duties. Perform access control reviews of
●
enterprise assets to validate that all privileges are authorized, on a recurring
schedule at a minimum annually, or more frequently.
14.6 Protect Information through Access Control Lists

Protect all information stored on systems with file system, network share, claims,
v7 application, or database specific access control lists. These controls will enforce the ● ● ●
principle that only authorized individuals should have access to the information
based on their need to access the information as a part of their responsibilities.
Page 30

3.3 Ensure that MongoDB is run using a non-privileged, dedicated
service account (Manual)
Description:
The MongoDB service should not be run using a privileged account such as 'root'
because this unnecessarily exposes the operating system to high risk.
Rationale:
Using a non-privileged, dedicated service account restricts the database from accessing
the critical areas of the operating system which are not required by the MongoDB. This
will also mitigate the potential for unauthorized access via a compromised, privileged
account on the operating system.
Audit:
Run the following command to get listing of all mongo instances, the PID number, and
the PID owner.
ps -ef | grep -E "mongos|mongod"
Remediation:
1. Create a dedicated user for performing MongoDB database activity.

2. Set the Database data files, the keyfile, and the SSL private key files to only be
readable by the mongod/mongos user.
3. Set the log files to only be writable by the mongod/mongos user and readable
only by root.
Default Value:
Not configured
References:
1. https://www.mongodb.com/docs/v7.0/tutorial/manage-users-and-roles/
Page 31

CIS Controls:
Controls
Version
5.5 Establish and Maintain an Inventory of Service

Accounts
v8 Establish and maintain an inventory of service accounts. The inventory, at a
minimum, must contain department owner, review date, and purpose. Perform
● ●
service account reviews to validate that all active accounts are authorized, on a
recurring schedule at a minimum quarterly, or more frequently.

● ● ●
Page 32

3.4 Ensure that each role for each MongoDB database is needed
and grants only the necessary privileges (Manual)
Description:
Reviewing all roles periodically and eliminating unneeded roles as well as unneeded
privileges from necessary roles helps minimize the privileges that each user has.
Rationale:
Although role-based access control (RBAC) has many advantages for regulating access
to resources, over time some roles may no longer be needed, and some roles may
grant privileges that are no longer needed.
Audit:
Perform the following command to view all roles on the database on which the
command runs, including both built-in and user-defined roles, as well as the privileges
granted by each role. Ensure that only necessary roles are listed and only the
necessary privileges are listed for each role.
db.runCommand(
{
rolesInfo: 1,
showPrivileges: true,
showBuiltinRoles: true
}
)
Remediation:
To revoke specified privileges from the user-defined role on the database where the
command is run. The revokePrivilegesFromRole command has the following syntax:
References:
1. https://www.mongodb.com/docs/v7.0/reference/privilege-actions/#mongodb-
authaction-revokeRole
2. https://www.mongodb.com/docs/v7.0/core/authorization/#std-label-privileges
Additional Information:
You must have the dropRole action on a database to drop a role from that database.
Page 33

CIS Controls:
Controls
Version

v8 Restrict administrator privileges to dedicated administrator accounts on ● ● ●
enterprise assets. Conduct general computing activities, such as internet browsing,
email, and productivity suite use, from the user’s primary, non-privileged account.

Protect all information stored on systems with file system, network share,
v7 claims, application, or database specific access control lists. These controls will
enforce the principle that only authorized individuals should have access to the
● ● ●
information based on their need to access the information as a part of their
responsibilities.
Page 34

3.5 Review Superuser/Admin Roles (Manual)
Description:
Roles provide several advantages that make it easier to manage privileges in a
database system. Security administrators can control access to their databases in a
way that mirrors the structure of their organizations (they can create roles in the
database that map directly to the job functions in their organizations). The assignment
of privileges is simplified. Instead of granting the same set of privileges to each
individual user in a particular job function, the administrator can grant this set of
privileges to a role representing that job function and then grant that role to each user in
that job function.
Rationale:
Reviewing the Superuser/Admin roles within a database helps minimize the possibility
of privileged unwanted access.
Audit:
Superuser roles provide the ability to assign any user any privilege on any database,
which means that users with one of these roles can assign themselves any privilege on
any database:
db.runCommand( { rolesInfo: "dbOwner" } )
db.runCommand( { rolesInfo: "userAdmin" } )
db.runCommand( { rolesInfo: "userAdminAnyDatabase" } )
Root role provides access to the operations and all the resources of the
readWriteAnyDatabase, dbAdminAnyDatabase, userAdminAnyDatabase,
clusterAdmin roles, restore combined.
db.runCommand( { rolesInfo: "readWriteAnyDatabase" } )
db.runCommand( { rolesInfo: "dbAdminAnyDatabase" } )
db.runCommand( { rolesInfo: "userAdminAnyDatabase" } )
db.runCommand( { rolesInfo: "clusterAdmin" } )
Cluster Administration Roles are used for administering the whole system rather than
just a single database.
db.runCommand( { rolesInfo: "hostManager" } )
Remediation:
To remove a user from one or more roles on the current database.
Page 35

References:
1. https://www.mongodb.com/docs/v7.0/core/security-user-defined-roles/
2. https://www.mongodb.com/docs/v7.0/reference/method/#std-label-role-
management-methods
CIS Controls:
Controls
Version

v8 Restrict administrator privileges to dedicated administrator accounts on
enterprise assets. Conduct general computing activities, such as internet
● ● ●
browsing, email, and productivity suite use, from the user’s primary, non-privileged
account.

● ● ●
16.8 Disable Any Unassociated Accounts

v7 Disable any account that cannot be associated with a business process or ● ● ●
business owner.
Page 36

4 Data Encryption
This section contains recommendations for securing data at rest (stored) and data in
motion (transiting) for MongoDB.
Page 37

4.1 Ensure legacy TLS protocols are disabled (Automated)
Description:
Only modern TLS protocols should be enabled in MongoDB for all client connections
and upstream connections. Removing legacy TLS and SSL protocols (SSL 3.0, TLS 1.0
and 1.1), and enabling emerging and stable TLS protocols (TLS 1.2, and TLS 1.3),
ensures users are able to take advantage of strong security capabilities and protects
them from insecure legacy protocols.
Rationale:
Why disable TLS 1.0: TLS 1.0 was deprecated from use when PCI DSS Compliance
mandated that it not be used for any applications processing credit card numbers in
June 2018.
Why disable TLS 1.1: Because of the increased security associated with higher
versions of TLS, TLS 1.0 should be disabled.
Audit:
To verify that the server uses disables legacy TLS protocols you should check the
disabledProtocols directive, run the following commands:
mongod --config /etc/mongod.conf
Review for disabledProtocols as part of the output shown below:

net:
tls:
mode: requireTLS
certificateKeyFile: /etc/ssl/mongodb.pem
CAFile: /etc/ssl/caToValidateClientCertificates.pem
disabledProtocols: TLS1_0,TLS1_1
Remediation:
Make changes to configuration file, to configure your mongod or mongos instance to
disable legacy protocols, shut down the instance and update the configuration file with
the following setting:
net:
tls:
mode: requireTLS
Start mongod or mongos instance with the configuration file.
Page 38

Default Value:
TLS1_0, TLS1_1, TLS1_2
Note: Starting in version 4.0.4 (and 3.6.9)TLS1_3 is added to the default value.
References:
1. https://www.mongodb.com/docs/v7.0/core/security-transport-encryption/
CIS Controls:
Controls
Version
4.1 Establish and Maintain a Secure Configuration Process

Establish and maintain a secure configuration process for enterprise assets
v8 (end-user devices, including portable and mobile, non-computing/IoT devices, and
servers) and software (operating systems and applications). Review and update
● ● ●
documentation annually, or when significant enterprise changes occur that could
impact this Safeguard.
18.11 Use Standard Hardening Configuration Templates

for Databases
v7 For applications that rely on a database, use standard hardening configuration ● ●
templates. All systems that are part of critical business processes should also be
tested.
Page 39

4.2 Ensure Weak Protocols are Disabled (Automated)
Description:
Servers can be configured to disable specific TLS/SSL protocol versions which may be
vulnerable to exploitation and/or lack features which improve the level of security as
provided by newer versions of the protocol.
Rationale:
The TLSv1.0 protocol is vulnerable to the BEAST attack when used in CBC mode
(October 2011). Unfortunately, the TLSv1.0 uses CBC modes for all of the block mode
ciphers, which only leaves the RC4 streaming cipher which is also weak and is not
recommended. Therefore, it is recommended that the TLSv1.0 protocol be disabled.
The TLSv1.1 protocol does not support Authenticated Encryption with Associated Data
(AEAD) which is designed to simultaneously provide confidentiality, integrity, and
authenticity.
The NIST SP 800-52r2 guidelines for TLS configuration require that TLS 1.2 is
configured with FIPS-based cipher suites be supported by all government TLS servers
and clients and requires support of TLS 1.3 by January 1, 2024. A September 2018
IETF draft also depreciates the usage of TLSv1.0 and TLSv1.1 as shown in the
references.
Impact:
If an attempt to connect using a disabled protocol is made the connection attempt will
fail and may have unanticipated impact on clients attempting to establish the
connection.
Audit:
To verify that the server disable TLS v1.0 and v1.1, run one of the following commands:
• On Ubuntu:
cat /etc/mongod.conf | grep –A20 ‘net’ | grep –A10 ‘ssl’ | grep

‘disabledProtocols’
• On Windows:
type mongod.conf | findstr –A20 ‘net’ | findstr –A10 ‘ssl’ | findstr

‘disabledProtocols’
If TLS1_0,TLS1_1 is not included in the string returned by either of these commands
this is a fail.
Page 40

Remediation:
For mongod (“Primary daemon process for the MongoDB system”)
In the configuration file /etc/mongod.conf, set the disabledProtocols option to to
include TLS1_0,TLS1_1:
net:
ssl:
mode: requireSSL
PEMKeyFile: /etc/ssl/mongodb.pem
And restart monogdb instance with
Or
mongod --sslDisabledProtocols `TLS1_0,TLS1_1
Default Value:
TLS1_0 if TLS 1.1+ is available on the system.
References:
1. https://www.mongodb.com/docs/v7.0/reference/configuration-options/#mongodb-
setting-net.ssl.disabledProtocols
On macOS, you cannot disable TLS1_1 and leave both TLS1_0 and TLS1_2 enabled.
You must also disable at least one of the other two; for example, TLS1_0,TLS1_1.
CIS Controls:
Controls
Version
3.10 Encrypt Sensitive Data in Transit

v8 Encrypt sensitive data in transit. Example implementations can include: ● ●
Transport Layer Security (TLS) and Open Secure Shell (OpenSSH).
v7 14.4 Encrypt All Sensitive Information in Transit ● ●

Encrypt all sensitive information in transit.
Page 41

4.3 Ensure Encryption of Data in Transit TLS or SSL (Transport
Encryption) (Automated)
Description:
Use TLS or SSL to protect all incoming and outgoing connections. This should include
using TLS or SSL to encrypt communication between the mongod and mongos
components of a MongoDB client as well as between all applications and MongoDB.
MongoDB supports TLS/SSL (Transport Layer Security/Secure Sockets Layer) to
encrypt all of MongoDB’s network traffic. TLS/SSL ensures that MongoDB network
traffic is only readable by the intended client.
Please note: As of MongoDB version 4.2 SSL has been deprecated.
Also, starting in MongoDB version 4.0, MongoDB disables support for TLS 1.0
encryption on systems where TLS 1.1+ is available.
Rationale:
This prevents sniffing of cleartext traffic between MongoDB components or performing a
man-in-the-middle attack for MongoDB.
Audit:
To verify that the server requires SSL or TLS (net.tls.mode value set to requireTLS),
run one of the following commands:
On Ubuntu:
cat /etc/mongod.conf | grep –A20 ‘net’ | grep –A10 ‘tls’ | grep ‘mode’
On Windows:
type mongod.conf | findstr –A20 ‘net’ | findstr –A10 ‘tls’ | findstr ‘mode’
Remediation:
Configure MongoDB servers to require the use of SSL or TLS to encrypt all MongoDB
network communications.
To implement SSL or TLS to encrypt all MongoDB network communication, perform the
following steps:
For mongod (“Primary daemon process for the MongoDB system”)
In the configuration file /etc/mongod.conf, set the PEMKeyFile option to the certificate
file’s path and then start the component with this command:
Page 42

net:
tls:
mode: requireTLS
And restart monogdb instance with

Default Value:
Not configured
References:
1. https://www.mongodb.com/docs/v7.0/tutorial/configure-ssl/
2. https://www.mongodb.com/docs/v7.0/tutorial/configure-ssl-clients/
3. https://www.mongodb.com/docs/v7.0/tutorial/upgrade-cluster-to-ssl/
setting-net.tls.clusterAuthX509.attributes
-----------------------------------------------------------------------------
Value | Description
------------+----------------------------------------------------------------
disabled | The server does not use TLS.
------------+----------------------------------------------------------------
allowTLS | Connections between servers do not use TLS. For incoming
connections,
| the server accepts both TLS and non-TLS.
|
|
------------+----------------------------------------------------------------
preferTLS | Connections between servers use TLS. For incoming connections,
the server
| accepts both TLS and non-TLS.
|
|
------------+----------------------------------------------------------------
requireTLS | The server uses and accepts only TLS encrypted connections.
|
-----------------------------------------------------------------------------
CIS Controls:
Controls
Version

Page 43

Controls
Version

14.2 Encrypt All Sensitive Information Over Less-trusted

Networks
v6 All communication of sensitive information over less-trusted networks should
be encrypted. Whenever information flows over a network with a lower trust level,
the information should be encrypted.
Page 44

4.4 Ensure Federal Information Processing Standard (FIPS) is
enabled (Automated)
Description:
The Federal Information Processing Standard (FIPS) is a computer security standard
used to certify software modules and libraries that encrypt and decrypt data securely.
You can configure MongoDB to run with a FIPS 140-2 certified library for OpenSSL.
FIPS is a property of the encryption system and not the access control system.
However, the environment requires FIPS compliant encryption and access control.
Organizations must ensure that the access control system uses only FIPS-compliant
encryption.
Rationale:
FIPS is an industry standard which dictates how data should be encrypted at rest and
during transmission.
Audit:
On Ubuntu:
To verify that the server uses FIPS Mode (net.tls.FIPSMode value set to true), run
following commands:
net:
tls:
FIPSMode: true
Or
To verify FIPS mode is running, check the server log file for a message that FIPS is
active:
FIPS 140-2 mode activated
On Windows:
Check FIPSMode is true
type mongod.conf | findstr “FIPSMode"
Remediation:
Configuring FIPS mode, ensure that your certificate is FIPS compliant. Run mongod or
mongos instance in FIPS mode.
Make changes to configuration file, to configure your mongod or mongos instance to
use FIPS mode, shut down the instance and update the configuration file with the
following setting:
Page 45

net:
tls:
FIPSMode: true
Start mongod or mongos instance with a configuration file.
Default Value:
Not configured
References:
1. https://www.mongodb.com/docs/v7.0/tutorial/configure-fips/
CIS Controls:
Controls
Version


14.8 Encrypt Sensitive Information at Rest

v7 Encrypt all sensitive information at rest using a tool that requires a secondary
authentication mechanism not integrated into the operating system, in order to
●
access the information.
Page 46

4.5 Ensure Encryption of Data at Rest (Manual)
Description:
Encryption of data at rest must be enabled to ensure compliance with security and
privacy standards including HIPAA, PCI-DSS, and FERPA.
Encryption at rest, when used in conjunction with transport encryption and good security
policies that protect relevant accounts, passwords, and encryption keys.
Rationale:
Unauthorized users, such as intruders who are attempting security attacks, cannot read
the data from storage and back up media unless they have the master encryption key to
decrypt it.
Audit:
To verify that the server requires TLS (net.tls.mode value set to requireTLS), run
one of the following commands:
On Ubuntu:
cat /etc/mongod.conf | grep --enableEncryption 'yes' | grep --
encryptionKeyFile '<path to keyfile>'
On Windows:
type mongod.conf | findstr --enableEncryption 'yes' | findstr --
encryptionKeyFile '<path to keyfile>'
Remediation:
It is recommended to enable the data at rest encryption to protect the data.
Protecting Data at Rest Including following steps.
• Generating a master key.

• Generating keys for each database.
• Encrypting data with the database keys.
• Encrypting the database keys with the master key.
Only the master key is external to the server and requires external management. To
manage the master key, MongoDB’s encrypted storage engine supports two key
management options:
• Integration with a third-party key management appliance via the Key

Management Interoperability Protocol (KMIP). Recommended
• Use of local key management via a keyfile.
Page 47

The encryption occurs transparently in the storage layer; i.e. all data files are fully
encrypted from a filesystem perspective, and data only exists in an unencrypted state in
memory and during transmission.
To enable Encryption on Database follow below step mentioned in below Link
https://docs.mongodb.com/manual/tutorial/configure-encryption/
Rotation of Key is also important. This can be enabled by following mentioned
steps in below link.
https://docs.mongodb.com/manual/tutorial/rotate-encryption-key/
References:
1. https://www.mongodb.com/docs/v7.0/core/security-encryption-at-rest/
Available in MongoDB Enterprise only.
CIS Controls:
Controls
Version
3.11 Encrypt Sensitive Data at Rest

Encrypt sensitive data at rest on servers, applications, and databases containing
sensitive data. Storage-layer encryption, also known as server-side encryption,
v8 meets the minimum requirement of this Safeguard. Additional encryption methods ● ●
may include application-layer encryption, also known as client-side encryption,
where access to the data storage device(s) does not permit access to the plain-text
data.
14.8 Encrypt Sensitive Information at Rest

v7 Encrypt all sensitive information at rest using a tool that requires a secondary
authentication mechanism not integrated into the operating system, in order to
●
access the information.
Page 48

5 Audit Logging
This section contains recommendations related to configuring audit logging in
MongoDB.
Page 49

5.1 Ensure that system activity is audited (Automated)
Description:
Track access and changes to database configurations and data. MongoDB Enterprise
includes a system auditing facility that can record system events (e.g. user operations,
connection events) on a MongoDB instance. These audit records permit forensic
analysis and allow administrators to verify proper controls.
Rationale:
System level logs can be handy while troubleshooting an operational problem or
handling a security incident.
Audit:
To verify that system activity is being audited for MongoDB, run the following command
to confirm the auditLog.destination value is set correctly:
On Ubuntu:
cat /etc/mongod.conf |grep –A4 "auditLog" | grep "destination"
On Windows:
type mongod.conf | findstr –A4 "auditLog" | findstr "destination"
Remediation:
Set the value of auditLog.destination to the appropriate value from the following
options:
syslog
To enable auditing and print audit events to syslog
mongod --dbpath data/db --auditDestination syslog
console
To enable auditing and print audit events to standard output (i.e., stdout)
mongod --dbpath data/db --auditDestination console
Json File
To enable auditing and print audit events to a file in JSON format. Printing audit events
to file in JSON format degrades server performance more than printing to a file in BSON
format.
Page 50

mongod --dbpath data/db --auditDestination file --auditFormat JSON --
auditPath data/db/auditLog.json
Bson File
To enable auditing and print audit events to a file in BSON binary format
mongod --dbpath data/db --auditDestination file --auditFormat BSON --
auditPath data/db/auditLog.bson
Default Value:
Not configured
References:
1. http://docs.mongodb.org/manual/tutorial/configure-auditing/
CIS Controls:
Controls
Version
8.2 Collect Audit Logs

v8 Collect audit logs. Ensure that logging, per the enterprise’s audit log ● ● ●
management process, has been enabled across enterprise assets.
6.2 Activate audit logging

v7 Ensure that local logging has been enabled on all systems and networking ● ● ●
devices.
6.3 Enable Detailed Logging

v7 Enable system logging to include detailed information such as an event
source, date, user, timestamp, source addresses, destination addresses, and
● ●
other useful elements.
Page 51

5.2 Ensure that audit filters are configured properly (Manual)
Description:
MongoDB Enterprise supports auditing of various operations. When enabled, the audit
facility, by default, records all auditable operations as detailed in Audit Event Actions,
Details, and Results. To specify which events to record, the audit feature includes the -
-auditFilter option. This check is only for Enterprise editions.
Rationale:
All operations carried out on the database are logged. This helps in backtracking and
tracing any incident that occurs.
Audit:
To verify that audit filters are configured on MongoDB as per the organization’s
requirements, run the following command:
On Ubuntu:
cat /etc/mongod.conf |grep –A10 "auditLog" | grep "filter"
On Windows:
type mongod.conf | findstr –A10 "auditLog" | findstr "filter"
Remediation:
Set the audit filters based on the organization’s requirements.
Default Value:
Not configured
References:
1. https://docs.mongodb.com/manual/reference/audit-message/
2. https://docs.mongodb.com/manual/tutorial/configure-audit-filters/
CIS Controls:
Controls
Version

Page 52

Controls
Version
8.5 Collect Detailed Audit Logs

v8 Configure detailed audit logging for enterprise assets containing sensitive data.
Include event source, date, username, timestamp, source addresses, destination
● ●
addresses, and other useful elements that could assist in a forensic investigation.

devices.

v7 Enable system logging to include detailed information such as an event source,
date, user, timestamp, source addresses, destination addresses, and other useful
● ●
elements.
Page 53

5.3 Ensure that logging captures as much information as possible
(Automated)
Description:
The SystemLog.quiet option stops logging of information such as:
• connection events
• authentication events
• replication sync activities
• evidence of some potentially impactful commands being run (eg: drop,
dropIndexes, validate)
This information should be logged whenever possible. This check is only for Enterprise
editions.
Rationale:
The use of SystemLog.quiet makes troubleshooting problems and investigating
possible security incidents much more difficult.
Audit:
To verify that the SystemLog: quiet=false option is disabled (value of false), run the
following command:
On Ubuntu:
cat /etc/mongod.conf |grep "quiet"
On Windows:
type mongod.conf | findstr "quiet"
Remediation:
Set
`SystemLog:
quiet: false`
to false in the /etc/mongod.conf file to disable it.
References:
1. https://docs.mongodb.com/manual/reference/configuration-
options/#systemLog.quiet
Page 54

CIS Controls:
Controls
Version

8.5 Collect Detailed Audit Logs

v8 Configure detailed audit logging for enterprise assets containing sensitive data.
Include event source, date, username, timestamp, source addresses, destination
● ●
addresses, and other useful elements that could assist in a forensic investigation.

devices.

v7 Enable system logging to include detailed information such as an event source,
date, user, timestamp, source addresses, destination addresses, and other useful
● ●
elements.
Page 55

5.4 Ensure that new entries are appended to the end of the log
file (Automated)
Description:
By default, new log entries will overwrite old entries after a restart of the mongod or
Mongols service. Enabling the systemLog.logAppend setting causes new entries to be
appended to the end of the log file rather than overwriting the existing content of the log
when the mongos or mongod instance restarts.
Rationale:
Allowing old entries to be overwritten by new entries instead of appending new entries
to the end of the log may destroy old log data that is needed for a variety of purposes.
Audit:
To verify that new log entries will be appended to the end of the log file after a restart
(systemLog: logAppend: true value set to true), run the following command:
On Ubuntu:
cat /etc/mongod.conf | grep "logAppend"
On Windows:
type mongod.conf | findstr "logAppend"
Remediation:
Set
`systemLog:
logAppend: true`
to true in the /etc/mongod.conf file.
References:
1. https://docs.mongodb.com/manual/reference/configuration-
options/#systemLog.logAppend
Page 56

CIS Controls:
Controls
Version
v8 8.10 Retain Audit Logs ● ●

Retain audit logs across enterprise assets for a minimum of 90 days.
6.4 Ensure adequate storage for logs

v7 Ensure that all systems that store logs have adequate storage space for ● ●
the logs generated.
Page 57

6 Operating System Hardening
This section contains recommendations related to hardening the operating system
running below MongoDB.
Page 58

6.1 Ensure that MongoDB uses a non-default port (Automated)
Description:
Changing the default port used by MongoDB makes it harder for attackers to find the
database and target it.
Rationale:
Standard ports are used in automated attacks and by attackers to verify which
applications are running on a server.
Impact:
Hackers frequently scan IP addresses for commonly used ports, so it's not uncommon
to use a different port to "fly under the radar". This is just to avoid detection, other than
that there is no added safety by using a different port.
Audit:
To verify the port number used by MongoDB, execute the following command and
ensure that the port number is not 27017:
On Ubuntu:
cat /etc/mongod.conf |grep “port”
On Windows:
type mongod.conf | findstr “port”
Remediation:
Change the port for MongoDB server to a number other than 27017.
In mongod.conf edit the below lines
# network interfaces
net:
port: $Orginasation Defined port
bindIp: $Orginasation Defined IP
References:
1. https://docs.mongodb.com/v5.0/reference/default-mongodb-port/
Page 59

CIS Controls:
Controls
Version
4.8 Uninstall or Disable Unnecessary Services on

Enterprise Assets and Software
v8 Uninstall or disable unnecessary services on enterprise assets and software, ● ●
such as an unused file sharing service, web application module, or service
function.
9.2 Ensure Only Approved Ports, Protocols and Services

v7 Are Running ● ●
Ensure that only network ports, protocols, and services listening on a system
with validated business needs, are running on each system.
Page 60

6.2 Ensure that operating system resource limits are set for
MongoDB (Manual)
Description:
Operating systems provide ways to limit and control the usage of system resources
such as threads, files, and network connections on a per-process and per-user basis
Rationale:
These ulimits prevent a single user from consuming too many system resources.
Audit:
To verify the resource limits set for MongoDB, run the following commands.
Extract the process ID for MongoDB:
ps -ef | grep mongod
View the limits associated with that process number:
cat /proc/1322/limits
Remediation:
Every deployment may have unique requirements and settings. Recommended
thresholds and settings are particularly important for MongoDB deployments:
•
f (file size): unlimited
•
t (cpu time): unlimited
•
v (virtual memory): unlimited [1]
•
n (open files): 64000
•
m (memory size): unlimited [1] [2]
•
u (processes/threads): 64000
Restart the mongod and mongos instances after changing the ulimit settings to
ensure that the changes take effect.
Page 61

Default Value:
Not configured
References:
1. https://www.mongodb.com/docs/v7.0/reference/ulimit/
2. https://docs.mongodb.com/manual/reference/ulimit/
CIS Controls:
Controls
Version
16.7 Use Standard Hardening Configuration Templates for

Application Infrastructure
Use standard, industry-recommended hardening configuration templates for
v8 application infrastructure components. This includes underlying servers, databases, ● ●
and web servers, and applies to cloud containers, Platform as a Service (PaaS)
components, and SaaS components. Do not allow in-house developed software to
weaken configuration hardening.
8.3 Enable Operating System Anti-Exploitation Features/

Deploy Anti-Exploit Technologies
v7 Enable anti-exploitation features such as Data Execution Prevention (DEP) or
Address Space Layout Randomization (ASLR) that are available in an operating
● ●
system or deploy appropriate toolkits that can be configured to apply protection to a
broader set of applications and executables.
Page 62

6.3 Ensure that server-side scripting is disabled if not needed
(Manual)
Description:
MongoDB supports the execution of JavaScript code for certain server-side operations:
mapReduce, group, $where, $accumulator, and $function aggregation operations
that allow users to define custom aggregation expressions. If you do not use these
operations, server-side scripting should be disabled.
Rationale:
If server-side scripting is not needed and is not disabled, this introduces unnecessary
risk which may allow an attacker to take advantage of insecure coding.
Impact:
Disabling server-side scripting will block all server-side scripts from executing.
Audit:
If server-side scripting is not required, verify that it is disabled (javascriptEnabled

value of false) using the following command:
On Ubuntu:
cat /etc/mongod.conf | grep –A10 "security" | grep "javascriptEnabled"
On Windows:
type mongod.conf | findstr –A10 "security" | findstr "javascriptEnabled"
Remediation:
If server-side scripting is not required, for mongod instance disable it by using the --
noscripting option on the command line, or setting security.javascriptEnabled to
false in the configuration file.
Starting in MongoDB 4.4 this is also applicable to mongos.
Default Value:
Enabled
References:
1. https://www.mongodb.com/docs/v7.0/core/server-side-javascript/
2. https://docs.mongodb.com/manual/core/server-side-javascript/#disable-server-
side-js
Page 63

CIS Controls:
Controls
Version
2.7 Allowlist Authorized Scripts

Use technical controls, such as digital signatures and version control, to ensure
v8 that only authorized scripts, such as specific .ps1, .py, etc., files, are allowed to ●
execute. Block unauthorized scripts from executing. Reassess bi-annually, or more
frequently.
2.9 Implement Application Whitelisting of Scripts

v7 The organization's application whitelisting software must ensure that only
authorized, digitally signed scripts (such as *.ps1, *.py, macros, etc) are allowed to
●
run on a system.
4.7 Limit Access to Script Tools

v7 Limit access to scripting tools (such as Microsoft PowerShell and Python) to
only administrative or development users with the need to access those
● ●
capabilities.
7.3 Limit Use of Scripting Languages in Web Browsers

v7 and Email Clients ● ●
Ensure that only authorized scripting languages are able to run in all web
browsers and email clients.
Page 64

7 File Permissions
This section provides recommendations for setting permissions for the key file and the
database file.
Page 65

7.1 Ensure appropriate key file permissions are set (Manual)
Description:
In the Shared Cluster, the certificate or keyfile is utilized for authentications.
Implementing proper file permissions on the certificate or keyfile will prevent
unauthorized access to it.
Rationale:
Protecting the certificate/keyfile strengthens authentication in the sharded cluster and
prevents unauthorized access to the MongoDB database.
Audit:
Find the location of certificate/keyfile using the following commands:
On Ubuntu:
cat /etc/mongod.conf | grep “keyFile:”
cat /etc/mongod.conf | grep “PEMKeyFile:”
cat /etc/mongod.conf | grep “CAFile:”
On Windows:
type mongod.conf | findstr “keyFile:”
type mongod.conf | findstr “PEMKeyFile:”
type mongod.conf | findstr “CAFile:”
Check the permission of the file using:

ls -l certificate_file_locations
ls -l keyfile_locations
Remediation:
Set the keyFile ownership to mongodb user and remove other permissions by
executing these commands:
chmod 600 /keyfile
sudo chown mongodb:mongodb /keyfile
Default Value:
Not configured
References:
1. https://www.mongodb.com/docs/v7.0/tutorial/deploy-replica-set-with-keyfile-
access-control/
Page 66

CIS Controls:
Controls
Version
3.11 Encrypt Sensitive Data at Rest

Encrypt sensitive data at rest on servers, applications, and databases containing
sensitive data. Storage-layer encryption, also known as server-side encryption,
v8 meets the minimum requirement of this Safeguard. Additional encryption methods ● ●
may include application-layer encryption, also known as client-side encryption,
where access to the data storage device(s) does not permit access to the plain-text
data.
v7 16.4 Encrypt or Hash all Authentication Credentials ● ●

Encrypt or hash with a salt all authentication credentials when stored.
Page 67

7.2 Ensure appropriate database file permissions are set.
(Manual)
Description:
MongoDB database files need to be protected using file permissions.
Rationale:
This will restrict unauthorized users from accessing the database.
Audit:
To verify that the permissions for the MongoDB database file are configured securely,
run the following commands.
Find out the database location using the following command:
On Ubuntu:
cat /etc/mongod.conf |grep "dbpath"
or
cat /etc/mongod.conf | grep "dbPath"
Use the database location as part of the following command to view and verify the
permissions set for the database file:
Example:
$ stat -c '%a' /var/lib/mongodb
On Windows:
type mongod.conf | findstr "dbpath"
Use the database location as part of the following command to view and verify the
permissions set for the database file:
icacls "dbpath"
Remediation:
Set ownership of the database file to mongodb user and remove other permissions
using the following commands:
chmod 770 /var/lib/mongodb
chown mongodb:mongodb /var/lib/mongodb
Default Value:
Not configured
Page 68

References:
setting-storage.dbPath
CIS Controls:
Controls
Version
3.3 Configure Data Access Control Lists

Configure data access control lists based on a user’s need to know. Apply data
v8 access control lists, also known as access permissions, to local and remote file
● ● ●
systems, databases, and applications.

Protect all information stored on systems with file system, network share,
v7 claims, application, or database specific access control lists. These controls will
enforce the principle that only authorized individuals should have access to the
● ● ●
information based on their need to access the information as a part of their
responsibilities.
Page 69

Appendix: Summary Table
CIS Benchmark Recommendation Set
Correctly
Yes No
1 Installation and Patching
1.1 Ensure the appropriate MongoDB software  

version/patches are installed (Manual)
2 Authentication
2.1 Ensure Authentication is configured (Automated)  
2.2 Ensure that MongoDB does not bypass authentication  

via the localhost exception (Automated)
2.3 Ensure authentication is enabled in the sharded cluster  

(Automated)
3 Authorization
3.1 Ensure least privilege for database accounts (Manual)  
3.2 Ensure that role-based access control is enabled and  

configured appropriately (Manual)
3.3 Ensure that MongoDB is run using a non-privileged,  

dedicated service account (Manual)
3.4 Ensure that each role for each MongoDB database is  

needed and grants only the necessary privileges
(Manual)
3.5 Review Superuser/Admin Roles (Manual)  
4 Data Encryption
4.1 Ensure legacy TLS protocols are disabled (Automated)  
4.2 Ensure Weak Protocols are Disabled (Automated)  
4.3 Ensure Encryption of Data in Transit TLS or SSL  

(Transport Encryption) (Automated)
Page 70

CIS Benchmark Recommendation Set
Correctly
Yes No
4.4 Ensure Federal Information Processing Standard (FIPS)  

is enabled (Automated)
4.5 Ensure Encryption of Data at Rest (Manual)  
5 Audit Logging
5.1 Ensure that system activity is audited (Automated)  
5.2 Ensure that audit filters are configured properly (Manual)  
5.3 Ensure that logging captures as much information as  

possible (Automated)
5.4 Ensure that new entries are appended to the end of the  
log file (Automated)
6 Operating System Hardening
6.1 Ensure that MongoDB uses a non-default port  

(Automated)
6.2 Ensure that operating system resource limits are set for  
MongoDB (Manual)
6.3 Ensure that server-side scripting is disabled if not  

needed (Manual)
7 File Permissions
7.1 Ensure appropriate key file permissions are set (Manual)  
7.2 Ensure appropriate database file permissions are set.  

(Manual)
Page 71

Appendix: CIS Controls v7 IG 1 Mapped
Recommendations
Recommendation Set
Correctly
Yes No
1.1 Ensure the appropriate MongoDB software
 
version/patches are installed
3.1 Ensure least privilege for database accounts  
 
configured appropriately
3.3 Ensure that MongoDB is run using a non-privileged,
 
dedicated service account
3.4 Ensure that each role for each MongoDB database is
 
3.5 Review Superuser/Admin Roles  
5.1 Ensure that system activity is audited  
5.2 Ensure that audit filters are configured properly  
5.3 Ensure that logging captures as much information as
 
possible
Page 72

Recommendations
Recommendation Set
Correctly
Yes No
 
2.1 Ensure Authentication is configured  
2.2 Ensure that MongoDB does not bypass authentication
 
via the localhost exception
 
 
 
4.1 Ensure legacy TLS protocols are disabled  
4.2 Ensure Weak Protocols are Disabled  
4.3 Ensure Encryption of Data in Transit TLS or SSL
 
(Transport Encryption)
4.4 Ensure Federal Information Processing Standard (FIPS)
 
is enabled
 
possible
5.4 Ensure that new entries are appended to the end of the
 
log file
 
MongoDB
6.3 Ensure that server-side scripting is disabled if not needed  
7.1 Ensure appropriate key file permissions are set  
Page 73

Recommendation Set
Correctly
Yes No
Page 74

Recommendations
Recommendation Set
Correctly
Yes No
 
 
 
 
 
 
 
is enabled
4.5 Ensure Encryption of Data at Rest  
 
possible
 
log file
 
MongoDB
Page 75

Recommendation Set
Correctly
Yes No
Page 76

Appendix: CIS Controls v7 Unmapped
Recommendations
Recommendation Set
Correctly
Yes No
No unmapped recommendations to CIS Controls v7  
Page 77

Recommendations
Recommendation Set
Correctly
Yes No
 
 
 
possible
Page 78

Recommendations
Recommendation Set
Correctly
Yes No
 
 
 
 
 
 
is enabled
 
possible
 
log file
 
MongoDB
Page 79

Recommendation Set
Correctly
Yes No
Page 80

Recommendations
Recommendation Set
Correctly
Yes No
 
 
 
 
 
 
 
is enabled
 
possible
 
log file
 
MongoDB
Page 81

Recommendation Set
Correctly
Yes No
Page 82

Appendix: CIS Controls v8 Unmapped
Recommendations
Recommendation Set
Correctly
Yes No
No unmapped recommendations to CIS Controls v8  
Page 83

Appendix: Change History
Date Version Changes for this version
10-23-2024 1.1.0 Added support for 7.0.15
Page 84

CIS MongoDB 7 Benchmark v1.1.0 PDF

Uploaded by

Copyright:

Available Formats

CIS MongoDB 7 Benchmark v1.1.0 PDF

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CIS MongoDB 7 Benchmark v1.1.0 PDF

Uploaded by

Copyright:

Available Formats

CIS MongoDB 7

Internal Only - General

Internal Only - General

Internal Only - General

Internal Only - General

In the end, the CIS Benchmarks™ are designed to be a key component of a

Important Usage Information

When remediating systems (changing configuration settings on

Internal Only - General

CIS-CAT® Pro is also available to CIS SecureSuite® members.

Target Technology Details

Internal Only - General

• For Windows: "\bin\mongod.cfg"

Internal Only - General

Internal Only - General

Used for blocks of code, command, and

Used for inline code, commands, UI/Menu

Text set in angle brackets denote a variable

Used to reference other relevant settings,

Additional information or caveats things like

Internal Only - General

Internal Only - General

CIS Critical Security Controls® (CIS Controls®)

Internal Only - General

Items in this profile apply to MongoDB and intend to:

o be practical and prudent;

o are intended for environments or use cases where security is paramount

Internal Only - General

Internal Only - General

Internal Only - General

1. Backup the data set.

Internal Only - General

2.3 Address Unauthorized Software

2.2 Ensure Software is Supported by Vendor

Internal Only - General

Internal Only - General

• LDAP proxy authentication

Internal Only - General

The value for authorization must be set to enabled.

• Use the mongo command-line authentication options (--username, --password,

• Start the MongoDB instance without authentication.

mongod --port 27017 --dbpath /data/db1

mongod.exe --port 27017 --dbpath db1

Internal Only - General

• Open mongod.conf and change for authorization value to enabled:

• Restart the MongoDB instance

service mongod restart

5.2 Use Unique Passwords

6.3 Require MFA for Externally-Exposed Applications

16.3 Require Multi-factor Authentication

Internal Only - General

Internal Only - General

6.3 Require MFA for Externally-Exposed Applications

16.3 Require Multi-factor Authentication

Internal Only - General

Internal Only - General

Internal Only - General

Internal Only - General

6.6 Establish and Maintain an Inventory of Authentication

1.8 Utilize Client Certificates to Authenticate Hardware