{ "id": 37, "benchmarkId": "Redis_Enterprise_6-x_STIG", "slug": "redis_enterprise_6x", "status": "accepted", "statusDate": "2024-09-04T00:00:00.000Z", "title": "Redis Enterprise 6.x Security Technical Implementation Guide", "description": "This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DOD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.", "version": "2", "createdAt": "2025-10-21T11:13:12.677Z", "updatedAt": "2025-10-23T20:54:39.209Z", "groups": [ { "id": 2643, "benchmarkId": 37, "groupId": "V-251190", "title": "SRG-APP-000089-DB-000064", "description": "", "ruleId": "SV-251190r960879_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-001400", "ruleTitle": "Redis Enterprise DBMS must provide audit record generation capability for DoD-defined auditable events within all DBMS/database components.", "ruleVulnDiscussion": "Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. \n\nAudit records can be generated from various components within the DBMS (e.g., process, module). Certain specific application functionalities may be audited as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.\n\nDoD has defined the list of events for which the DBMS will provide an audit record generation capability as the following: \n\n(i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n\n(ii) Access actions, such as successful and unsuccessful login attempts, privileged activities, or other system-level access, starting and ending time for user access to the system, concurrent logins from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and\n\n(iii) All account creation, modification, disabling, and termination actions.\n\nOrganizations may define additional events requiring continuous or ad hoc auditing.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000169", "ruleFixText": "Logging verbosity on Redis Enterprise can be changed for error messages and debugging purposes. Auditing and logging levels for user actions on the control plane does not change and cannot be configured.\n\nConfigure the verbosity to the organizationally defined level:\n\n1. Enter the relevant node and run the following commands (run on each desired node): \n- ccs-cli hset dmc: log_level \n- ccs-cli hset dmc: mgmt_log_level \n\n2. Reconfigure the DMC: \nrlutil dmc_reconf dmc=\n\n3. Set a specific log level in the DMC for a given DB:\n- ccs-cli hset bdb: log_level \n- rlutil dmc_reconf bdb= \n\nLogging levels include:\n1. Debug (DBG) - at this level, anything goes, to include whatever a developer finds useful for debugging. This level should very rarely be active in production and is intended for developers only.\n\n2. Trace (TRC) - used for tracking specific elements' lifespan, issues a few messages (only those important for tracing element) per flow. It might be used in production, under very restrictive and careful watch, for very short periods of time.\n\n3. Info (INF) - positive events changing the behavior of app or one of its major elements: a key component started, configuration changed, etc.\n\n4. Warn (WRN) - events that have temporary (usually recoverable) negative impact on one or more major application elements (server went down, a temporary lack or resources, etc.), such events lead to undesired impact on many sub-elements, while others can still function properly.\n\n5. Error (ERR) - unexpected, harmful events - a key element/component cannot function properly, there is no way to recover proper functionality until this situation is resolved (configuration in accessible, or fundamentally broken, network unreachable, etc.).\n\n6. Fatal (FTL) - unrecoverable state. Usually, the last message (or one of very few of them) in an app's lifetime.\n\nNOTICE: Level info (3) and above are enabled by default.", "ruleFixId": "F-54579r804759_fix", "ruleCheckSystem": "C-54625r804758_chk", "ruleCheckContent": "Review the organization documentation to determine the organization-defined auditable events.\n\nTo validate the log of an event, check the logs tab for configuration actions within Redis Enterprise.\n \nOn the Redis Enterprise UI:\n1. Log in to Redis Enterprise.\n2. Navigate to the logs page.\n3. Review the logs as needed to verify they meet organizationally defined audit events.\n\nOn the underlying server, logs may also be found in /var/opt/redislabs/log/\n\nThe eventlog.log and cnm_http log files contain all logs.\n\nTo check, perform an event that should trigger an organizationally defined audit log.\n\nReview logs in the UI, and in /var/opt/redislabs/log/eventlog.log and /var/opt/redislabs/log/cnm_http.log for applicable event logs.\n\nCheck DBMS auditing to determine whether organization-defined auditable events are being audited by the system.\n\nTo check the current verbosity (log level), run the following command from the underlying node (as root):\n\nccs-cli hget dmc: log_level and ccs-cli hget dmc: mgmt_log_level\n\nIf the field does not exist it means the DMC is working with its default log_level which is \"info\".\n\nIf the action is not captured in the logs page audit trail, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2636, "benchmarkId": 37, "groupId": "V-251183", "title": "SRG-APP-000001-DB-000031", "description": "", "ruleId": "SV-251183r960735_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "RD6X-00-000100", "ruleTitle": "Redis Enterprise DBMS must limit the number of concurrent sessions to an organization-defined number per user for all accounts and/or account types.", "ruleVulnDiscussion": "Database management includes the ability to control the number of users and user sessions utilizing a DBMS. Unlimited concurrent connections to the DBMS could allow a successful denial-of-service (DoS) attack by exhausting connection resources; and a system can also fail or be degraded by an overload of legitimate users. Limiting the number of concurrent sessions per user is helpful in reducing these risks.\n\nThis requirement addresses concurrent session control for a single account. It does not address concurrent sessions by a single user via multiple system accounts; and it does not deal with the total number of sessions across all accounts.\n\nThe capability to limit the number of concurrent sessions per user must be configured in or added to the DBMS (for example, by use of a logon trigger), when this is technically feasible. Note that it is not sufficient to limit sessions via a web server or application server alone, because legitimate users and adversaries can potentially connect to the DBMS by other means.\n\nThe organization will need to define the maximum number of concurrent sessions by account type, by account, or a combination thereof. In deciding on the appropriate number, it is important to consider the work requirements of the various types of users. For example, 2 might be an acceptable limit for general users accessing the database via an application; but 10 might be too few for a database administrator using a database management GUI tool, where each query tab and navigation pane may count as a separate session.\n\n(Sessions may also be referred to as connections or logons, which for the purposes of this requirement are synonyms.)", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000054", "ruleFixText": "To modify the number of maximum sessions, run the following command:\n\nrladmin tune db max_connections \ne.g., - rladmin tune db inline-jp-staging max_connections 15000", "ruleFixId": "F-54572r804738_fix", "ruleCheckSystem": "C-54618r804737_chk", "ruleCheckContent": "Redis sets this limit by default at 10k clients per shard. It reserves 32 for descriptors for internal use. The organization can set a limit based on its needs during the configuration. When the set limit is reached, Redis will deny all new incoming connections and inform senders \"max number of clients reached\".\n\nTo check for maximum connections, run the following command:\nrladmin info db db: \n\nwhere db:1 would be:\nrladmin info db db:1 \n\nSearch in the output for max_connections. If the max connections are greater than the organizationally defined value, this is a finding.\n\nNote: Redis Enterprise 6 does support multiple users; however, it does not support the ability to limit connections per user. If using Redis Cluster, the max number of connections remains 10k; however, each node will use two connections (incoming/outgoing).", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2642, "benchmarkId": 37, "groupId": "V-251189", "title": "SRG-APP-000342-DB-000302", "description": "", "ruleId": "SV-251189r961359_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-001100", "ruleTitle": "Execution of software modules (to include stored procedures, functions, and triggers) with elevated privileges must be restricted to necessary cases only.", "ruleVulnDiscussion": "In certain situations, to provide required functionality, a DBMS needs to execute internal logic (stored procedures, functions, triggers, etc.) and/or external code modules with elevated privileges. However, if the privileges required for execution are at a higher level than the privileges assigned to organizational users invoking the functionality applications/programs, those users are indirectly provided with greater privileges than assigned by organizations.\n\nPrivilege elevation must be used only where necessary and protected from misuse.\n\nThis calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers, and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.\n\nRedis Enterprise comes with the ability to run Redis Enterprise software modules within each database to extend the database functionality.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002233", "ruleFixText": "To remove a module from the Redis Enterprise Software:\n1. Log in to the adminUI as an administrator.\n2. Navigate to the \"settings\" tab.\n3. Under \"redis modules\" to the far-right of each individual module, click the trashcan icon to remove the associated module.\n\nTo remove a module from an existing database, the database needs to be recreated without the authorized modules and migrate all applications and data to the new database. Once a module is installed within a database, removal is not supported.", "ruleFixId": "F-54578r804756_fix", "ruleCheckSystem": "C-54624r804755_chk", "ruleCheckContent": "To verify that each database is not using these modules, perform the following steps:\n1. Log in to the Redis Enterprise control plane.\n2. Navigate to the databases tab.\n3. Inspect each database for Redis modules within the database application. If the databases display \"None\" next to the Redis Modules field, no modules are installed.\n\nIf a module is present and a necessary use case is not documented, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2637, "benchmarkId": 37, "groupId": "V-251184", "title": "SRG-APP-000023-DB-000001", "description": "", "ruleId": "SV-251184r960768_rule", "ruleWeight": "10.0", "ruleSeverity": "high", "ruleVersion": "RD6X-00-000700", "ruleTitle": "Redis Enterprise DBMS must integrate with an organization-level authentication/access mechanism providing account management and automation for all users, groups, roles, and any other principals.", "ruleVulnDiscussion": "Enterprise environments make account management for applications and databases challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other error. Managing accounts for the same person in multiple places is inefficient and prone to problems with consistency and synchronization.\n\nA comprehensive application account management process that includes automation helps to ensure that accounts designated as requiring attention are consistently and promptly addressed. \n\nExamples include, but are not limited to, using automation to act on multiple accounts designated as inactive, suspended, or terminated, or by disabling accounts located in non-centralized account stores, such as multiple servers. Account management functions can also include assignment of group or role membership; identifying account type; specifying user access authorizations (i.e., privileges); account removal, update, or termination; and administrative alerts. The use of automated mechanisms can include, for example: using email or text messaging to notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using automated telephone notification to report atypical system account usage.\n\nThe DBMS must be configured to automatically use organization-level account management functions, and these functions must immediately enforce the organization's current account policy. \n\nAutomation may be comprised of differing technologies that when placed together contain an overall mechanism supporting an organization's automated account management requirements.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000015", "ruleFixText": "Integrate Redis Enterprise with LDAP to provide organization-level authentication/access mechanism and account management for all users, groups, roles, and any other principals.\n\nFor each DBMS-managed account that is not documented and approved, either transfer it to management by the external mechanism or document the need for it and obtain approval as appropriate.\n\nTo enable LDAP:\n1. Import the saslauthd configuration.\n2. Restart saslauthd service.\n3. Configure LDAP users.\n\nConfiguring LDAP:\nTo provide the LDAP configuration information:\n1. Edit the configuration file located at /etc/opt/redislabs/saslauthd.conf or the installation directory used during initial configuration.\n\n2. Provide the following information associated with each variable:\n- ldap_servers: the ldap servers that authenticate against and the port to use:\nPort 389 is standardly used for unencrypted LDAP connections\nPort 636 is standardly used for encrypted LDAP connections and is strongly recommended.\n- Ldap_tls_cacert_file (optional): The path to the CA Certificates. This is required for encrypted LDAP connections only.\n- ldap_filter: the filter used to search for users.\n- ldap_bind_dn: The distinguished name for the user that will be used to authenticate to the LDAP server.\n- ldap_password: The password used for the user specified in ldap_bind_dn\n\n3. Import the saslauthd configuration into Redis Enterprise using the command below, which will distribute the configuration to all nodes in the cluster:\nrladmin cluster config saslauthd_ldap_conf \n\nNote: For this command to work on a new server installation, a cluster must be set up already.\n\n4. Restart saslauthd:\nsudo supervisorctl restart saslauthd", "ruleFixId": "F-54573r804741_fix", "ruleCheckSystem": "C-54619r804740_chk", "ruleCheckContent": "Redis Enterprise supports LDAP for access to the Redis Enterprise web UI. If all accounts are authenticated by the organization-level authentication/access mechanism and not by the DBMS, this is not a finding. LDAP can be checked by examining the process used during user login on the Redis web UI.\n\nIf any accounts are managed by Redis Enterprise, review the system documentation for justification and approval of these accounts. Compare the documented accounts with those found on the system.\n\nIf any Redis Enterprise-managed accounts exist that are not documented and approved, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2638, "benchmarkId": 37, "groupId": "V-251185", "title": "SRG-APP-000033-DB-000084", "description": "", "ruleId": "SV-251185r960792_rule", "ruleWeight": "10.0", "ruleSeverity": "high", "ruleVersion": "RD6X-00-000800", "ruleTitle": "Redis Enterprise DBMS must enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.", "ruleVulnDiscussion": "Authentication with a DoD-approved PKI certificate does not necessarily imply authorization to access the DBMS. To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD systems, including databases, must be properly configured to implement access control policies. \n\nSuccessful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. \n\nAccess control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system. \n\nThis requirement is applicable to access control enforcement applications, a category that includes database management systems. If the DBMS does not follow applicable policy when approving access, it may be in conflict with networks or other applications in the information system. This may result in users either gaining or being denied access inappropriately and in conflict with applicable policy.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000213", "ruleFixText": "To modify the commands or keys a user is able to access, perform the following steps:\n\n1. Log in to Redis Enterprise.\n2. Navigate to the access controls tab.\n3. Ensure the appropriate role is configured by inspecting the Redis ACL rules and Roles in the Redis ACL and Role sub-tabs.\n4. If an appropriate role is not present, create the appropriate role.\n5. On the users tab, assign the appropriate role to the user in question.", "ruleFixId": "F-54574r804744_fix", "ruleCheckSystem": "C-54620r804743_chk", "ruleCheckContent": "Review the system documentation to determine if accounts have been set with appropriate, organizationally defined role-based permissions. Compare these settings with the settings on the actual DB.\n\nTo find the database id, run the command:\nrladmin status extra all.\n\n1. Log in to Redis Enterprise.\n2. Navigate to the access controls tab.\n3. Verify that each user is assigned an appropriate role.\n\nIf a user is not assigned an appropriate role, this is a finding. \n\nIf the appropriate role is not assigned to a user, or the roles and permission settings are not documented, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2639, "benchmarkId": 37, "groupId": "V-251186", "title": "SRG-APP-000328-DB-000301", "description": "", "ruleId": "SV-251186r961317_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-000900", "ruleTitle": "Redis Enterprise DBMS must enforce discretionary access control policies, as defined by the data owner, over defined subjects and objects.", "ruleVulnDiscussion": "Discretionary Access Control (DAC) is based on the notion that individual users are \"owners\" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled table permissions.\n\nWhen discretionary access control policies are implemented, subjects are not constrained with regard to what actions they can take with information for which they have already been granted access. Thus, subjects that have been granted access to information are not prevented from passing (i.e., the subjects have the discretion to pass) the information to other subjects or objects. \n\nA subject that is constrained in its operation by Mandatory Access Control policies is still able to operate under the less rigorous constraints of this requirement. Thus, while Mandatory Access Control imposes constraints preventing a subject from passing information to another subject operating at a different sensitivity level, this requirement permits the subject to pass the information to any subject at the same sensitivity level. \n\nThe policy is bounded by the information system boundary. Once the information is passed outside of the control of the information system, additional means may be required to ensure the constraints remain in effect. While the older, more traditional definitions of discretionary access control require identity-based access control, that limitation is not required for this use of discretionary access control.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002165", "ruleFixText": "To assign a user to a role:\n1. Log in to Redis Enterprise as an admin user.\n2. Navigate to the access controls tab.\n3. Ensure that each user is assigned a role according to organizationally defined policy.\n\nTo configure a Redis ACL rule that can be assigned to a user role:\n1. Navigate to access control >> redis acls.\n2. Edit an existing Redis ACL by hovering over a Redis ACL and clicking \"Edit\".\n3. Create a new Redis ACL by clicking \"Add\".\n4. Enter a descriptive name for the Redis ACL. This will be used to reference the ACL rule to the role.\n5. Define the ACL rule.\n6. Click \"Save\".\n\nFor more information: \nhttps://docs.redislabs.com/latest/rs/security/passwords-users-roles/", "ruleFixId": "F-54575r804747_fix", "ruleCheckSystem": "C-54621r804746_chk", "ruleCheckContent": "Redis Enterprise discretionary access control is configured through the use of individual roles. Verify that enforcement of role-based access control (RBAC) is implemented.\n\nReview the system documentation to determine if accounts have been set with appropriate, organizationally defined Discretionary Access Control permissions. Compare these settings with the settings on the actual DB.\n\n1. Log in to Redis Enterprise.\n2. Navigate to the access controls tab.\n3. Verify that each user is assigned a role. If a user is not assigned an appropriate role, this is a finding.\n\nIf the appropriate access is not assigned to a user, or the access and permission settings are not documented, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2640, "benchmarkId": 37, "groupId": "V-251187", "title": "SRG-APP-000328-DB-000301", "description": "", "ruleId": "SV-251187r961317_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-000950", "ruleTitle": "Redis Enterprise DBMS must enforce access control lists, as defined by the data owner, over defined subjects and objects.", "ruleVulnDiscussion": "Discretionary Access Control (DAC) is based on the notion that individual users are \"owners\" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled table permissions.\n\nWhen discretionary access control policies are implemented, subjects are not constrained with regard to what actions they can take with information for which they have already been granted access. Thus, subjects that have been granted access to information are not prevented from passing (i.e., the subjects have the discretion to pass) the information to other subjects or objects. \n\nA subject that is constrained in its operation by Mandatory Access Control policies is still able to operate under the less rigorous constraints of this requirement. Thus, while Mandatory Access Control imposes constraints preventing a subject from passing information to another subject operating at a different sensitivity level, this requirement permits the subject to pass the information to any subject at the same sensitivity level. \n\nThe policy is bounded by the information system boundary. Once the information is passed outside of the control of the information system, additional means may be required to ensure the constraints remain in effect. While the older, more traditional definitions of discretionary access control require identity-based access control, that limitation is not required for this use of discretionary access control.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002165", "ruleFixText": "To configure a Redis ACL rule that can be assigned to a user role:\n1. Navigate to access control >> redis acls.\n2. Edit an existing Redis ACL by hovering over a Redis ACL and clicking \"Edit\".\n3. Create a new Redis ACL by clicking \"Add\".\n4. Enter a descriptive name for the Redis ACL. This will be used to reference the ACL rule to the role.\n5. Define the ACL rule.\n6. Click \"Save\".\n\nAssign ACLs to roles and roles to users as appropriate.\n\nFor more information: \nhttps://docs.redislabs.com/latest/rs/security/passwords-users-roles/", "ruleFixId": "F-54576r804750_fix", "ruleCheckSystem": "C-54622r804749_chk", "ruleCheckContent": "Review the system documentation to determine what organizationally defined Access Control permissions should be in place. Compare these settings with the settings on the actual DB.\n\n1. Log in to Redis Enterprise.\n2. Navigate to the access controls tab >> redis acls\n3. Review ACLs for appropriate rules. If ACL rules are not defined as appropriate in system documentation, this is a finding.\n4. Review roles.\n5. Verify that each role is assigned an appropriate ACL. If a role is not assigned an appropriate ACL, this is a finding.\n6. Review users.\n7. Verify that each user is assigned a role. If a user is not assigned an appropriate role, this is a finding.\n\nIf any user accounts implicitly gain “Full Access” through the user/role/ACL relationship and are not authorized, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2641, "benchmarkId": 37, "groupId": "V-251188", "title": "SRG-APP-000340-DB-000304", "description": "", "ruleId": "SV-251188r961353_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-001000", "ruleTitle": "Redis Enterprise DBMS must prevent non-privileged users from executing privileged functions, to include disabling, circumventing, or altering implemented security safeguards/countermeasures.", "ruleVulnDiscussion": "Preventing non-privileged users from executing privileged functions mitigates the risk that unauthorized individuals or processes may gain unnecessary access to information or privileges. \n\nSystem documentation should include a definition of the functionality considered privileged.\n\nDepending on circumstances, privileged functions can include, for example, establishing accounts, performing system integrity checks, or administering cryptographic key management activities. Non-privileged users are individuals that do not possess appropriate authorizations. Circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms are examples of privileged functions that require protection from non-privileged users.\n\nA privileged function in the DBMS/database context is any operation that modifies the structure of the database, its built-in logic, or its security settings. This would include all Data Definition Language (DDL) statements and all security-related statements. In an SQL environment, it encompasses, but is not necessarily limited to: \nCREATE\nALTER\nDROP\nGRANT\nREVOKE\nDENY\n\nThere may also be Data Manipulation Language (DML) statements that, subject to context, should be regarded as privileged. Possible examples include:\nTRUNCATE TABLE;\nDELETE, or\nDELETE affecting more than n rows, for some n, or\nDELETE without a WHERE clause;\n\nUPDATE or\nUPDATE affecting more than n rows, for some n, or\nUPDATE without a WHERE clause;\n\nany SELECT, INSERT, UPDATE, or DELETE to an application-defined security table executed by other than a security principal.\n\nDepending on the capabilities of the DBMS and the design of the database and associated applications, the prevention of unauthorized use of privileged functions may be achieved by means of DBMS security features, database triggers, other mechanisms, or a combination of these.\n\nRedis Enterprise comes with a configurable role-based access control mechanism that allows users to be given specific roles. These roles provide various levels of permissions to security safeguards and countermeasures.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002235", "ruleFixText": "To ensure that a non-privileged user is not granted a non-default role, perform the following steps:\n1. Log in to the Redis Enterprise control plane.\n2. Navigate to the access control tab.\n3. Navigate to the users tab and review the roles for users.\n4. Assign users an appropriate role, and if necessary, create a new role for the user.\n5. Modify and save the users' new role after ensuring the role is provided with the appropriate permissions.", "ruleFixId": "F-54577r804753_fix", "ruleCheckSystem": "C-54623r804752_chk", "ruleCheckContent": "To verify this, perform the following steps:\n1. Log in to the Redis Enterprise control plane.\n2. Navigate to the access control tab.\n3. Navigate to the users tab and review the roles for users.\n4. For users without the need to modify the database, verify they are given a viewer or none for cluster management in the roles tab.\n5. For users with access to databases, verify they are given the default role \"Not Dangerous\" or a more restrictive role that does not allow access to the dangerous command category.\n\nIf a non-privileged user is granted a non-default role, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2644, "benchmarkId": 37, "groupId": "V-251191", "title": "SRG-APP-000090-DB-000065", "description": "", "ruleId": "SV-251191r960882_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-001500", "ruleTitle": "Redis Enterprise DBMS must allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.", "ruleVulnDiscussion": "Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent or interfere with the auditing of critical events.\n\nSuppression of auditing could permit an adversary to evade detection.\n\nMisconfigured audits can degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000171", "ruleFixText": "Configure the DBMS's settings to allow designated personnel to select which auditable events are audited. This can be done on Redis Enterprise with ACLs and RBAC.\n\nTo configure RBAC:\n1. Log in to the Redis Control Plane as an admin user.\n2. Navigate to the access control tab.\n3. Provide the appropriate permissions and privileges as defined by the organization.", "ruleFixId": "F-54580r804762_fix", "ruleCheckSystem": "C-54626r804761_chk", "ruleCheckContent": "Auditing alerts can be selected on Redis Enterprise. With the RBAC settings, by default, only the Admin group can configure these events in the database. Additional roles with admin privileges can also be configured.\n\nTo view which roles have admin level privileges:\n1. Log in to Redis Enterprise.\n2. Navigate to the Access control tab and review the users listed therein.\n\nTo view which alerts are configured:\n1. Log in to Redis Enterprise.\n2. Navigate to the Databases tab.\n3. Select any database to view and select the configuration tab.\n4. Scroll down to determine which Alerts are selected to be emailed to the appropriate audiences (if any).\n\nIf designated personnel are not able to configure auditable events, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2645, "benchmarkId": 37, "groupId": "V-251192", "title": "SRG-APP-000508-DB-000358", "description": "", "ruleId": "SV-251192r961839_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-004400", "ruleTitle": "Redis Enterprise DBMS must generate audit records for all direct access to the database(s).", "ruleVulnDiscussion": "In this context, direct access is any query, command, or call to the DBMS that comes from any source other than the application(s) that it supports. Examples would be the command line or a database management utility program. The intent is to capture all activity from administrative and non-standard sources.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000172", "ruleFixText": "Configure the host RHEL OS to generate audit records whenever a user calls the redis-cli command. This can be done by adding a rule to the /etc/audit/audit.rules to generate records when /opt/redislabs/bin/redis-cli and /opt/redislabs/bin/rladmin is called.\n\nExample Linux commands:\n-a always,exit -F path=/opt/redislabs/bin/redis-cli -F perm=x -F auid>=1000 -F auid!=unset -k privileged-priv_change\n-a always,exit -F path=/opt/redislabs/bin/rladmin -F perm=x -F auid>=1000 -F auid!=unset -k privileged-priv_change\n\nThe audit daemon must be restarted for the changes to take effect.", "ruleFixId": "F-54581r804765_fix", "ruleCheckSystem": "C-54627r804764_chk", "ruleCheckContent": "All local access to the server is handled by the underlying RHEL OS server that hosts the Redis Enterprise DBMS and is viewable in syslog. Additionally, RHEL can be configured to audit direct access to Redis Enterprise by modifying the rule set in /etc/audit/audit.rules to include the redis-cli and rladmin command found in /opt/redislabs/bin. \n\nTo determine if the OS is auditing direct and privileged access/execution of the database and database configuration options on the server:\ncat to /etc/audit/audit.rules \n\nExamine the audit rules defined for rules that specify that command calls for /opt/redislabs/bin/redis-cli and /opt/redislabs/bin/rladmin are audited, if not present, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2646, "benchmarkId": 37, "groupId": "V-251195", "title": "SRG-APP-000357-DB-000316", "description": "", "ruleId": "SV-251195r961392_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-005500", "ruleTitle": "Redis Enterprise DBMS must allocate audit record storage capacity in accordance with organization-defined audit record storage requirements.", "ruleVulnDiscussion": "To ensure sufficient storage capacity for the audit logs, the DBMS must be able to allocate audit record storage capacity. Although another requirement (SRG-APP-000515-DB-000318) mandates that audit data be offloaded to a centralized log management system, it remains necessary to provide space on the database server to serve as a buffer against outages and capacity limits of the offloading mechanism.\n\nThe task of allocating audit record storage capacity is usually performed during initial installation of the DBMS and is closely associated with the DBA and system administrator roles. The DBA or system administrator will usually coordinate the allocation of physical drive space with the application owner/installer and the application will prompt the installer to provide the capacity information, the physical location of the disk, or both.\n\nIn determining the capacity requirements, consider such factors as: total number of users; expected number of concurrent users during busy periods; number and type of events being monitored; types and amounts of data being captured; the frequency/speed with which audit records are offloaded to the central log management system; and any limitations that exist on the DBMS's ability to reuse the space formerly occupied by offloaded records.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001849", "ruleFixText": "Ensure that the server is configured with enough storage space to accommodate database and audit record storage. The right amount of storage will be dependent on a variety of factors such as: number of databases, database size, HA enabled, persistence enabled, etc.\n\nAt no time should storage be more than 95 percent full.\n\nSee the following documents for hardware requirements:\nhttps://docs.redislabs.com/latest/rs/administering/designing-production/hardware-requirements/\nand\nhttps://docs.redislabs.com/latest/rs/installing-upgrading/file-locations/", "ruleFixId": "F-54584r855601_fix", "ruleCheckSystem": "C-54630r855600_chk", "ruleCheckContent": "Review organization documentation to determine the organization-defined audit record storage requirements. By default, Redis Enterprise will use whatever disk space is allocated for audit logs. It is the responsibility of the organization to ensure that the RHEL OS server hosting the service has been allocated enough storage space to avoid running out of log space.\n\nInterview the system administrator and review audit log configuration and alerts to investigate whether there have been any incidents where the Redis Enterprise server ran out of audit log space since the last time the space was allocated, or other corrective measures were taken. \n\nIf such incidents have occurred, this is a finding.\n\nReview the Redis Enterprise control pane as an admin user. \n\nIf alerts are present indicating that storage is full or is at 95 percent full, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2647, "benchmarkId": 37, "groupId": "V-251196", "title": "SRG-APP-000515-DB-000318", "description": "", "ruleId": "SV-251196r961860_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-005600", "ruleTitle": "Redis Enterprise DBMS must offload audit data to a separate log management facility; this must be continuous and in near real time for systems with a network connection to the storage facility, and weekly or more often for stand-alone systems.", "ruleVulnDiscussion": "Information stored in one location is vulnerable to accidental or incidental deletion or alteration.\n\nOffloading is a common process in information systems with limited audit storage capacity. \n\nThe DBMS may write audit records to database tables, to files in the file system, to other kinds of local repository, or directly to a centralized log management system. Whatever the method used, it must be compatible with offloading the records to the centralized system.\n\nFor more information, refer to: \nhttps://docs.redislabs.com/latest/rs/administering/logging/rsyslog-logging/\nand\nhttps://redislabs.com/blog/sending-redis-cluster-alerts-to-slack-with-syslog/", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001851", "ruleFixText": "Configure Redis Enterprise to offload log entries onto a separate log server by configuring the redislabs.conf and ensuring that all server logs from syslog are offloaded to a centralized backup server.\n\nTo configure Redis Enterprise to use syslog for all logs generated, ensure that redislabs.conf exists and is configured.\n\nCreate the file as shown here:\n/etc/rsyslog.d/redislabs.conf\n\nThe log entries can be categorized into events and alerts. Events are only logged, while alerts have a state attached to them. RS log entries include information about the specific event that occurred. In addition, rsyslog can be configured to add other information, such as the event severity, for example.\n\nSince rsyslog entries do not include the severity information by default, use the following instructions to log that information (in Ubuntu): \nAdd the following line to /etc/rsyslog.conf $template TraditionalFormatWithPRI,\"%pri-text%:%timegenerated%:%HOSTNAME%:%syslogtag%:%msg:::drop-last-lf%\\n\"\n\nAnd modify $ActionFileDefaultTemplate to use the new template: $ActionFileDefaultTemplateTraditionalFormatWithPRI \n\nSave the changes and restart rsyslog for the changes to take effect. Alerts and events can be viewed under /var/log in messages log file.\n\nCommand components:\n%pri­text% ­adds the severity.\n%timegenerated% ­adds the timestamp.\n%HOSTNAME% ­adds the machine name.\n%syslogtag% ­the RS message as detailed below in the Log entry structure section below.\n%msg:::drop­last­lf%n ­ removes duplicated log entries.\n\nExample configuration:\ntemplate(name=\"RedisLabsEventTemplate\" type=\"string\" string=\"%syslogseverity-text%:%pri-text%:%timegenerated%:%HOSTNAME%:%syslogtag%:%msg:::drop-last-lf% -- %syslogtag% -- %programname% \\n\")\n\nif $programname startswith 'event_log' then {\n action(type=\"omfile\" file=\"/var/log/redislabs.log\" template=\"RedisLabsEventTemplate\" )\n}\n\nWith this configuration, the syslog service will:\nLoad a new template named RedisLabsEventTemplate that logs the message with the priority (syslogseverity-text) that will be info, crit, warning, etc.\n\nUse this template to write into the file /var/log/redislabs.log when the program is \"event_log\" (the Redis Enterprise log manager). Learn more about the template syntax in the syslog documentation. \n\nRestart syslog: systemctl restart rsyslog\n\nTesting the new configuration:\nNavigate to the Redis Enterprise web console and create a new database (or edit an existing database). There should be a new /var/log/redislabs.log file and the event that was generated.", "ruleFixId": "F-54585r855603_fix", "ruleCheckSystem": "C-54631r804776_chk", "ruleCheckContent": "Review the system documentation for a description of how audit records are offloaded. By default, all log entries shown on the log page in the Redis Enterprise UI are also written to syslog. Then, rsyslog can be configured to monitor the syslog. All alerts are logged to syslog if the alerts are configured to be enabled, in addition to other log entries. These logs can be configured to be offloaded to a centralized log management system.\n\nVerify that Redis Enterprise is configured on the server to send all logs to a centralized log management system by examining the redislabs.conf file found in /etc/rsyslog.d.\n\nThe file should include the line:\n action(type=\"omfwd\" protocol=\"tcp\" target=\"[organization defined logging server IP]\" port=\"[organization defined logging server port]\" template=\"RedisLabsEventTemplate\" )\n\nIf it does not, this is a finding.\n\nIf the DBMS has a continuous network connection to the centralized log management system, but the DBMS audit records are not written directly to the centralized log management system or transferred in near-real-time, this is a finding.\n\nIf the DBMS does not have a continuous network connection to the centralized log management system, and the DBMS audit records are not transferred to the centralized log management system weekly or more often, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2648, "benchmarkId": 37, "groupId": "V-251197", "title": "SRG-APP-000359-DB-000319", "description": "", "ruleId": "SV-251197r961398_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-005700", "ruleTitle": "Redis Enterprise DBMS must provide a warning to appropriate support staff when allocated audit record storage volume reaches 75 percent of maximum audit record storage capacity.", "ruleVulnDiscussion": "Organizations are required to use a central log management system, so under normal conditions, the audit space allocated to the DBMS on its own server will not be an issue. However, space will still be required on the DBMS server for audit records in transit, and, under abnormal conditions, this could fill up. Since a requirement exists to halt processing upon audit failure, a service outage would result.\n\nIf support personnel are not notified immediately upon storage volume utilization reaching 75 percent, they are unable to plan for storage capacity expansion. \n\nThe appropriate support staff include, at a minimum, the ISSO and the DBA/SA.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001855", "ruleFixText": "To configure cluster alerts:\n1. Log in to the Redis Enterprise AdminUI (repeat this step for the following sections as well).\n2. Navigate to settings >> alerts. Alerts may be enabled for node or cluster events, such as high memory usage or throughput.\n\nConfigurable alerts may be displayed as follows:\n- As a warning icon for the node and cluster\n- In the logs \n- In email notifications, if email alerts are configured\nNote: If alerts are enabled for \"Node joined\" or \"Node removed\" actions, \"Receive email alerts\" must also be enabled so the notifications are sent.\n\nTo enable alerts for a cluster:\nIn settings >> alerts, select the desired alerts to show for the cluster and click \"Save\".\n\nDatabase alerts: \nFor each database, alerts may be enabled for database events, such as high memory usage or throughput.\n\nConfigured alerts are shown:\n- As a warning icon (Warning) for the database\n- In the log\n- In emails, if email alerts are configured\n\nTo enable alerts for a database:\n1. In configuration for each database, click show advanced options to view and select the database alerts.\n2. Click \"Update\".\n\nTo send cluster or database alerts by email:\n1. Log in to the Redis Enterprise UI.\n2. Navigate to settings >> alerts, then select Receive email alerts at the bottom of the page.\n3. Configure the email server settings.\n4. In access control, select for each user the database and cluster alerts that are to be received by the user.", "ruleFixId": "F-54586r804780_fix", "ruleCheckSystem": "C-54632r855605_chk", "ruleCheckContent": "To verify that Redis Enterprise has been configured to send appropriate support staff when allocated audit record storage volume reaches 75 percent of maximum audit record storage capacity:\n1. Log in to the Redis Enterprise UI as a user with the Admin role.\n2. Navigate to the Settings tab and then to Alerts.\n3. Verify that the appropriate Alerts are enabled to notify support staff when storage volume reaches 75 percent.\n4. Navigate to the General subtab and scroll down to verify that an email server is set up to send out alert notifications.\n5. Lastly, navigate to the Access Control tab and verify that the appropriate users listed are configured to receive alert notifications.\n\nTo view on a specific database:\n1. Navigate to the Databases tab on the UI.\n2. Select the Databases from the list and then select configuration.\n3. Scroll down to view the Alert settings.\n\nAlso verify that the RHEL server OS is STIG compliant to notify support staff when allocated audit record storage volume reaches 75 percent of the repository maximum audit record storage capacity.\n\nIf appropriate support staff are not notified immediately upon storage volume utilization reaching 75 percent, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2649, "benchmarkId": 37, "groupId": "V-251198", "title": "SRG-APP-000360-DB-000320", "description": "", "ruleId": "SV-251198r961401_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-005800", "ruleTitle": "Redis Enterprise DBMS must provide an immediate real-time alert to appropriate support staff of all audit log failures.", "ruleVulnDiscussion": "Redis Enterprise does not send immediate real-time alerts to support staff in the event of audit log failures; however, the host RHEL server can be configured to send such alerts using scripts or other third-party tools.\n\nIt is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without a real-time alert, security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected. \n\nThe appropriate support staff include, at a minimum, the ISSO and the DBA/SA.\n\nA failure of database auditing will result in either the database continuing to function without auditing or in a complete halt to database operations. When audit processing fails, appropriate personnel must be alerted immediately to avoid further downtime or unaudited transactions.\n\nAlerts provide organizations with urgent messages. Real-time alerts provide these messages immediately (i.e., the time from event detection to alert occurs in seconds or less).", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001858", "ruleFixText": "Configure the system to provide an immediate real-time alert to appropriate support staff when an audit log failure occurs.\n\nIt is possible to create scripts or implement third-party tools to enable real-time alerting for audit log failures, depending on the underlying OS.\n\nAdditionally, it is recommended to enable the following alerts from within the Redis Enterprise AdminUI Console:\n\n1. Log in to the AdminUI.\n2. Navigate to settings >> alerts.\n- Receive email alerts (with the appropriate email server settings configured under settings >> general)\n- Node has sufficient disk space for AOF rewrite\n- Multiple nodes are down - this may cause data loss", "ruleFixId": "F-54587r804783_fix", "ruleCheckSystem": "C-54633r804782_chk", "ruleCheckContent": "Review the OS or third-party logging software settings to determine whether a real-time alert will be sent to the appropriate personnel when auditing fails for any reason.\n\nIf real-time alerts are not sent upon auditing failure, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2650, "benchmarkId": 37, "groupId": "V-251199", "title": "SRG-APP-000109-DB-000049", "description": "", "ruleId": "SV-251199r960915_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-005900", "ruleTitle": "Redis Enterprise DBMS must by default shut down upon audit failure, to include the unavailability of space for more audit log records; or must be configurable to shut down upon audit failure.", "ruleVulnDiscussion": "Redis Enterprise can be configured to generate alerts for certain other key events, but not in the instance of an audit failure. The DBMS would depend on the base Linux OS to detect and shut down in the event of an audit processing failure.\n\nIt is critical that when the DBMS is at risk of failing to process audit logs as required, it take action to mitigate the failure. Audit processing failures include software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode. \n\nWhen the need for system availability does not outweigh the need for a complete audit trail, the DBMS should shut down immediately, rolling back all in-flight transactions.\n\nSystems where audit trail completeness is paramount will most likely be at a lower MAC level than MAC I; the final determination is the prerogative of the application owner, subject to Authorizing Official concurrence. In any case, sufficient auditing resources must be allocated to avoid a shutdown in all but the most extreme situations.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000140", "ruleFixText": "Modify DBMS, OS, or third-party logging application settings to alert appropriate personnel when a specific percentage of log storage capacity is reached.", "ruleFixId": "F-54588r804786_fix", "ruleCheckSystem": "C-54634r804785_chk", "ruleCheckContent": "If the application owner has determined that the need for system availability outweighs the need for a complete audit trail, this is not applicable. \n\nOtherwise, review the procedures, manual and/or automated, for monitoring the space used by audit trail(s) and for offloading audit records to a centralized log management system.\n\nIf the procedures do not exist, this is a finding.\n\nIf the procedures exist, request evidence that they are followed. If the evidence indicates that the procedures are not followed, this is a finding.\n\nIf the procedures exist, inquire if the system has ever run out of audit trail space in the last two years or since the last system upgrade, whichever is more recent. If it has run out of space in this period, and the procedures have not been updated to compensate, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2651, "benchmarkId": 37, "groupId": "V-251200", "title": "SRG-APP-000109-DB-000321", "description": "", "ruleId": "SV-251200r960915_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-006000", "ruleTitle": "Redis Enterprise DBMS must be configurable to overwrite audit log records, oldest first (First-In-First-Out [FIFO]), in the event of unavailability of space for more audit log records.", "ruleVulnDiscussion": "It is critical that when the DBMS is at risk of failing to process audit logs as required, it take action to mitigate the failure. Audit processing failures include software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode. \n\nWhen availability is an overriding concern, approved actions in response to an audit failure are as follows: \n\n(i) If the failure was caused by the lack of audit record storage capacity, the DBMS must continue generating audit records, if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner.\n\n(ii) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, the DBMS must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server.\n\nSystems where availability is paramount will most likely be MAC I; the final determination is the prerogative of the application owner, subject to Authorizing Official concurrence. In any case, sufficient auditing resources must be allocated to avoid audit data loss in all but the most extreme situations.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000140", "ruleFixText": "Redis Enterprise uses the default logrotate daemon to schedule rotation of logs stored on the operating system. The configuration of log rotation may be found at /etc/logrotate.d.\n\nBy default, the log rotation should occur on a daily basis. Redis Labs recommends sending log files to a remote logging server so that they can be more effectively maintained.\n\nTo modify the log rotation policy perform the following steps:\n1. sudo vi /etc/logrotate.conf (The location of the log rotation configuration may vary depending on operating system distribution.)\n2. Modify the log rotation configuration to meet the needs of the application.", "ruleFixId": "F-54589r804789_fix", "ruleCheckSystem": "C-54635r804788_chk", "ruleCheckContent": "Redis Enterprise uses the default logrotate daemon to schedule rotation of logs stored on the operating system. The configuration of log rotation may be found at /etc/logrotate.d.\n\nBy default, the log rotation should occur on a daily basis. Redis Labs recommends sending log files to a remote logging server so that they can be more effectively maintained.\n\nTo check the log rotation policy, perform the following steps:\n1. sudo cat /etc/logrotate.conf (The location of the log rotation configuration may vary depending on operating system distribution.)\n2. Investigate the log rotation policy to verify that the appropriate policy is applied for all logs.\n\nCheck to verify that log rotation is not disabled and is appropriate for the application by investigating the logrotated configuration. If log rotation is not enabled or is not configured appropriately, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2652, "benchmarkId": 37, "groupId": "V-251201", "title": "SRG-APP-000374-DB-000322", "description": "", "ruleId": "SV-251201r961443_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-006200", "ruleTitle": "Redis Enterprise DBMS must record time stamps, in audit records and application data, that can be mapped to Coordinated Universal Time (UTC, formerly GMT).", "ruleVulnDiscussion": "If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis.\n\nTime stamps generated by the DBMS must include date and time. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. \n\nSome DBMS products offer a data type called TIMESTAMP that is not a representation of date and time. Rather, it is a database state counter and does not correspond to calendar and clock time. This requirement does not refer to that meaning of TIMESTAMP.\n\nRedis Enterprise application components allow the setting of a UTC timestamp associated with the logs of the database.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001890", "ruleFixText": "To resolve an issue with the timestamps, perform the following steps:\n1. Log in to the Redis Enterprise Control Plane.\n2. Navigate to the settings tab.\n3. Navigate to the general tab of the settings tab.\n4. On screen find the Time zone setting.\n5. Ensure that the time zone is mapped to UTC.\n6. Click \"Save\".", "ruleFixId": "F-54590r804792_fix", "ruleCheckSystem": "C-54636r804791_chk", "ruleCheckContent": "To check the timestamp, perform the following steps:\n1. Log in to the Redis Enterprise Control Plane.\n2. Navigate to the settings tab.\n3. Navigate to the general tab of the settings tab.\n4. On screen find the Time zone setting.\n5. Verify that the time zone is mapped to UTC.\n\nIf the time zone isn't mapped to UTC, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2653, "benchmarkId": 37, "groupId": "V-251202", "title": "SRG-APP-000118-DB-000059", "description": "", "ruleId": "SV-251202r960930_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-006400", "ruleTitle": "The audit information produced by Redis Enterprise DBMS must be protected from unauthorized read access.", "ruleVulnDiscussion": "If audit data were to become compromised, competent forensic analysis and discovery of the true source of potentially malicious system activity would be difficult, if not impossible, to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage.\n\nTo ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, copy, etc.\n\nThis requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files enjoy the proper file system permissions, utilizing file system protections, and limiting log data location. \n\nAdditionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring that audit information is protected from unauthorized access.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000162", "ruleFixText": "To investigate the log files used by Redis Enterprise, perform the following steps:\n1. SSH into the server running Redis Enterprise.\n2. Issue the command chmod 640 /var/opt/redislabs/log/* to change permissions of log files that are not appropriately assigned permissions.\n3. Issue the command chown owner:group -R /var/opt/redislabs/log/ if the ownership is not correct where the owner and group are substituted for the appropriate owner and group.", "ruleFixId": "F-54591r804795_fix", "ruleCheckSystem": "C-54637r804794_chk", "ruleCheckContent": "To investigate the log files used by Redis Enterprise, perform the following steps:\n1. SSH into the server running Redis Enterprise.\n2. Issue the command cd /var/opt/redislabs/log\n3. Issue the command ls -ltr ./\n\nInvestigate the permissions on these files. These permissions should be 640 or 660 and assigned to the installation user and group or another appropriate group. If the permissions are readable by other or assigned an inappropriate owner/group, this is a finding.\n\nRedis Enterprise does not support the ability to perform transaction logging.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2654, "benchmarkId": 37, "groupId": "V-251203", "title": "SRG-APP-000119-DB-000060", "description": "", "ruleId": "SV-251203r960933_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-006500", "ruleTitle": "The audit information produced by Redis Enterprise DBMS must be protected from unauthorized modification.", "ruleVulnDiscussion": "If audit data were to become compromised, competent forensic analysis and discovery of the true source of potentially malicious system activity would be impossible to achieve. \n\nTo ensure the veracity of audit data the information system and/or the application must protect audit information from unauthorized modification. \n\nThis requirement can be achieved through multiple methods that will depend upon system architecture and design. Some commonly employed methods include ensuring log files enjoy the proper file system permissions and limiting log data locations. \n\nApplications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding user rights in order to make access decisions regarding the modification of audit data.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. \n\nModification of database audit data could mask the theft of, or the unauthorized modification of, sensitive data stored in the database.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000163", "ruleFixText": "To investigate the log files used by Redis Enterprise, perform the following steps:\n1. SSH into the server running Redis Enterprise.\n2. Issue the command chmod 640 /var/opt/redislabs/log/* to change permissions of log files that are not appropriately assigned permissions.\n3. Issue the command chown owner:group -R /var/opt/redislabs/log/ if the ownership is not correct where the owner and group are substituted for the appropriate owner and group.", "ruleFixId": "F-54592r804798_fix", "ruleCheckSystem": "C-54638r804797_chk", "ruleCheckContent": "To investigate the log files used by Redis Enterprise, perform the following steps:\n1. SSH into the server running Redis Enterprise.\n2. Issue the command cd /var/opt/redislabs/log\n3. Issue the command ls -ltr ./\n\nInvestigate the permissions on these files. These permissions should be 640 or 660 and assigned to the installation user and group or another appropriate group. If the permissions are readable by other or assigned an inappropriate owner/group, this is a finding.\n\nRedis Enterprise does not support the ability to perform transaction logging.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2655, "benchmarkId": 37, "groupId": "V-251204", "title": "SRG-APP-000120-DB-000061", "description": "", "ruleId": "SV-251204r960936_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-006600", "ruleTitle": "The audit information produced by Redis Enterprise DBMS must be protected from unauthorized deletion.", "ruleVulnDiscussion": "If audit data were to become compromised, competent forensic analysis and discovery of the true source of potentially malicious system activity would be impossible to achieve.\n\nTo ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods which will depend upon system architecture and design.\n\nSome commonly employed methods include: ensuring log files enjoy the proper file system permissions utilizing file system protections; restricting access; and backing up log data to ensure log data is retained.\n\nApplications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit data.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.\n\nDeletion of database audit data could mask the theft of, or the unauthorized modification of, sensitive data stored in the database.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000164", "ruleFixText": "To investigate the log files used by Redis Enterprise, perform the following steps:\n1. SSH into the server running Redis Enterprise.\n2. Issue the command chmod 640 /var/opt/redislabs/log/* to change permissions of log files that are not appropriately assigned permissions.\n3. Issue the command chown owner:group -R /var/opt/redislabs/log/ if the ownership is not correct where the owner and group are substituted for the appropriate owner and group.\n\nRedis Enterprise provides configurable role-based access control inherently within the product. To ensure that users are provided the appropriate permissions that they are authorized to use, check each user's assigned roles.\n1. Log in to Redis Enterprise.\n2. Navigate to the access controls tab.\n3. Navigate to the users tab.\n4. Ensure that each user is given a role appropriate for their authorization level.", "ruleFixId": "F-54593r804801_fix", "ruleCheckSystem": "C-54639r804800_chk", "ruleCheckContent": "To investigate the log files used by Redis Enterprise stored on the operating system, perform the following steps:\n1. SSH into the server running Redis Enterprise.\n2. Issue the command cd /var/opt/redislabs/log\n3. Issue the command ls -ltr ./\n\nInvestigate the permissions on these files. These permissions should be 640 or 660 and assigned to the installation user and group or another appropriate group. \n\nIf the permissions are readable by other or assigned an inappropriate owner/group, this is a finding.\n\nRedis Enterprise does not support the ability to perform transaction logging.\n\nRedis Enterprise also provides configurable role-based access control inherently within the product. This is available to users with the cluster viewer. To verify that users are provided the appropriate permissions that they are authorized to use, check each user's assigned roles.\n1. Log in to Redis Enterprise.\n2. Navigate to the access controls tab.\n3. Navigate to the users tab.\n4. Review all roles assigned to a user and verify that user is given the appropriate role for their authorization level. Roles with the Cluster Management Role of admin, cluster_member, cluster_viewer, or db_member are able to view logs in the UI.\n\nIf the user is not given the appropriate role, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2656, "benchmarkId": 37, "groupId": "V-251205", "title": "SRG-APP-000121-DB-000202", "description": "", "ruleId": "SV-251205r960939_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-006700", "ruleTitle": "Redis Enterprise DBMS must protect its audit features from unauthorized access.", "ruleVulnDiscussion": "Redis Enterprise does not come with unique tools to view log data and logging is not configurable. Logs are stored in a standard log file on the host operating system that is accessible using standard Linux tooling. Only users in the admin role can view or modify privileged settings in the Redis Enterprise UI.\n\nProtecting audit data also includes identifying and protecting the tools used to view and manipulate log data. \n\nDepending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. It is, therefore, imperative that access to audit tools be controlled and protected from unauthorized access. \n\nApplications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the access to audit tools.\n\nAudit tools include, but are not limited to, OS-provided audit tools, vendor-provided audit tools, and open-source audit tools needed to successfully view and manipulate audit information system activity and records. \n\nIf an attacker were to gain access to audit tools, they could analyze audit logs for system weaknesses or weaknesses in the auditing itself. An attacker could also manipulate logs to hide evidence of malicious activity.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001493", "ruleFixText": "Apply or modify access controls and permissions (in the file system/operating system) to tools used to view or modify audit log data. Tools must be accessible by authorized personnel only.\n\n/var/opt/redislabs/log/ (or whatever the organizationally defined location for Redis logs) should have an appropriate and documented admin user and group owner, and the directory should not have permissions more than 700. \n\nTo update these permissions, run the following commands:\nchown redislabs:redislabs /var/opt/redislabs/log\nchmod 700 /var/opt/redislabs/log", "ruleFixId": "F-54594r804804_fix", "ruleCheckSystem": "C-54640r804803_chk", "ruleCheckContent": "For validating privilege on the OS, verify user ownership, group ownership, and permissions on the Redis audit directory.\n\nFrom Linux command line as root:\n> ls - ald /var/opt/redislabs/log/ (or whatever the organizationally defined location for Redis logs)\n\nIf the User owner is not a defined admin, this is a finding.\n\nIf the Group owner is not a defined admin group, this is a finding.\n\nIf the directory is more permissive than 700, this is a finding.\n\nFor validating privileges on the control plane, verify Redis Admin users listed on the control plane against documented approved admin users. If any users have unauthorized admin privileges, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2657, "benchmarkId": 37, "groupId": "V-251206", "title": "SRG-APP-000122-DB-000203", "description": "", "ruleId": "SV-251206r960942_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-006800", "ruleTitle": "Redis Enterprise DBMS must protect its audit configuration from unauthorized modification.", "ruleVulnDiscussion": "Redis Enterprise does not come with unique tools to view log data and logging is not configurable. Logs are stored in a standard log file on the host operating system that is accessible using standard Linux tooling. Only users in the admin role can view or modify privileged settings in the Redis Enterprise UI.\n\nProtecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.\n\nApplications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the modification of audit tools.\n\nAudit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001494", "ruleFixText": "Apply or modify access controls and permissions (in the file system/operating system) to tools used to view or modify audit log data. Tools must be accessible by authorized personnel only.\n\n/var/opt/redislabs/log/ (or whatever the organizationally defined location for Redis logs) should have an appropriate and documented admin user and group owner and the directory should not have permissions more than 700. \n\nTo update these permissions, run the following commands:\nchown redislabs:redislabs /var/opt/redislabs/log\nchmod 700 /var/opt/redislabs/log", "ruleFixId": "F-54595r804807_fix", "ruleCheckSystem": "C-54641r804806_chk", "ruleCheckContent": "For validating privilege on the OS, verify user ownership, group ownership, and permissions on the redis audit directory. \n\nFrom Linux command line as root:\n> ls - ald /var/opt/redislabs/log/ (or whatever the organizationally defined location for Redis logs)\n\nIf the User owner is not a defined admin, this is a finding. \n\nIf the Group owner is not a defined admin group, this is a finding.\n\nIf the directory is more permissive than 700, this is a finding.\n\nFor validating privileges on the control plane, verify Redis Admin users that are listed on the control plane against documented approved admin users. If any users have unauthorized admin privileges, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2658, "benchmarkId": 37, "groupId": "V-251207", "title": "SRG-APP-000123-DB-000204", "description": "", "ruleId": "SV-251207r960945_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-006900", "ruleTitle": "Redis Enterprise DBMS must protect its audit features from unauthorized removal.", "ruleVulnDiscussion": "Redis Enterprise does not come with unique tools to view log data and logging is not configurable. Logs are stored in a standard log file on the host operating system that is accessible using standard Linux tooling. Only users in the admin role can view or modify privileged settings in the Redis Enterprise UI.\n\nProtecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.\n\nApplications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit tools.\n\nAudit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001495", "ruleFixText": "Apply or modify access controls and permissions (in the file system/operating system) to tools used to view or modify audit log data. Tools must be accessible by authorized personnel only.\n\n/var/opt/redislabs/log/ (or whatever the organizationally defined location for Redis logs) should have an appropriate and documented admin user and group owner and the directory should not have permissions more than 700. \n\nTo update these permissions, run the following commands:\nchown redislabs:redislabs /var/opt/redislabs/log\nchmod 700 /var/opt/redislabs/log", "ruleFixId": "F-54596r804810_fix", "ruleCheckSystem": "C-54642r804809_chk", "ruleCheckContent": "For validating privilege on the OS, verify user ownership, group ownership, and permissions on the Redis audit directory:\n\nFrom Linux command line as root:\n> ls - ald /var/opt/redislabs/log/ (or whatever the organizationally defined location for Redis logs)\n\nIf the User owner is not a defined admin, this is a finding. \n\nIf the Group owner is not a defined admin group, this is a finding.\n\nIf the directory is more permissive than 700, this is a finding.\n\nFor validating privileges on the control plane, verify Redis Admin users that are listed on the control plane against documented approved admin users. If any users have unauthorized admin privileges, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2659, "benchmarkId": 37, "groupId": "V-251208", "title": "SRG-APP-000378-DB-000365", "description": "", "ruleId": "SV-251208r1018617_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-007000", "ruleTitle": "Redis Enterprise DBMS must prohibit user installation of logic modules (stored procedures, functions, triggers, views, etc.) without explicit privileged status.", "ruleVulnDiscussion": "Redis Enterprise permits the installation of logic modules through a control plane layer to the database, which requires privilege access to the control plane. This is provisioned for support during database runtime by a user with permissions to create a database.\n\nThe ability to load modules directly within the database is not supported in Redis Enterprise; however, it is supported in open-source Redis.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-003980", "ruleFixText": "To ensure a regular user is unable to perform updates:\n1. Log in to the Redis Enterprise control plane.\n2. Navigate to the access controls tab.\n3. In the users section, review each users role to ensure they are assigned the appropriate permissions.\n4. If a user is not assigned appropriate permissions, ensure they are moved to an appropriate role.", "ruleFixId": "F-54597r804813_fix", "ruleCheckSystem": "C-54643r804812_chk", "ruleCheckContent": "Modules may be added to the Redis Enterprise control plane (adminUI) by navigating to the settings tab and then modules. Only admin users can view the settings tab.\n\nTo verify that users without explicit privileged status are not able to install modules, do the following:\n1. Log in to the Redis Enterprise control plane (adminUI) with a user with administrative privileges.\n2. Navigate to the access control tab.\n3. Verify that only organizationally defined users have the appropriate privileges.\n\nIf a user is not assigned appropriate permissions, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2660, "benchmarkId": 37, "groupId": "V-251209", "title": "SRG-APP-000380-DB-000360", "description": "", "ruleId": "SV-251209r961461_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-007100", "ruleTitle": "Redis Enterprise DBMS must enforce access restrictions associated with changes to the configuration of Redis Enterprise DBMS or database(s).", "ruleVulnDiscussion": "Failure to provide logical access restrictions associated with changes to configuration may have significant effects on the overall security of the system. \n\nWhen dealing with access restrictions pertaining to change control, it should be noted that any changes to the hardware, software, and/or firmware components of the information system can potentially have significant effects on the overall security of the system. \n\nAccordingly, only qualified and authorized individuals should be allowed to obtain access to system components for the purposes of initiating changes, including upgrades and modifications.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001813", "ruleFixText": "Redis Enterprise is an application database and not intended to be used by human actors. Human actor activity has been generally abstracted to a control plane that resides outside of the database level. \n\nTo ensure that users are in the appropriate role, perform the following steps:\n1. Log in to the Redis Enterprise Control Plane.\n2. Navigate to the access control tab.\n3. Navigate to the users tab. \n4. Ensure that the principle is assigned the appropriate permissions for their function.", "ruleFixId": "F-54598r804816_fix", "ruleCheckSystem": "C-54644r804815_chk", "ruleCheckContent": "Redis Enterprise is an application database and not intended to be used by human actors. Human actor activity has been generally abstracted to a control plane that resides outside of the database level. \n\nRedis Enterprise comes with roles for both the control plane and the data plane. Viewer roles and none provide access restrictions to make configuration changes to the database. \n\nTo verify that users are in the appropriate role, perform the following steps:\n1. Log in to the Redis Enterprise Control Plane.\n2. Navigate to the access control tab.\n3. Navigate to the users tab. \n4. Verify that all users are assigned an appropriate role. If the principle is using custom roles, this may require investigating the permissions provided for each custom role.\n\nIf it does not enforce access restrictions associated with changes to the configuration of the DBMS or database(s), this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2661, "benchmarkId": 37, "groupId": "V-251210", "title": "SRG-APP-000133-DB-000179", "description": "", "ruleId": "SV-251210r960960_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-007300", "ruleTitle": "Redis Enterprise DBMS must limit privileges to change software modules; to include stored procedures, functions, and triggers, and links to software external to Redis Enterprise DBMS.", "ruleVulnDiscussion": "If the system were to allow any user to make changes to software libraries, those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.\n\nAccordingly, only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to the database software libraries or configuration can lead to unauthorized or compromised installations.\n\nFor Redis Enterprise this is largely handled by the RHEL OS. The OS audit logs record any changes made to the database software libraries, related applications, and configuration files. Redis Enterprise also generates audit logs by default. All log entries are shown on the Log page in the Redis Enterprise web UI as well as written in the syslog. Only users in the admin role on the Redis Enterprise web UI and users with privileged access to the server can view, add, or remove modules. In both cases, this is logged.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001499", "ruleFixText": "Implement procedures to monitor for unauthorized changes to DBMS software libraries, related software application libraries, and configuration files. If a third-party automated tool is not employed, an automated job that reports file information on the directories and files of interest and compares them to the baseline report for the same will meet the requirement. Syslog can be used to track and monitor access, deletions, and modification actions of the Redis logs, system configuration files, and binaries stored on the RHEL OS.\n\nEnsure that the permissions of the Redis logs, system configuration files, and binaries are set so that only those with admin privileges can modify them on the hosting RHEL OS. Permissions can be modified using the chmod command.", "ruleFixId": "F-54599r804819_fix", "ruleCheckSystem": "C-54645r804818_chk", "ruleCheckContent": "The RHEL server OS must be STIG-compliant to ensure only appropriate users have access. Verify user ownership, group ownership, and permissions on the directories where the Redis logs, binaries ,and modules reside:\n\nFrom Linux command line as root, perform the command ls –ald on the following directory paths: \n/var/opt/redislabs - Default storage location for the cluster data, system logs, backups and ephemeral, persisted data\n/var/opt/redislabs/log - System logs for Redis Enterprise Software\n/var/opt/redislabs/run - Socket files for Redis Enterprise Software\n/etc/opt/redislabs - Default location for cluster manager configuration and certificates\n/opt/redislabs - Main installation directory for all Redis Enterprise Software binaries\n/opt/redislabs/bin - Binaries for all the utilities for command line access and managements such as \"rladmin\" or \"redis-cli\"\n/opt/redislabs/config - System configuration files\n/opt/redislabs/lib - System library files\n/opt/redislabs/sbin - System binaries for tweaking provisioning\n \nIf the user owner is not a defined admin, this is a finding.\n\nIf the group owner is not a defined admin group, this is a finding.\n\nIf the directory is more permissive than 700, this is a finding.\n\nReview monitoring procedures and implementation evidence to verify monitoring of changes to database software libraries, related applications, and configuration files is done. This is performed on the RHEL OS utilizing syslog.\n\nVerify the list of files, directories, and database application objects (procedures, functions, and triggers) being monitored is complete.\n\nIf monitoring does not occur or the list of monitored objects is not complete, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2662, "benchmarkId": 37, "groupId": "V-251211", "title": "SRG-APP-000133-DB-000198", "description": "", "ruleId": "SV-251211r960960_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-007400", "ruleTitle": "Redis Enterprise DBMS software installation account must be restricted to authorized users.", "ruleVulnDiscussion": "When dealing with change control issues, it should be noted any changes to the hardware, software, and/or firmware components of the information system and/or application can have significant effects on the overall security of the system. \n\nIf the system were to allow any user to make changes to software libraries, those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.\n\nAccordingly, only qualified and authorized individuals must be allowed access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nDBA and other privileged administrative or application owner accounts are granted privileges that allow actions that can have a great impact on database security and operation. It is especially important to grant privileged access to only those persons who are qualified and authorized to use them.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001499", "ruleFixText": "User must have root level access to the system prior to installing Redis Enterprise. Without this, the installation will not complete, and no changes will be made. Review the procedure used to install Redis Enterprise. In this procedure, users are capable of selecting their own user to own the software. Typically, this is run under a Redis Labs system user.\n\nTo check this requirement, investigate the user used and ensure that only the appropriate people are able to access this account on the host operating system.", "ruleFixId": "F-54600r804822_fix", "ruleCheckSystem": "C-54646r804821_chk", "ruleCheckContent": "To install the software, the user must have root level access to each node it will be installed on. Review the procedure used to install Redis Enterprise. In this procedure, users are capable of selecting their own user to own the software. Typically, this is run under a Redis Labs system user.\n\nTo check this requirement, investigate the user used and verify that only the appropriate people are able to access this account on the host operating system. \n\nIf more than the appropriate people can access this account, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2663, "benchmarkId": 37, "groupId": "V-251212", "title": "SRG-APP-000133-DB-000199", "description": "", "ruleId": "SV-251212r960960_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-007500", "ruleTitle": "Database software, including DBMS configuration files, must be stored in dedicated directories, or DASD pools, separate from the host OS and other applications.", "ruleVulnDiscussion": "When dealing with change control issues, it should be noted any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system.\n\nMultiple applications can provide a cumulative negative effect. A vulnerability and subsequent exploit to one application can lead to an exploit of other applications sharing the same security context. For example, an exploit to a web server process that leads to unauthorized administrative access to host system directories can most likely lead to a compromise of all applications hosted by the same system. Database software not installed using dedicated directories both threatens and is threatened by other hosted applications. Access controls defined for one application may by default provide access to the other application's database objects or directories. Any method that provides any level of separation of security context assists in the protection between applications.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001499", "ruleFixText": "To resolve this issue, perform one of the two following actions:\n1. Install Redis Enterprise on a single tenant operating system.\n2. Uninstall third-party applications that have been installed in the Redis Enterprise directories and install them in separate directories.", "ruleFixId": "F-54601r804825_fix", "ruleCheckSystem": "C-54647r804824_chk", "ruleCheckContent": "The default directories that Redis Enterprise Software uses for data and metadata are:\n\n1. /var/opt/redislabs - Default storage location for the cluster data, system logs, backups and ephemeral, persisted data\n2. /var/opt/redislabs/log - System logs for Redis Enterprise Software\n3. /var/opt/redislabs/run - Socket files for Redis Enterprise Software\n4. /etc/opt/redislabs - Default location for cluster manager configuration and certificates\n5. /tmp - Temporary files\n6. /opt/redislabs - Main installation directory for all Redis Enterprise Software binaries\n7. /opt/redislabs/bin - Binaries for all the utilities for command line access and managements such as \"rladmin\" or \"redis-cli\"\n8. /opt/redislabs/config - System configuration files\n9. /opt/redislabs/lib - System library files\n10. /opt/redislabs/sbin - System binaries for tweaking provisioning\n\nTo check this finding, examine the documentation for third-party applications and verify that no other applications are installed in these directories. It is recommended that Redis Enterprise be installed on a single tenant operating system.\n\nIf another application is using these directories on the host operating system, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2664, "benchmarkId": 37, "groupId": "V-251213", "title": "SRG-APP-000133-DB-000362", "description": "", "ruleId": "SV-251213r960960_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-007700", "ruleTitle": "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 Redis Enterprise DBMS, etc.) must be restricted to authorized users.", "ruleVulnDiscussion": "If the DBMS were to allow any user to make changes to database structure or logic, those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.\n\nAccordingly, only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to the database software libraries or configuration can lead to unauthorized or compromised installations.\n\nRedis Enterprise provides configurable role-based access control inherently within the product. To ensure that users are provided the appropriate permissions that they are authorized to use, check each user's assigned roles.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001499", "ruleFixText": "To ensure that users are provided the appropriate permissions that they are authorized to use, check each user's assigned roles.\n1. Log in to Redis Enterprise.\n2. Navigate to the access controls tab.\n3. Navigate to the users tab.\n4. Locate desired user.\n5. Assign appropriate permission based on desired authorization level.", "ruleFixId": "F-54602r804828_fix", "ruleCheckSystem": "C-54648r804827_chk", "ruleCheckContent": "To check each user's assigned role:\n1. Log in to Redis Enterprise.\n2. Navigate to the access controls tab.\n3. Navigate to the users tab.\n4. Review all roles assigned to a user and verify that user is given the appropriate role for their authorization level.\n\nIf the user is not given the appropriate role, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2665, "benchmarkId": 37, "groupId": "V-251214", "title": "SRG-APP-000516-DB-000363", "description": "", "ruleId": "SV-251214r961863_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-007800", "ruleTitle": "Redis Enterprise DBMS 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.", "ruleVulnDiscussion": "Configuring the DBMS to implement organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across the DoD that reflects the most restrictive security posture consistent with operational requirements. \n\nIn addition to this STIG, sources of guidance on security and information assurance exist. These include NSA configuration guides, CTOs, DTMs, and IAVMs. The DBMS must be configured in compliance with guidance from all such relevant sources.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000366", "ruleFixText": "Follow all DoD security configuration and implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs and IAVMs to configure the Redis Enterprise security configuration settings.", "ruleFixId": "F-54603r804831_fix", "ruleCheckSystem": "C-54649r804830_chk", "ruleCheckContent": "The organization that is implementing Redis Enterprise must review the documentation and configuration to determine if it is configured in accordance with DoD security configuration and implementation guidance, including STIGs, NSA configuration guides, CTOs, DTMs, and IAVMs.\n\nIf Redis Enterprise is not configured in accordance with security configuration settings, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2666, "benchmarkId": 37, "groupId": "V-251215", "title": "SRG-APP-000383-DB-000364", "description": "", "ruleId": "SV-251215r961470_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-007900", "ruleTitle": "Redis Enterprise DBMS must disable network functions, ports, protocols, and services deemed by the organization to be nonsecure, in accord with the Ports, Protocols, and Services Management (PPSM) guidance.", "ruleVulnDiscussion": "Use of nonsecure network functions, ports, protocols, and services exposes the system to avoidable threats.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001762", "ruleFixText": "Use firewalld commands to remove any unnecessary ports from the appropriate zone. To do this, enter the following commands as root.\n\nThis command will immediately remove a port from the configuration:\n$ firewall-cmd --zone= --remove-port=/\n\nThis command will persistently remove a port from a configuration:\n$ firewall-cmd --permanent --zone= --remove-port=/\n\nRepeat the previous commands for any port that is unauthorized for use or is not used.", "ruleFixId": "F-54604r804834_fix", "ruleCheckSystem": "C-54650r804833_chk", "ruleCheckContent": "To check this control, investigate the application documentation and understand what services and ports are in use within the application. Inspect the ports running on the server using the following command:\nsudo ss -tulw\n\nIf any ports or services that are not approved are present in the output of this command, this is a finding.\n\nRedis Enterprise makes use of the following ports:\n1. TCP 1968, Internal, Proxy traffic\n2. TCP 3333, 3334, 3335, 3336, 3337, 3338, 3339, 36379, 36380, Internal, Cluster traffic\n3. TCP 8001, Internal, External, Sentinel Traffic\n4. TCP 8002, 8004, Internal, System health monitoring\n5. TCP 8443 Internal, External, User Interface\n6. TCP 8444, 9080, Internal, Proxy Traffic\n7. TCP 9081. Internal, Active-Active \n8. TCP 8070, 8071, Internal & External, Metrics Exporter\n9. TCP 9443 (Recommended), 8080 (Recommended to be removed), REST API traffic\n10. TCP 10000-19999, Internal, External, Active-Active Database traffic\n11. TCP 20000-29999, Internal\n12. UDP 53, 5353, Internal, External DNS/mDNS traffic", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2693, "benchmarkId": 37, "groupId": "V-251243", "title": "SRG-APP-000428-DB-000386", "description": "", "ruleId": "SV-251243r1018562_rule", "ruleWeight": "10.0", "ruleSeverity": "high", "ruleVersion": "RD6X-00-010900", "ruleTitle": "Redis Enterprise DBMS 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.", "ruleVulnDiscussion": "DBMSs handling data requiring data at rest protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest. These cryptographic mechanisms may be native to the DBMS or implemented via additional software or operating system/file system settings, as appropriate to the situation.\n\nSelection of a cryptographic mechanism is based on the need to protect the integrity of organizational information. The strength of the mechanism is commensurate with the security category and/or classification of the information. Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields). \n\nThe decision whether and what to encrypt rests with the data owner and is also influenced by the physical measures taken to secure the equipment and media on which the information resides.\n\nRedis Enterprise does not inherently encrypt data at rest; however, this can be handled at the OS level.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002475", "ruleFixText": "Red Hat Enterprise Linux natively supports partition encryption through the Linux Unified Key Setup-on-disk-format (LUKS) technology. The easiest way to encrypt a partition is during installation time.\n\nFor manual installations, select the \"Encrypt\" checkbox during partition creation to encrypt the partition. When this option is selected the system will prompt for a passphrase to use in decrypting the partition. The passphrase will subsequently need to be entered manually every time the system boots.\n\nFor automated/unattended installations, it is possible to use Kickstart by adding the \"--encrypted\" and \"--passphrase=\" options to the definition of each partition to be encrypted. For example, the following line would encrypt the root partition:\npart / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=[PASSPHRASE]\n\nAny [PASSPHRASE] is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly. Omitting the \"--passphrase=\" option from the partition definition will cause the installer to pause and interactively ask for the passphrase during installation.\n\nDetailed information on encrypting partitions using LUKS can be found on the Red Hat Documentation website: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-encryption", "ruleFixId": "F-54632r804918_fix", "ruleCheckSystem": "C-54678r804917_chk", "ruleCheckContent": "Review the system documentation to determine whether the organization has defined the information at rest that is to be protected from modification, which must include, at a minimum, PII and classified information.\n\nIf no information is identified as requiring such protection, this is not a finding.\n\nVerify the operating system implements encryption to protect the confidentiality and integrity of information at rest. \n\nIf a disk or filesystem requires encryption, ask the system owner, DBA, and SA to demonstrate the use of filesystem and/or disk-level encryption. If this is required and is not found, this is a finding.\n\nTo check if full disk encryption is enabled, log in to RHEL as an Admin user and run the following commands:\n# lsblk\n\nIdentify the partition that Redis Enterprise is located on.\n# blkid /dev/[name of partition]\n\nIf the output shows TYPE=\"crypto_LUKS\" then the partition is encrypted.\n\nIf encryption must be used and is not employed, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2667, "benchmarkId": 37, "groupId": "V-251217", "title": "SRG-APP-000141-DB-000091", "description": "", "ruleId": "SV-251217r960963_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-008100", "ruleTitle": "Unused database components, DBMS software, and database objects must be removed.", "ruleVulnDiscussion": "Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions).\n\nIt is detrimental for software products to provide, or install by default, functionality exceeding requirements or mission objectives. \n\nDBMSs must adhere to the principles of least functionality by providing only essential capabilities.\n\nModules are not needed for Redis Enterprise to function properly but can make some tasks easier. The following come by default on Redis Enterprise 6:\nRedisBloom\nRediSearch\nRedisGraph\nRedisJSON\nRedisTimeSeries\n\nMore information can be found at: https://docs.redislabs.com/latest/modules/?s=modules", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000381", "ruleFixText": "Modules are not needed for Redis Enterprise to function properly but can make some tasks easier. To view/remove installed modules from the UI:\n1. Click \"Settings\" in the red banner.\n2. Click Redis modules.\n3. Find the module to be removed and click the trash can icon on the right.", "ruleFixId": "F-54606r804840_fix", "ruleCheckSystem": "C-54652r804839_chk", "ruleCheckContent": "Redis Enterprise comes with a suite of capabilities sorted into modules. These modules can be removed if deemed unnecessary. Modules are not needed for Redis Enterprise to function properly but can make some tasks easier. Check the installed modules in the UI at the following location:\n1. Log in to the Redis Enterprise UI as an Admin user.\n2. Navigate to the Settings tab.\n3. View the Redis Modules tab.\n\nIf unused components or features are installed and are not documented and authorized, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2668, "benchmarkId": 37, "groupId": "V-251218", "title": "SRG-APP-000141-DB-000092", "description": "", "ruleId": "SV-251218r960963_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-008200", "ruleTitle": "Unused database components that are integrated in Redis Enterprise DBMS and cannot be uninstalled must be disabled.", "ruleVulnDiscussion": "Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). \n\nIt is detrimental for software products to provide, or install by default, functionality exceeding requirements or mission objectives. \n\nDBMSs must adhere to the principles of least functionality by providing only essential capabilities.\n\nUnused, unnecessary DBMS components increase the attack vector for the DBMS by introducing additional targets for attack. By minimizing the services and applications installed on the system, the number of potential vulnerabilities is reduced. Components of the system that are unused and cannot be uninstalled must be disabled. The techniques available for disabling components will vary by DBMS product, OS, and the nature of the component and may include DBMS configuration settings, OS service settings, OS file access security, and DBMS user/role permissions.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000381", "ruleFixText": "To view/remove installed modules from the UI:\n1. Click \"Settings\" in the red banner.\n2. Click Redis modules.\n3. Find the module to be removed and click the trash can icon on the right.", "ruleFixId": "F-54607r804843_fix", "ruleCheckSystem": "C-54653r804842_chk", "ruleCheckContent": "Redis Enterprise comes with a suite of capabilities sorted into modules. These modules can be removed if deemed unnecessary. Check the installed modules in the UI at the following location:\n1. Log in to the Redis Enterprise UI as an Admin user.\n2. Navigate to the Settings tab.\n3. View the Redis Modules tab.\n\nIf unused components or features are present on the system, can be disabled, and are not disabled, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2669, "benchmarkId": 37, "groupId": "V-251219", "title": "SRG-APP-000141-DB-000093", "description": "", "ruleId": "SV-251219r960963_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-008300", "ruleTitle": "Access to external executables must be disabled or restricted.", "ruleVulnDiscussion": "Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). \n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. \n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nDBMSs may spawn additional external processes to execute procedures that are defined in the DBMS but stored in external host files (external procedures). The spawned process used to execute the external procedure may operate within a different OS security context than the DBMS and provide unauthorized access to the host system.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000381", "ruleFixText": "To add or remove modules or executables:\n1. Log in to the Redis Enterprise web UI as an admin user.\n2. Navigate to the settings and then Redis modules tabs. From here, modules may be freely added or removed.", "ruleFixId": "F-54608r804846_fix", "ruleCheckSystem": "C-54654r804845_chk", "ruleCheckContent": "Redis Enterprise has this feature available if any object used is approved by the ISSO. By default, external executables are not included in Redis Enterprise, and only admin users on the Redis Enterprise web UI or admins who have direct access to the server can add them.\n\nTo determine what modules or executables are applied:\n1. Log in to the Redis Enterprise web UI as an admin user.\n2. Navigate to the settings and then Redis modules tabs.\n\nVerify that no unapproved external executables exist. \n\nIf external executables do exist and are not approved by the ISSO, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2670, "benchmarkId": 37, "groupId": "V-251220", "title": "SRG-APP-000142-DB-000094", "description": "", "ruleId": "SV-251220r960966_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-008400", "ruleTitle": "Redis Enterprise DBMS must be configured to prohibit or restrict the use of organization-defined functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments.", "ruleVulnDiscussion": "To prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols/services on information systems.\n\nApplications are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., email and web services); however, doing so increases risk over limiting the services provided by any one component. \n\nTo support the requirements and principles of least functionality, the application must support the organizational requirements providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues.\n\nDatabase Management Systems using ports, protocols, and services deemed unsafe are open to attack through those ports, protocols, and services. This can allow unauthorized access to the database and through the database to other components of the information system.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000382", "ruleFixText": "Use firewalld commands to remove any unnecessary ports from the appropriate zone. To do this, enter the following commands as root:\n\nThis command will immediately remove a port from the configuration:\n$ firewall-cmd --zone= --remove-port=/\n\nThis command will persistently remove a port from a configuration:\n$ firewall-cmd --permanent --zone= --remove-port=/\n\nRepeat the previous commands for any port that is unauthorized for use or is not used.", "ruleFixId": "F-54609r804849_fix", "ruleCheckSystem": "C-54655r804848_chk", "ruleCheckContent": "To check this control, investigate the application documentation and understand what services and ports are in use within the application. Inspect the ports running on the server using the following command:\nsudo ss -tulw\n\nIf any ports or services that are not approved are present in the output of this command, this is a finding.\n\nRedis Enterprise makes use of the following ports:\n1. TCP 1968, Internal, Proxy traffic\n2. TCP 3333, 3334, 3335, 3336, 3337, 3338, 3339, 36379, 36380, Internal, Cluster traffic\n3. TCP 8001, Internal, External, Sentinel Traffic\n4. TCP 8002, 8004, Internal, System health monitoring\n5. TCP 8443, Internal, External, User Interface\n6. TCP 8444, 9080, Internal, Proxy Traffic\n7. TCP 9081, Internal, Active-Active \n8. TCP 8070, 8071, Internal & External, Metrics Exporter\n9. TCP 9443 (Recommended), 8080 (Recommended to be removed), REST API traffic\n10. TCP 10000-19999, Internal, External, Active-Active Database traffic\n11. TCP 20000-29999, Internal\n12. UDP 53, 5353, Internal, External DNS/mDNS traffic", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2671, "benchmarkId": 37, "groupId": "V-251221", "title": "SRG-APP-000389-DB-000372", "description": "", "ruleId": "SV-251221r1018618_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-008500", "ruleTitle": "Redis Enterprise DBMS must require users to reauthenticate when organization-defined circumstances or situations require reauthentication.", "ruleVulnDiscussion": "The DOD standard for authentication of an interactive user is the presentation of a Common Access Card (CAC) or other physical token bearing a valid, current, DOD-issued Public Key Infrastructure (PKI) certificate, coupled with a Personal Identification Number (PIN) to be entered by the user at the beginning of each session and whenever reauthentication is required.\n\nWithout reauthentication, users may access resources or perform tasks for which they do not have authorization. \n\nWhen applications provide the capability to change security roles or escalate the functional capability of the application, it is critical the user reauthenticate.\n\nIn addition to the reauthentication requirements associated with session locks, organizations may require reauthentication of individuals and/or devices in other situations, including (but not limited to) the following circumstances:\n\n(i) When authenticators change; \n(ii) When roles change; \n(iii) When security categories of information systems change; \n(iv) When the execution of privileged functions occurs; \n(v) After a fixed period of time; or\n(vi) Periodically.\n\nWithin the DOD, the minimum circumstances requiring reauthentication are privilege escalation and role changes.\n\nFor more information refer to: https://docs.redislabs.com/latest/rs/administering/access-control/.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-004895", "ruleFixText": "Confirm with information owner any circumstances under which a user is required to reauthenticate. If any exist, confirm they are properly documented.\n\nConfigure Redis Enterprise settings to meet organizationally defined requirements:\nUser account security \n\nTo ensure user accounts are secured and not misused, RS supports enforcement of:\n- Password complexity\n- Password expiration\n- Account lock on failed attempts\n- Account inactivity timeout\n\nTo enforce a more advanced password policy that meets the desired contractual and compliance requirements and associated organizational policies, it is recommend to use LDAP integration with an external identity provider, such as Active Directory.\n\nResetting user passwords: \nTo reset a user password from the CLI, run:\nrladmin cluster reset_password \n\nThe user is asked to enter and confirm the new password.\n\nSetting up local password complexity:\nRS allows for enforcement of a password complexity profile that meets most organizational needs. The password complexity profile is defined by:\n- At least 8 characters\n- At least one uppercase character\n- At least one lowercase character\n- At least one number (not first or last character)\n- At least one special character (not first or last character)\n- Does not contain the User ID or reverse of the User ID\n- No more than three repeating characters\nNote: The password complexity profile applies to when a new user is added or an existing user changes their password.\n\nTo enforce the password complexity profile, run:\ncurl -k -X PUT -v -H \"cache-control: no-cache\" -H \"content-type: application/json\" -u \":\" -d '{\"password_complexity\":true}' https://:9443/v1/cluster\n\nSetting local user password expiration: \nRS allows for enforced password expiration to meet compliance and contractual requirements. To enforce an expiration of a local user password after a specified number of days, run:\ncurl -k -X PUT -v -H \"cache-control: no-cache\" -H \"content-type: application/json\" -u \":\" -d '{\"password_expiration_duration\":}' https://:9443/v1/cluster\nTo disable password expiration, set the number of days to 0.\n\nAccount lock on failed attempts: \nTo prevent unauthorized access to RS, organizations may enforce account lockout after a specified number of failed login attempts.\n\nSession timeout: \nWhen logging in to the web UI, the account is automatically logged out after 15 minutes of inactivity.\n\nTo change the duration of inactivity that causes the timeout:\nFrom rladmin, run: rladmin cluster config cm_session_timeout_minutes \n\nFrom the REST API, run:\ncurl --request PUT \\\n --url https://localhost:9443/v1/cluster \\\n --header 'content-type: application/json' \\\n --data '{\n\"cm_session_timeout_minutes\": \n}'", "ruleFixId": "F-54610r804852_fix", "ruleCheckSystem": "C-54656r804851_chk", "ruleCheckContent": "Review the system documentation and the configuration of Redis Enterprise and related applications and tools.\n\nIf the information owner has identified additional cases where reauthentication is needed, but there are circumstances where the system does not ask the user to reauthenticate when those cases occur, this is a finding.\n\nRedis Enterprise requires users to reauthenticate after the configured time-out period has been met, but does not require reauthentication when permissions are updated; permissions are automatically updated and applied on both the database and the Redis Enterprise web UI. Only admin users can modify privileges and roles.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2672, "benchmarkId": 37, "groupId": "V-251222", "title": "SRG-APP-000148-DB-000103", "description": "", "ruleId": "SV-251222r960969_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-008600", "ruleTitle": "Redis Enterprise DBMS must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).", "ruleVulnDiscussion": "Redis Enterprise allows the user to configure unique users per role. Review roles and ensure roles use unique organizational principles per user to the database. Redis does come with a default user for backwards compatibility. This user may be disabled.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000764", "ruleFixText": "To fix this issue perform the following actions:\n\nTo audit this configuration:\n1. Log in to Redis Enterprise Administrative Control Plane.\n2. Go to databases tab.\n3. Select each database and review the configuration by selecting edit.\n4. Deselect the default database access tab.\n\nThis configuration will break applications designed for use with Redis 5 prior to ACLs.", "ruleFixId": "F-54611r804855_fix", "ruleCheckSystem": "C-54657r804854_chk", "ruleCheckContent": "To audit this configuration:\n1. Log in to Redis Enterprise Administrative Control Plane.\n2. Go to databases tab.\n3. Select the desired database and then the configuration subtab.\n4. Verify that Default database access is enabled. \n\nIf it is enabled, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2673, "benchmarkId": 37, "groupId": "V-251223", "title": "SRG-APP-000171-DB-000074", "description": "", "ruleId": "SV-251223r1018619_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-008800", "ruleTitle": "If passwords are used for authentication, Redis Enterprise DBMS must store only hashed, salted representations of passwords.", "ruleVulnDiscussion": "The DOD standard for authentication is DOD-approved PKI certificates.\n\nAuthentication based on User ID and Password may be used only when it is not possible to employ a PKI certificate, and requires authorizing official (AO) approval.\n\nIn such cases, database passwords stored in clear text, using reversible encryption, or using unsalted hashes would be vulnerable to unauthorized disclosure. Database passwords must always be in the form of one-way, salted hashes when stored internally or externally to the DBMS.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-004062", "ruleFixText": "Develop, document, and maintain a list of DBMS database objects, database configuration files, associated scripts, applications defined within or external to the DBMS that access the database, and DBMS/user environment files/settings in the System Security Plan.\n\nRecord whether they do or do not contain DBMS passwords. If passwords are present, ensure that they are correctly hashed using one-way, salted hashing functions, and that the hashes are protected by host system security.", "ruleFixId": "F-54612r804858_fix", "ruleCheckSystem": "C-54658r998302_chk", "ruleCheckContent": "Redis stores and displays its user passwords in encrypted form, it also and transmits passwords as one-way hashed representations utilizing SHA256. Nevertheless, any User ID and Password stores should be verified by interviewing the database administrator (DBA).\n\nInterview the DBA or ISSO and review any associated scripts, and applications defined within or external to the DBMS that access the database. The list must also include files, tables, or settings used to configure the operational environment for the DBMS and for interactive DBMS user accounts. Determine if any files contain database passwords. If any do, confirm that DBMS passwords stored internally or externally to the DBMS are encoded or encrypted.\n\nIf any passwords are stored in clear text, this is a finding.\n\nAsk the DBA/system administrator (SA)/application support staff if they have created an external password store for applications, batch jobs, and scripts to use on the database server. Verify that all passwords stored there are encrypted.\n\nIf a password store is used and any password is not encrypted, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2674, "benchmarkId": 37, "groupId": "V-251224", "title": "SRG-APP-000400-DB-000367", "description": "", "ruleId": "SV-251224r961521_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-009000", "ruleTitle": "Redis Enterprise DBMS must prohibit the use of cached authenticators after an organization-defined time period.", "ruleVulnDiscussion": "If cached authentication information is out of date, the validity of the authentication information may be questionable.\n\nFor more information on configuring time out periods on Redis Enterprise refer to:\nhttps://docs.redislabs.com/latest/rs/administering/access-control/", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002007", "ruleFixText": "Configure Redis Enterprise settings to meet organizationally defined requirements. To configure the time out period, refer to Redis Enterprise Documentation: \n\nTo set time out period for authentication, log in to the RHEL server that the Redis Enterprise database is hosted on as an admin user. Escalate to root privileges.\n1. Type: rladmin\n2. Once rladmin is started, type: cluster config cm_session_timeout_minutes \n\nBy default, the timeout is set to 15 minutes.", "ruleFixId": "F-54613r804861_fix", "ruleCheckSystem": "C-54659r804860_chk", "ruleCheckContent": "Interview the system administrator to determine what, if any, the organizational policy is for cached authentication. By default, Redis Enterprise terminates authenticators after a user logs or times out.\n\nTo view the current time out period for authentication, log in to the RHEL server that the Redis Enterprise database is hosted on as an admin user.\n1. Type: rladmin\n2. Once rladmin is started, type: info cluster \n\nCheck documentation to verify that organizationally defined limits, if any, have been set. Compare documentation to actual settings found on the DB. \n\nIf the settings do not match the documentation, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2675, "benchmarkId": 37, "groupId": "V-251225", "title": "SRG-APP-000175-DB-000067", "description": "", "ruleId": "SV-251225r961038_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-009100", "ruleTitle": "Redis Enterprise DBMS, when utilizing PKI-based authentication, must validate certificates by performing RFC 5280-compliant certification path validation.", "ruleVulnDiscussion": "The DoD standard for authentication is DoD-approved PKI certificates.\n\nA certificate's certification path is the path from the end entity certificate to a trusted root certification authority (CA). Certification path validation is necessary for a relying party to make an informed decision regarding acceptance of an end entity certificate. Certification path validation includes checks such as certificate issuer trust, time validity, and revocation status for each certificate in the certification path. Revocation status information for CA and subject certificates in a certification path is commonly provided via certificate revocation lists (CRLs) or online certificate status protocol (OCSP) responses.\n\nDatabase Management Systems that do not validate certificates by performing RFC 5280-compliant certification path validation are in danger of accepting certificates that are invalid and/or counterfeit. This could allow unauthorized access to the database.\n\nFor more information refer to: https://docs.redislabs.com/latest/rs/administering/designing-production/security/", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000185", "ruleFixText": "Configure Redis Enterprise settings to meet organizationally defined requirements. \n\n1. Replace the RS server default certificates and key on all nodes with the CA-signed certificate and restart the proxy.\n\nTo replace certificates using the rladmin CLI, run:\nrladmin cluster certificate set certificate_file .pem key_file .pem\nWhere:\ncert-name - The certificate name to replace:\nFor management UI: cm\nFor REST API: api\nFor database endpoint: proxy\nFor syncer: syncer\nFor metrics exporter: metrics_exporter\ncert-file-name - The name of the certificate file\nkey-file-name - The name of the key file\n\nNote: A certificate for the databases' endpoint should be assigned for the same domain as the cluster name. For example, for a cluster with the name \"redislabs.com\" the certificate should be for \"*.redislabs.com\".\n\n2. Add the TLS client certificates in the UI including CA certificates and any intermediate certificates by chaining the certificate into one file (can use a cat command to chain the certificates).\n\n3. On the client side, make sure to import and trust the CA and intermediate certificates (CA certificates can be chained with intermediate as one file to use and import).", "ruleFixId": "F-54614r804864_fix", "ruleCheckSystem": "C-54660r804863_chk", "ruleCheckContent": "At this time, Redis Enterprise does not support OSCP and is partially compliant with RFC 5280. Verify that the host operating system is encrypted. \n\nIf the host operating system is not encrypted or STIG-compliant, this is a finding.\n\nTo test, have the user log in to the database. If certificates are not being validated by performing RFC 5280-compliant certification path validation (i.e., \"pop up\" certificate validation), this is a finding.\n\nIf the host operating system is encrypted, run the following commands and verify that only DoD-approved PKI certificates are present and used for Redis Enterprise:\n# cd /etc/opt/redislabs\n# cat proxy_cert.pem\n\nIf no DoD-approved certificates are found, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2676, "benchmarkId": 37, "groupId": "V-251226", "title": "SRG-APP-000176-DB-000068", "description": "", "ruleId": "SV-251226r961041_rule", "ruleWeight": "10.0", "ruleSeverity": "high", "ruleVersion": "RD6X-00-009200", "ruleTitle": "Redis Enterprise DBMS must enforce authorized access to all PKI private keys stored/used by Redis Enterprise DBMS.", "ruleVulnDiscussion": "The DoD standard for authentication is DoD-approved PKI certificates. PKI certificate-based authentication is performed by requiring the certificate holder to cryptographically prove possession of the corresponding private key.\n\nIf the private key is stolen, an attacker can use the private key(s) to impersonate the certificate holder. In cases where the DBMS-stored private keys are used to authenticate the DBMS to the system's clients, loss of the corresponding private keys would allow an attacker to successfully perform undetected man-in-the-middle attacks against the DBMS system and its clients.\n\nBoth the holder of a digital certificate and the issuing authority must take careful measures to protect the corresponding private key. Private keys should always be generated and protected in FIPS 140-2 or 140-3 validated cryptographic modules.\n\nAll access to the private key(s) of the DBMS must be restricted to authorized and authenticated users. If unauthorized users have access to one or more of the DBMS's private keys, an attacker could gain access to the key(s) and use them to impersonate the database on the network or otherwise perform unauthorized actions.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000186", "ruleFixText": "Apply or modify access controls and permissions (in the file system/operating system) to tools used to view or modify where the certificates are stored. Tools must be accessible by authorized personnel only.\n\n/etc/opt/redislabs (or wherever the organizationally defined location for certificates are stored) should have an appropriate and documented admin user and group owner and the directory should not have permissions more than 700. \n\nTo update these permissions, run the following commands:\nchown redislabs:redislabs /etc/opt/redislabs\nchmod 700 /etc/opt/redislabs/proxy_cert.pem", "ruleFixId": "F-54615r804867_fix", "ruleCheckSystem": "C-54661r804866_chk", "ruleCheckContent": "All keys must be stored by the host RHEL OS that Redis Enterprise resides on. On the server, look for proxy_cert.pem found in /etc/opt/redislabs. If proxy_cert.pem has file permissions that would allow unauthorized users to access it, this is a finding. \n\nKeys can also be manipulated on the Redis Enterprise UI. RBAC prevents unauthorized users from doing this; to check:\n\nReview organization documentation to determine which users should have administrative privileges. From there:\n1. Log in to Redis Enterprise UI as a user in the administrator role.\n2. Navigate to the Access Control tab.\n3. Compare the documented users to the users found in the user settings on the web UI.\n\nIf any users have administrative privileges and are not documented, this is a finding. \n\nIf access to the DBMS's private key(s) is not restricted to authenticated and authorized users, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2677, "benchmarkId": 37, "groupId": "V-251227", "title": "SRG-APP-000177-DB-000069", "description": "", "ruleId": "SV-251227r961044_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-009300", "ruleTitle": "Redis Enterprise DBMS must map the PKI-authenticated identity to an associated user account.", "ruleVulnDiscussion": "The DoD standard for authentication is DoD-approved PKI certificates. Once a PKI certificate has been validated, it must be mapped to a DBMS user account for the authenticated identity to be meaningful to the DBMS and useful for authorization decisions.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000187", "ruleFixText": "Configure Redis Enterprise settings to meet organizationally defined requirements. Redis Enterprise uses LDAP to map authenticated identity directly to the DBMS user account.\n\n1. Before enabling LDAP in Redis Software, it is important to verify:\n- Confirmation of the LDAP groups that correspond to the levels of access on which to authorize. Each LDAP group will be mapped to a Redis Software access control role.\n- Confirmation of Redis Software access control role for each LDAP group. If role-based access controls (RBAC) have not already been set up, do so before enabling LDAP.\n\n2. The following LDAP info is needed:\n- Server URI, including host, port, and protocol details.\n- Certificate details for secure protocols.\n- Bind credentials, including Distinguished Name, password, and (optionally) client public and private keys for certificate authentication.\n- Authentication query details, whether template or query.\n- Authorization query details, whether attribute or query.\n- The Distinguished Names of LDAP groups that will be used to authorize access to Redis Software resources.\n\n3. Use Settings | LDAP to enable LDAP access.\n\n4. Map LDAP groups to access control roles.\n\n5. Update database access control lists (ACLs) to authorize role access. \nIf appropriate roles are already established, update them to include LDAP groups.\n\nFor additional information:\nhttps://docs.redislabs.com/latest/rs/security/ldap/", "ruleFixId": "F-54616r804870_fix", "ruleCheckSystem": "C-54662r804869_chk", "ruleCheckContent": "Review the Redis Enterprise configuration to verify user accounts are being mapped directly to unique identifying information within the validated PKI certificate.\n\nTo test, have the user log in to the database and verify that the unique certificate to the authenticating user is used or prompted. If user accounts are not being mapped to authenticated identities, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2678, "benchmarkId": 37, "groupId": "V-251228", "title": "SRG-APP-000178-DB-000083", "description": "", "ruleId": "SV-251228r961047_rule", "ruleWeight": "10.0", "ruleSeverity": "high", "ruleVersion": "RD6X-00-009400", "ruleTitle": "Redis Enterprise DBMS must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.", "ruleVulnDiscussion": "The DoD standard for authentication is DoD-approved PKI certificates.\n\nNormally, with PKI authentication, the interaction with the user for authentication will be handled by a software component separate from the DBMS, such as ActivID ActivClient. However, in cases where the DBMS controls the interaction, this requirement applies.\n\nTo prevent the compromise of authentication information such as passwords and PINs during the authentication process, the feedback from the system must not provide any information that would allow an unauthorized user to compromise the authentication mechanism. \n\nObfuscation of user-provided authentication secrets when typed into the system is a method used in addressing this risk. \n\nDisplaying asterisks when a user types in a password or a smart card PIN is an example of obscuring feedback of authentication secrets.\n\nThis calls for review of applications, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers, and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000206", "ruleFixText": "For Redis CLI tools, which can accept a plain-text password, and any other essential tool with the same limitation:\n1. Document the need for it, who uses it, and any relevant mitigations, and obtain AO approval.\n2. Train all users of the tool in the importance of not using the plain-text password option and in how to keep the password hidden by using the \"--askpass\" without the password option. The user will then be prompted and the password obfuscated.\n\nExample command for authentication:\nredis-cli -h -p --askpass", "ruleFixId": "F-54617r804873_fix", "ruleCheckSystem": "C-54663r804872_chk", "ruleCheckContent": "If all interaction with the user for purposes of authentication is handled by a software component separate from the DBMS, this is not a finding.\n\nThe Redis Enterprise web UI does inherently obscure passwords. For Redis CLI, 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 not, this is a finding.\n\nRequest evidence that all users of the tool are trained in the importance of using the \"--askpass\" option (and not using the plain-text password option), how to keep the password hidden, and that they adhere to this practice. If not, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2679, "benchmarkId": 37, "groupId": "V-251229", "title": "SRG-APP-000179-DB-000114", "description": "", "ruleId": "SV-251229r961050_rule", "ruleWeight": "10.0", "ruleSeverity": "high", "ruleVersion": "RD6X-00-009500", "ruleTitle": "Redis Enterprise DBMS must use NIST FIPS 140-2 or 140-3 validated cryptographic modules for cryptographic operations.", "ruleVulnDiscussion": "Use of weak or not validated cryptographic algorithms undermines the purposes of utilizing encryption and digital signatures to protect data. Weak algorithms can be easily broken and not validated cryptographic modules may not implement algorithms correctly. Unapproved cryptographic modules or algorithms should not be relied on for authentication, confidentiality, or integrity. Weak cryptography could allow an attacker to gain access to and modify data stored in the database as well as the administration settings of the DBMS.\n\nApplications, including DBMSs, utilizing cryptography are required to use approved NIST FIPS 140-2 or 140-3 validated cryptographic modules that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. \n\nNSA Type-X (where X=1, 2, 3, 4) products are NSA-certified, hardware-based encryption modules.\n\nThe standard for validating cryptographic modules will transition to the NIST FIPS 140-3 publication.\n\nFIPS 140-2 modules can remain active for up to five years after validation or until September 21, 2026, when the FIPS 140-2 validations will be moved to the historical list. Even on the historical list, CMVP supports the purchase and use of these modules for existing systems. While Federal Agencies decide when they move to FIPS 140-3 only modules, purchasers are reminded that for several years there may be a limited selection of FIPS 140-3 modules from which to choose. CMVP recommends purchasers consider all modules that appear on the Validated Modules Search Page:\nhttps://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules\n\nMore information on the FIPS 140-3 transition can be found here: \nhttps://csrc.nist.gov/Projects/fips-140-3-transition-effort/\n\nFor more detailed information on Redis, refer to:\nhttps://docs.redislabs.com/latest/rs/administering/designing-production/security/", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000803", "ruleFixText": "Configure Redis Enterprise settings to use NIST FIPS 140-2-validated cryptographic modules for cryptographic operations. To set the minimum TLS version that can be used for encrypting the data in transit between a Redis client and a Redis Enterprise cluster, use the REST API or the following rladmin command:\nrladmin> cluster config min_data_TLS_version (e.g., 1.2)\n\nEnsure that openssl is on the latest version as required by organizational policies to be FIPS compliant.", "ruleFixId": "F-54618r863363_fix", "ruleCheckSystem": "C-54664r863362_chk", "ruleCheckContent": "Review the Redis Enterprise configuration to verify it is using NIST FIPS validated cryptographic modules for cryptographic operations. Redis Enterprise uses TLS 1.2 and has a cyber suite of options that is configurable through the rladmin, REST API, and on the Redis Enterprise web UI.\n\nVerify the host operating system is encrypted. \n\nIf the host operating system is not encrypted, this is a finding.\n\nIf the host operating system is encrypted, run the following commands and verify that only DoD-approved PKI certificates are present:\n# cd /etc/opt/redislabs\n# ls \n\nVerify the following file is present: proxy_cert.pem\n\nIf no certificates are present, this is a finding.\n\nVerify TLS is configured to be used. To check this:\n1. Log in to the Redis Enterprise web UI as an admin user.\n2. Navigate to the Databases tab and select the database and then configuration.\n3. Review the configuration and verify that TLS is enabled for all communications.\n\nIf TLS is not configured to be used, this is a finding.\n\nTo check the current TLS version, run the following commands on one of the servers that is hosting Redis Enterprise as a privileged user:\n# ccs-cli\n# hgetall min_control_tls_version\n\nIf TLS is not FIPS compliant, this is a finding.\n\nTo validate the openssl version, run the following command on one of the servers that is hosting Redis Enterprise as a privileged user:\n# openssl version\n\nIf NIST FIPS validated modules are not being used for all cryptographic operations, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2694, "benchmarkId": 37, "groupId": "V-251244", "title": "SRG-APP-000429-DB-000387", "description": "", "ruleId": "SV-251244r1018563_rule", "ruleWeight": "10.0", "ruleSeverity": "high", "ruleVersion": "RD6X-00-011000", "ruleTitle": "Redis Enterprise DBMS must implement cryptographic mechanisms preventing the unauthorized disclosure of organization-defined information at rest on organization-defined information system components.", "ruleVulnDiscussion": "DBMSs handling data requiring \"data at rest\" protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest. These cryptographic mechanisms may be native to the DBMS or implemented via additional software or operating system/file system settings, as appropriate to the situation.\n\nSelection of a cryptographic mechanism is based on the need to protect the integrity of organizational information. The strength of the mechanism is commensurate with the security category and/or classification of the information. Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields).\n\nThe decision whether and what to encrypt rests with the data owner and is also influenced by the physical measures taken to secure the equipment and media on which the information resides.\n\nRedis Enterprise does not inherently encrypt data at rest; however, this can be handled at the OS level.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002476", "ruleFixText": "Red Hat Enterprise Linux natively supports partition encryption through the Linux Unified Key Setup-on-disk-format (LUKS) technology. The easiest way to encrypt a partition is during installation time.\n\nFor manual installations, select the \"Encrypt\" checkbox during partition creation to encrypt the partition. When this option is selected the system will prompt for a passphrase to use in decrypting the partition. The passphrase will subsequently need to be entered manually every time the system boots.\n\nFor automated/unattended installations, it is possible to use Kickstart by adding the \"--encrypted\" and \"--passphrase=\" options to the definition of each partition to be encrypted. For example, the following line would encrypt the root partition:\n\npart / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=[PASSPHRASE]\n\nAny [PASSPHRASE] is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly. Omitting the \"--passphrase=\" option from the partition definition will cause the installer to pause and interactively ask for the passphrase during installation.\n\nDetailed information on encrypting partitions using LUKS can be found on the Red Hat Documentation website: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-encryption", "ruleFixId": "F-54633r804921_fix", "ruleCheckSystem": "C-54679r855621_chk", "ruleCheckContent": "Review the system documentation to determine whether the organization has defined the information at rest that is to be protected from disclosure, which must include, at a minimum, PII and classified information.\n\nIf the documentation indicates no information requires such protections, this is not a finding.\n\nVerify the operating system implements encryption to protect the confidentiality and integrity of information at rest. \n\nIf a disk or filesystem requires encryption, ask the system owner, DBA, and SA to demonstrate the use of filesystem and/or disk-level encryption. If this is required and is not found, this is a finding.\n\nTo check if full disk encryption is enabled, log in to RHEL as an Admin user and run the following commands:\n# lsblk\n\nIdentify the partition that Redis Enterprise is located on.\n# blkid /dev/[name of partition]\n\nIf the output shows TYPE=\"crypto_LUKS\" then the partition is encrypted.\n\nIf encryption must be used and is not employed, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2680, "benchmarkId": 37, "groupId": "V-251230", "title": "SRG-APP-000180-DB-000115", "description": "", "ruleId": "SV-251230r961053_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-009600", "ruleTitle": "Redis Enterprise DBMS must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).", "ruleVulnDiscussion": "Non-organizational users include all information system users other than organizational users, which include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations). \n\nNon-organizational users must be uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization when related to the use of anonymous access, such as accessing a web server.\n\nAccordingly, a risk assessment is used in determining the authentication needs of the organization.\n\nScalability, practicality, and security are simultaneously considered in balancing the need to ensure ease of use for access to federal information and information systems with the need to protect and adequately mitigate risk to organizational operations, organizational assets, individuals, other organizations, and the nation.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000804", "ruleFixText": "When adding user access to the database, either during initial creation or at a later time, admins must establish a unique username and password for all users and the default user account must be disabled.\n\nIn web UI:\n1. Log in to Redis Enterprise as an admin user.\n2. Select the Database tab.\n3. Select the Configuration subtab.\n4. Select \"Edit\".\n5. Ensure that \"Default database access\" is unchecked.", "ruleFixId": "F-54619r804879_fix", "ruleCheckSystem": "C-54665r804878_chk", "ruleCheckContent": "Redis Enterprise databases can be configured and set to deny by default posture. Access is granted when the database is configured and can be granted by admins at a later time. Verify in the database configuration that the default user is disabled. This would force non-organizational users to authenticate with a username and password similar to any organizationally defined user. \n\nIn web UI:\n1. Log in to Redis Enterprise as an admin user.\n2. Select the Database tab.\n3. Select the Configuration subtab.\n4. Confirm \"Default database access\" reads \"nopass\" and is \"Inactive\".\n\nIf default database access is active and there is no password set, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2681, "benchmarkId": 37, "groupId": "V-251231", "title": "SRG-APP-000416-DB-000380", "description": "", "ruleId": "SV-251231r962034_rule", "ruleWeight": "10.0", "ruleSeverity": "high", "ruleVersion": "RD6X-00-009700", "ruleTitle": "Redis Enterprise DBMS must use NSA-approved cryptography to protect classified information in accordance with the data owners requirements.", "ruleVulnDiscussion": "Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.\n\nIt is the responsibility of the data owner to assess the cryptography requirements in light of applicable federal laws, Executive Orders, directives, policies, regulations, and standards.\n\nNSA-approved cryptography for classified networks is hardware based. This requirement addresses the compatibility of a DBMS with the encryption devices.\n\nRedis Enterprise does not encrypt data at rest. Redis Enterprise encryption of data at rest is handled by the underlying Linux OS.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002450", "ruleFixText": "Configure the operating system to implement DoD-approved encryption by following the steps below:\n\nTo enable strict FIPS compliance, the fips=1 kernel option needs to be added to the kernel command line during system installation so key generation is done with FIPS-approved algorithms and continuous monitoring tests in place.\n\nEnable FIPS mode with the following command:\n# sudo fips-mode-setup --enable\n\nModify the kernel command line of the current kernel in the \"grub.cfg\" file by adding the following option to the GRUB_CMDLINE_LINUX key in the \"/etc/default/grub\" file and then rebuild the \"grub.cfg\" file:\nfips=1\n\nChanges to \"/etc/default/grub\" require rebuilding the \"grub.cfg\" file as follows:\n\nOn BIOS-based machines, use the following command:\n# sudo grub2-mkconfig -o /boot/grub2/grub.cfg\n\nOn UEFI-based machines, use the following command:\n# sudo grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg\n\nIf /boot or /boot/efi reside on separate partitions, the kernel parameter \"boot=\" must be added to the kernel command line. Identify a partition by running the df /boot or df /boot/efi command:\n# sudo df /boot\n\nFilesystem 1K-blocks Used Available Use% Mounted on\n/dev/sda1 495844 53780 416464 12% /boot\n\nTo ensure the \"boot=\" configuration option will work even if device naming changes occur between boots, identify the universally unique identifier (UUID) of the partition with the following command:\n# sudo blkid /dev/sda1\n/dev/sda1: UUID=\"05c000f1-a213-759e-c7a2-f11b7424c797\" TYPE=\"ext4\"\n\nFor the example above, append the following string to the kernel command line:\nboot=UUID=05c000f1-a213-759e-c7a2-f11b7424c797\n\nReboot the system for the changes to take effect.", "ruleFixId": "F-54620r804882_fix", "ruleCheckSystem": "C-54666r804881_chk", "ruleCheckContent": "Determine if the organization requires encryption. If Redis is deployed in an unclassified environment, this is not applicable.\n\nDetermine if FIPS mode is enabled with the following command:\n# sudo fipscheck\n\nusage: fipscheck [-s ] \nfips mode is on\n\nIf FIPS mode is \"on\", determine if the kernel command line is configured to use FIPS mode with the following command:\n# sudo grep fips /boot/grub2/grub.cfg\n\n/vmlinuz-3.8.0-0.40.el7.x86_64 root=/dev/mapper/rhel-root ro rd.md=0 rd.dm=0 rd.lvm.lv=rhel/swap crashkernel=auto rd.luks=0 vconsole.keymap=us rd.lvm.lv=rhel/root rhgb fips=1 quiet\n\nIf the kernel command line is configured to use FIPS mode, determine if the system is in FIPS mode with the following command:\n# sudo cat /proc/sys/crypto/fips_enabled\n1\n\nIf FIPS mode is not \"on\", the kernel command line does not have a FIPS entry, or the system has a value of \"0\" for \"fips_enabled\" in \"/proc/sys/crypto\", this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2682, "benchmarkId": 37, "groupId": "V-251232", "title": "SRG-APP-000514-DB-000381", "description": "", "ruleId": "SV-251232r961857_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-009800", "ruleTitle": "Redis Enterprise DBMS must implement NIST FIPS 140-2 or 140-3 validated cryptographic modules to provision digital signatures.", "ruleVulnDiscussion": "Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.\n\nFor detailed information, refer to NIST FIPS Publication 140-2 or Publication 140-3, Security Requirements for Cryptographic Modules. Note that the product's cryptographic modules must be validated and certified by NIST as FIPS-compliant.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002450", "ruleFixText": "Configure the operating system to implement DoD-approved encryption by following the steps below:\n\nTo enable strict FIPS compliance, the fips=1 kernel option needs to be added to the kernel command line during system installation so key generation is done with FIPS-approved algorithms and continuous monitoring tests in place.\n\nEnable FIPS mode with the following command:\n# sudo fips-mode-setup --enable\n\nModify the kernel command line of the current kernel in the \"grub.cfg\" file by adding the following option to the GRUB_CMDLINE_LINUX key in the \"/etc/default/grub\" file and then rebuild the \"grub.cfg\" file:\nfips=1\n\nChanges to \"/etc/default/grub\" require rebuilding the \"grub.cfg\" file as follows:\n\nOn BIOS-based machines, use the following command:\n# sudo grub2-mkconfig -o /boot/grub2/grub.cfg\n\nOn UEFI-based machines, use the following command:\n# sudo grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg\n\nIf /boot or /boot/efi reside on separate partitions, the kernel parameter \"boot=\" must be added to the kernel command line. Identify a partition by running the df /boot or df /boot/efi command:\n# sudo df /boot\n\nFilesystem 1K-blocks Used Available Use% Mounted on\n/dev/sda1 495844 53780 416464 12% /boot\n\nTo ensure the \"boot=\" configuration option will work even if device naming changes occur between boots, identify the universally unique identifier (UUID) of the partition with the following command:\n# sudo blkid /dev/sda1\n/dev/sda1: UUID=\"05c000f1-a213-759e-c7a2-f11b7424c797\" TYPE=\"ext4\"\n\nFor the example above, append the following string to the kernel command line:\nboot=UUID=05c000f1-a213-759e-c7a2-f11b7424c797\n\nReboot the system for the changes to take effect.", "ruleFixId": "F-54621r804885_fix", "ruleCheckSystem": "C-54667r804884_chk", "ruleCheckContent": "The DBMS relies on the underlying operating system's cryptographic modules to provision digital signatures. Verify the operating system implements DoD-approved encryption to protect the confidentiality of remote access sessions.\n\nDetermine if FIPS mode is enabled with the following command:\n# sudo fipscheck\n\nusage: fipscheck [-s ] \nfips mode is on\n\nIf FIPS mode is \"on\", determine if the kernel command line is configured to use FIPS mode with the following command:\n# sudo grep fips /boot/grub2/grub.cfg\n\n/vmlinuz-3.8.0-0.40.el7.x86_64 root=/dev/mapper/rhel-root ro rd.md=0 rd.dm=0 rd.lvm.lv=rhel/swap crashkernel=auto rd.luks=0 vconsole.keymap=us rd.lvm.lv=rhel/root rhgb fips=1 quiet\n\nIf the kernel command line is configured to use FIPS mode, determine if the system is in FIPS mode with the following command:\n# sudo cat /proc/sys/crypto/fips_enabled\n1\n\nIf FIPS mode is not \"on\", the kernel command line does not have a FIPS entry, or the system has a value of \"0\" for \"fips_enabled\" in \"/proc/sys/crypto\", this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2683, "benchmarkId": 37, "groupId": "V-251233", "title": "SRG-APP-000514-DB-000382", "description": "", "ruleId": "SV-251233r961857_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-009900", "ruleTitle": "Redis Enterprise DBMS must implement NIST FIPS 140-2 or 140-3 validated cryptographic modules to generate and validate cryptographic hashes.", "ruleVulnDiscussion": "Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.\n\nFor detailed information, refer to NIST FIPS Publication 140-2 or Publication 140-3, Security Requirements for Cryptographic Modules. Note that the product's cryptographic modules must be validated and certified by NIST as FIPS-compliant.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002450", "ruleFixText": "Configure the operating system to implement DoD-approved encryption by following the steps below:\n\nTo enable strict FIPS compliance, the fips=1 kernel option needs to be added to the kernel command line during system installation so key generation is done with FIPS-approved algorithms and continuous monitoring tests in place.\n\nEnable FIPS mode with the following command:\n# sudo fips-mode-setup --enable\n\nModify the kernel command line of the current kernel in the \"grub.cfg\" file by adding the following option to the GRUB_CMDLINE_LINUX key in the \"/etc/default/grub\" file and then rebuild the \"grub.cfg\" file:\nfips=1\n\nChanges to \"/etc/default/grub\" require rebuilding the \"grub.cfg\" file as follows:\nOn BIOS-based machines, use the following command:\n# sudo grub2-mkconfig -o /boot/grub2/grub.cfg\n\nOn UEFI-based machines, use the following command:\n# sudo grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg\n\nIf /boot or /boot/efi reside on separate partitions, the kernel parameter \"boot=\" must be added to the kernel command line. Identify a partition by running the df /boot or df /boot/efi command:\n# sudo df /boot\n\nFilesystem 1K-blocks Used Available Use% Mounted on\n/dev/sda1 495844 53780 416464 12% /boot\n\nTo ensure the \"boot=\" configuration option will work even if device naming changes occur between boots, identify the universally unique identifier (UUID) of the partition with the following command:\n# sudo blkid /dev/sda1\n/dev/sda1: UUID=\"05c000f1-a213-759e-c7a2-f11b7424c797\" TYPE=\"ext4\"\n\nFor the example above, append the following string to the kernel command line:\nboot=UUID=05c000f1-a213-759e-c7a2-f11b7424c797\n\nReboot the system for the changes to take effect.", "ruleFixId": "F-54622r804888_fix", "ruleCheckSystem": "C-54668r863368_chk", "ruleCheckContent": "The DBMS relies on the underlying operating system's file integrity tools use of cryptographic hashes for verifying file contents and directories have not been altered. These hashes must be FIPS-compliant cryptographic hashes.\n\nDetermine if FIPS mode is enabled with the following command:\n# sudo fipscheck\n\nusage: fipscheck [-s ] \nfips mode is on\n\nIf FIPS mode is \"on\", determine if the kernel command line is configured to use FIPS mode with the following command:\n# sudo grep fips /boot/grub2/grub.cfg\n\n/vmlinuz-3.8.0-0.40.el7.x86_64 root=/dev/mapper/rhel-root ro rd.md=0 rd.dm=0 rd.lvm.lv=rhel/swap crashkernel=auto rd.luks=0 vconsole.keymap=us rd.lvm.lv=rhel/root rhgb fips=1 quiet\n\nIf the kernel command line is configured to use FIPS mode, determine if the system is in FIPS mode with the following command:\n# sudo cat /proc/sys/crypto/fips_enabled\n1\n\nIf FIPS mode is not \"on\", the kernel command line does not have a FIPS entry, or the system has a value of \"0\" for \"fips_enabled\" in \"/proc/sys/crypto\", this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2684, "benchmarkId": 37, "groupId": "V-251234", "title": "SRG-APP-000514-DB-000383", "description": "", "ruleId": "SV-251234r961857_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-010000", "ruleTitle": "Redis Enterprise DBMS must implement NIST FIPS 140-2 or 140-3 validated cryptographic modules to protect unclassified information requiring confidentiality and cryptographic protection, in accordance with the data owners requirements.", "ruleVulnDiscussion": "Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. \n\nIt is the responsibility of the data owner to assess the cryptography requirements in light of applicable federal laws, Executive Orders, directives, policies, regulations, and standards.\n\nFor detailed information, refer to NIST FIPS Publication 140-2 or Publication 140-3, Security Requirements for Cryptographic Modules. Note that the product's cryptographic modules must be validated and certified by NIST as FIPS-compliant.\n\nThe DBMS relies on the underlying Linux operating system to meet this check.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002450", "ruleFixText": "To configure the operating system to implement DoD-approved encryption, review the official RHEL Documentation: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-federal_standards_and_regulations", "ruleFixId": "F-54623r804891_fix", "ruleCheckSystem": "C-54669r863370_chk", "ruleCheckContent": "Verify the operating system implements FIPS compliant cryptographic modules.\n\nAs the system administrator, run the following to determine if FIPS is enabled:\n# cat /proc/sys/crypto/fips_enabled\n\nIf fips_enabled is not 1, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2685, "benchmarkId": 37, "groupId": "V-251235", "title": "SRG-APP-000211-DB-000122", "description": "", "ruleId": "SV-251235r961095_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-010100", "ruleTitle": "Redis Enterprise DBMS must separate user functionality (including user interface services) from database management functionality.", "ruleVulnDiscussion": "Information system management functionality includes functions necessary to administer databases, network components, workstations, or servers and typically requires privileged user access. \n\nThe separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, combinations of these methods, or other methods, as appropriate. \n\nAn example of this type of separation is observed in web administrative interfaces that use separate authentication methods for users of any other information system resources. \n\nThis may include isolating the administrative interface on a different domain and with additional access controls.\n\nIf administrative functionality or information regarding DBMS management is presented on an interface available for users, information on DBMS settings may be inadvertently made available to the user.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001082", "ruleFixText": "Configure DBMS to separate database administration and general user functionality.", "ruleFixId": "F-54624r804894_fix", "ruleCheckSystem": "C-54670r804893_chk", "ruleCheckContent": "Redis Enterprise provides separate user functionality by default. An administrative control plane helps facilitate configuration and a database layer helps facilitate application integrations with the database. This functionality is provided by default; however, the same user may be used for both the database layer and the administrative control plane. \n\nFirst, obtain the list of authorized admin users and general users.\nTo check user functionality, perform the following steps:\n1. Log in to the administrative control plane.\n2. Navigate to the access controls tab.\n3. Navigate to the roles tab.\n4. Review all roles and verify that any role that provides access to the data path is configured with the cluster management role of \"None\". \n\nIf a role provides access to both data and management paths, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2686, "benchmarkId": 37, "groupId": "V-251236", "title": "SRG-APP-000211-DB-000122", "description": "", "ruleId": "SV-251236r961095_rule", "ruleWeight": "10.0", "ruleSeverity": "high", "ruleVersion": "RD6X-00-010150", "ruleTitle": "Access to the Redis Enterprise control plane must be restricted.", "ruleVulnDiscussion": "If administrative functionality or information regarding DBMS management is presented on an interface available for users, information on DBMS settings may be inadvertently made available to the user.\n\nThe Redis administrative control plane helps facilitate configuration and application integrations with the database. Exposing the control plane application to any network interface that is available to non-administrative personnel leaves the server vulnerable to attempts to access the management application. To mitigate this risk, the management application must only be run on network interfaces tied to a dedicated management network or firewall rule to limit access to dedicated trusted machines.\n\nRedis does not provide a configuration setting that can be used to restrict access to the administrative control plane, so firewall controls must be applied.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001082", "ruleFixText": "Configure a management network defined through physical or logical means to achieve network separation. Update system documentation (SSP) and identify the documented management networks as well as the documented client networks.\n\nConfigure the administrative control plane to only be accessible via the management network.\n\nAlternatively, ensure a firewall rule is enabled on the network layer and the administrative control plane is only available through trusted and approved IPs.\n\nUse firewalld (the host-based firewall service) on the server to set up a whitelist of IPs that it will accept to use the control plane and REST API ports. The default for these are 8443 and 9443. Below is an example:\nfirewall-cmd --permanent --add-rich-rule='rule family=\"ipv4\" source address=\"\" port protocol=\"tcp\" port=\"8443\" accept'\nfirewall-cmd --permanent --add-rich-rule='rule family=\"ipv4\" source address=\"\" port protocol=\"tcp\" port=\"9443\" accept'\n\nRestart the firewall to save the rule:\nsystemctl restart firewalld", "ruleFixId": "F-54625r806421_fix", "ruleCheckSystem": "C-54671r806420_chk", "ruleCheckContent": "Review system documentation (SSP) and identify the documented management networks as well as the documented client networks. A management network can be defined through physical means or logical means to achieve network separation.\n\nCheck the network interface to verify the administrative console is on a separate management network interface.\n\nIf the control plane is set up to only be accessed via a defined management network, this is not a finding.\n\nIf a management network does not exist or network separation is not established, verify the control plane can only be accessed via trusted approved machines.\n\nReview system documentation and obtain a list of approved machines for administrator use.\n\nCheck the firewall rules on the server. An example command is:\nfirewall-cmd --list-all\n\nCheck for rules showing that only the trusted and approved machines have access to the ports for the control plane (default is 8443) and REST API interface (default 9443). Below is an example of the output:\nrich rules:\nrule family=\"ipv4\" source address=\"\" forward-port port=\"8443\" protocol=\"tcp\" to-port=\"80\"\nrule family=\"ipv4\" source address=\"\" forward-port port=\"9443\" protocol=\"tcp\" to-port=\"80\"\n\nIf access is not limited using a management network, network separation such as vlans, or a firewall rule, this a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2687, "benchmarkId": 37, "groupId": "V-251237", "title": "SRG-APP-000223-DB-000168", "description": "", "ruleId": "SV-251237r961116_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-010300", "ruleTitle": "Redis Enterprise DBMS must recognize only system-generated session identifiers.", "ruleVulnDiscussion": "This requirement focuses on communications protection for the DBMS session rather than for the network packet. The intent of this control is to establish grounds for confidence at each end of a communications session in the ongoing identity of the other party and in the validity of the information being transmitted. \n\nRedis Enterprise Software (RS) uses self-signed certificates out-of-the-box to make sure that sessions are secure by default. When using the default self-signed certificates, an untrusted connection notification is shown in the web UI. Depending on the browser used, the user can allow the connection for each session or add an exception to make the site trusted in future sessions.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001664", "ruleFixText": "To configure TLS and configure only organizationally defined CA-signed certificates, refer to the following document: \nhttps://docs.redislabs.com/latest/rs/administering/cluster-operations/updating-certificates/", "ruleFixId": "F-54626r804900_fix", "ruleCheckSystem": "C-54672r804899_chk", "ruleCheckContent": "By default, each cluster node has a different set of self-signed certificates. These certificates can be replaced with a DoD-acceptable certificate, preferably a certificate issued by an intermediate certificate authority (CA).\n\nFor security reasons, Redis Enterprise only supports the TLS protocol. Therefore, verify that the Redis client or secured tunnel solution is TLS v1.2 or above.\n\nRun the following commands and verify that certificates are present:\n# cd /etc/opt/redislabs\n# ls \n\nVerify the proxy_cert.pem file is present.\n\nIf no certificates are present, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2688, "benchmarkId": 37, "groupId": "V-251238", "title": "SRG-APP-000224-DB-000384", "description": "", "ruleId": "SV-251238r961119_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-010400", "ruleTitle": "Redis Enterprise DBMS must maintain the authenticity of communications sessions by guarding against man-in-the-middle attacks that guess at Session ID values.", "ruleVulnDiscussion": "Session IDs are tokens generated by web applications to uniquely identify an application user's session. Applications will make application decisions and execute business logic based on the session ID. Unique session identifiers or IDs are the opposite of sequentially generated session IDs, which can be easily guessed by an attacker. Unique session IDs help to reduce predictability of said identifiers. Unique session IDs address man-in-the-middle attacks, including session hijacking or insertion of false information into a session. If the attackers are unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. When a user logs out, or when any other session termination event occurs, the application must terminate the user session to minimize the potential for an attacker to hijack that particular user session.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001188", "ruleFixText": "To encrypt the connection to the database endpoint with TLS, enter the contents the client certificate to the TLS field.\n\nIf configured, Redis Enterprise Software (RS) can use industry-standard encryption to protect the data in transit between a Redis client and RS. For this purpose, RS uses transport layer security (TLS) protocol, which is the more secure successor to SSL.\n\nTo enable TLS, the RS cluster nodes, the database, and client must be configured as detailed below.\n\nConfiguration of the RS nodes:\nBy default, each cluster node has a different set of self-signed certificates. These certificates can be replaced with another certificate, preferably a certificate issued by an intermediate certificate authority (CA).\n\nConfiguration of the database:\nTo encrypt the connection to the database endpoint with TLS, enter the contents the client certificate to the TLS field.\nNote: Once TLS encryption is enabled for the database endpoint, the database does not accept unsecured connections. TLS encryption can significantly impact database throughput and latency.\n\nAdding TLS CA signed certificates to the proxy:\nThe proxy is responsible for terminating the TLS connection.\nServer certificate and key are located on /etc/opt/redislabs:proxy_cert.pem - server certificate thatproxy_key.pem - server certificate key*any update on these requires a proxy restart\n\nEnabling of TLS is done via \"ssl authentication\" field in the UI. It is a requirement to add a client-side certificate as a TLS connection is done via client certificate authentication (not just server-side authentication).\n\nInstalling CA signed certificates high-level steps: \n1. Replace the RS server certificates and key on all nodes with the CA signed certificate and restart the proxy.\nNote: A certificate for the databases' endpoint should be assigned for the same domain as the cluster name. For example, for a cluster with the name \"redislabs.com\" the certificate should be for \"*.redislabs.com\".\n\n2. Add the TLS client certificates in the UI including CA certificates and any intermediate certificates by chaining the certificate into one file (use a cat command to chain the certificates).\n\n3. On the client side, import and trust the CA and intermediate certificates (chain the CA certificate with intermediate as one file to use and import).\n\nClient configuration:\nTo connect to a database configured with TLS encryption, either use one of the Redis clients that inherently support SSL encryption, or use any Redis client and create a secured tunnel between the client machine and the RS nodes.\n\nTo create a secure tunnel between the client machine and the RS nodes, use tools that enable this functionality, such as spiped or stunnel. An example of how to use stunnel is detailed below.\n\nNote: For security reasons, RS supports only the TLS protocol. Therefore, make sure the Redis client or secured tunnel solution used supports TLS, preferably TLS v1.2.\n\nWhen using self-signed certificates on the cluster nodes, make sure to copy these certificates to the client machines as well, thereby enabling the client to validate the cluster nodes.\n\nWhen using a certificate issued by an intermediate certificate authority (CA) on the cluster nodes, make sure that the CA root certificate is installed on the client machines.\n\nExample how to secure client connection with TLS using stunnel: \nThe instructions below explain how to use stunnel for setting up a secure tunnel between a client machine and the RS nodes when the client is running on Ubuntu, using the default RS nodes' self-signed certificates, and a self-signed certificate on the client machine.\n\n1. Install stunnel version 5 or higher on the client machine. Older versions of stunnel do not support the TLS protocol.\n\n2. Create a self-signed certificate on the client machine. \n\n3. Generate a private key by running the following commands:\nsudo su\nopenssl genrsa -out /etc/stunnel/keyclient.pem 4096\n\n4. Generate a client certificate by running the following commands:\nopenssl req -new -x509 -key /etc/stunnel/keyclient.pem\n-out\n/etc/stunnel/cert.pem -days 1826\n\n5. When prompted, enter the appropriate configuration details for the certificate.\n\n6. Copy the RS node certificates from all nodes to the client machine. The certificates are saved in a file named proxy_cert.pem, which is stored in /etc/opt/redislabs in each node.\n\n7. Rename the certificate files fetched from the RS nodes as certsvr.pem. For example: certsvr1.pem, certsvr2.pem.\n\n8. Create a single file for all of the server certificates on the client machine, by running the following command from the OS CLI. For example:\ncat /etc/stunnel/certsvr1.pem /etc/stunnel/certsvr2.pem > /etc/stunnel/servercerts.pem\n\n9. Configure stunnel for the connection to RS by using the steps below:\n\n10. Create a redislabs.conf file in /etc/stunnel folder.\n\n11. Make sure the certificates that have been generated exist in the following folder: /etc/stunnel.\n\n12. Edit the redislabs.conf content to look as follows: \ncert = /etc/stunnel/cert.pem key = /etc/stunnel/keyclient.pem cafile = /etc/stunnel/servercerts.pem verify = 2 delay = yes output = /tmp/stunnel.log pid = /tmp/stunnel.pid[redislabs] client = yes accept = [server IP address]:[configured port] connect = [database endpoint value]\nWhere [database endpoint value] is the database endpoint as can be retrieved from RS.\n\nNote: The value for the accept parameter is the local IP and port that is used for redirecting the traffic through the secure tunnel to the database endpoint configured in the connect parameter.\n\n13. Copy the contents of the client certificate from cert.pem and enter them in the SSL Client Authentication field, in the RS UI, of the database to be secured. When done, be sure to save the change.\n\n14. Start the stunnel service by running the following command: service stunnel restart\n\nNote: Any change made to the stunnel configuration requires restarting the stunnel service.\n\n15. Check the stunnel log file to verify that the connection is working properly. The log file is created under the root folder within the configuration mentioned above.\n\n16. Test the connection to the Redis database from the client machine. Use Redis-cli to run commands on the client machine, and the commands are redirected from the local machine's port [configured port] to the RS database endpoint. Note the connection to the Redis database is done through the local port; do not try to connect directly to the database endpoint.\n\nTLS version information: \nTo set the minimum TLS version that can be used for encrypting the data in transit between a Redis client and a Redis Enterprise cluster, use the REST API or the following rladmin command:\nrladmin> cluster config min_data_TLS_version [version, e.g., 1.2]\n\nNote that if a client supports an older TLS version, the communication is not allowed.", "ruleFixId": "F-54627r804903_fix", "ruleCheckSystem": "C-54673r863365_chk", "ruleCheckContent": "Redis Enterprise Software (RS) can use industry-standard encryption to protect data in transit between a Redis client and RS. For this purpose, RS uses transport layer security (TLS) protocol.\n\nRun the following commands and verify certificates are present:\n# cd /etc/opt/redislabs\n# ls \n\nVerify the proxy_cert.pem file is present.\n\nIf no certificates are found, this is a finding.\n\nVerify that TLS is configured to be used. To check this:\n1. Log in to the Redis Enterprise web UI as an admin user.\n2. Navigate to the Databases tab and select the database and then configuration.\n3. Review the configuration and verify that TLS is enabled for all communications.\n\nIf TLS is not configured to be used, this is a finding.\n\nTo check the current TLS version, run the following commands on one of the servers that is hosting Redis Enterprise as a privileged user:\n# ccs-cli\n# hgetall min_control_tls_version\n\nIf TLS is not FIPS compliant, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2689, "benchmarkId": 37, "groupId": "V-251239", "title": "SRG-APP-000427-DB-000385", "description": "", "ruleId": "SV-251239r961596_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-010500", "ruleTitle": "Redis Enterprise DBMS must only accept end entity certificates issued by DoD PKI or DoD-approved PKI Certification Authorities (CAs) for the establishment of all encrypted sessions.", "ruleVulnDiscussion": "Only DoD-approved external PKIs have been evaluated to ensure that they have security controls and identity vetting procedures in place which are sufficient for DoD systems to rely on the identity asserted in the certificate. PKIs lacking sufficient security controls and identity vetting procedures risk being compromised and issuing certificates that enable adversaries to impersonate legitimate users.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002470", "ruleFixText": "rladmin CLI or the REST API may be used to update the certificates.\n\nUsing the CLI: \nTo replace certificates using the rladmin CLI, run:\n rladmin cluster certificate set certificate_file .pem key_file .pem\nWhere:\ncert-name - The name of certificate to be replaced:\nFor management UI: cm\nFor REST API: api\nFor database endpoint: proxy\nFor syncer: syncer\nFor metrics exporter: metrics_exporter\ncert-file-name - The name of the certificate file\nkey-file-name - The name of the key file\n\nFor example, to replace the cm certificate with the private key \"key.pem\" and the certificate file \"cluster.pem\":\nrladmin cluster certificate set cm certificate_file cluster.pem key_file key.pem\n\nTo replace a certificate using the REST API, run:\ncurl -k -X PUT -u \":\" -H \"Content-Type: application/json\" -d '{ \"name\": \"\", \"key\": \"\", \"certificate\": \"\" }' https://:9443/v1/cluster/update_cert\nWhere:\ncert_name - The name of the certificate to replace:\nFor management UI: cm\nFor REST API: api\nFor database endpoint: proxy\nFor syncer: syncer\nFor metrics exporter: metrics_exporter\nkey - The contents of the *_key.pem file\ncert - The contents of the *_cert.pem file\n\nWhen upgrading RS, the upgrade process copies the certificates on the first upgraded node to all of the nodes in the cluster.\n\nTip: The key file contains \\n end of line characters (EOL) that cannot be pasted into the API call. Use sed -z 's/\\n/\\\\\\n/g' to escape the EOL characters.", "ruleFixId": "F-54628r804906_fix", "ruleCheckSystem": "C-54674r863372_chk", "ruleCheckContent": "Redis Enterprise Software (RS) can use industry-standard encryption to protect data in transit between a Redis client and RS. For this purpose, RS uses transport layer security (TLS) protocol.\n\nRun the following commands and verify certificates are present:\n# cd /etc/opt/redislabs\n# ls \n\nVerify that all present certificates are issued by DoD PKI or DoD-approved PKI Certification Authorities (CAs).\n\nIf non DoD-approved PKI certificates are found, this is a finding.\n\nVerify TLS is configured to be used. To check this:\n1. Log in to the Redis Enterprise web UI as an admin user.\n2. Navigate to the Databases tab and select the database and then configuration.\n3. Review the configuration and verify that TLS is enabled for all communications.\n\nIf TLS is not configured to be used, this is a finding.\n\nTo check the current TLS version, run the following commands on one of the servers that is hosting Redis Enterprise as a privileged user:\n# ccs-cli\n# hgetall min_control_tls_version\n\nIf TLS is not FIPS compliant, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2690, "benchmarkId": 37, "groupId": "V-251240", "title": "SRG-APP-000225-DB-000153", "description": "", "ruleId": "SV-251240r961122_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-010600", "ruleTitle": "Redis Enterprise DBMS must fail to a secure state if system initialization fails, shutdown fails, or aborts fail.", "ruleVulnDiscussion": "Failure to a known state can address safety or security in accordance with the mission/business needs of the organization. \n\nDatabases must fail to a known consistent state. Transactions must be successfully completed or rolled back.\n\nAll data is stored and managed exclusively in either RAM or RAM + Flash Memory (Redis on Flash) and therefore, is at risk of being lost upon a process or server failure. As Redis Enterprise Software is not just a caching solution, but also a full-fledged database, persistence to disk is critical. Therefore, Redis Enterprise Software supports persisting data to disk on a per-database basis.\n\nAppend Only File (AOF) is a continuous writing of data to disk Snapshot. It is not a replacement for backups but should be done in addition to backups. \n\nAOF writes the latest \"write\" commands into a file either every second or during every write. It resembles a traditional RDBMS's redo log. This file can later be replayed to recover from a crash.\n\nTo ensure data availability, Redis Enterprise Software must be implemented in, at a minimum, a three-node cluster. A three-node cluster can withstand one node failure without data loss. If more than one node is lost in a three-node cluster and persistence is not enabled, then data loss is to be expected.\n\nThe Append Only File is a persistence mode that provides much better durability. For instance, using the default data fsync policy, Redis can lose just one second of writes in a dramatic event like a server power outage, or a single write if something goes wrong with the Redis process itself, but the operating system is still running correctly. AOF and RDB persistence can be enabled at the same time without problems. If the AOF is enabled on startup Redis will load the AOF, that is the file with the better durability guarantees. Check http://redis.io/topics/persistence for more information.\n\nRedis Labs additionally recommends using the wait command. Review the wait command at: https://redis.io/commands/wait and determine if this meets organizational needs.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001190", "ruleFixText": "To enable persistence and replication in the Redis Enterprise UI, click the databases tab. For each database that requires reconfiguration, click it and select configuration. Ensure that the replication box is checked as well as the desired persistence level.\n\nEdit the parameters necessary to meet the desired organizational needs.", "ruleFixId": "F-54629r804909_fix", "ruleCheckSystem": "C-54675r804908_chk", "ruleCheckContent": "1. In the console UI, click the databases tab.\n2. For each listed database, click it and select configuration.\n3. Verify that \"Persistence\" is set to: \"Append Only File (AOF) - fsync every write\".\n\nIf the setting is not configured or not documented to be set differently, this is a finding.\n\n4. For each listed database, click it and select configuration.\n5. Verify \"Replication\" is set enabled.\n\nIf the setting is not configured or not documented to be set differently, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2691, "benchmarkId": 37, "groupId": "V-251241", "title": "SRG-APP-000226-DB-000147", "description": "", "ruleId": "SV-251241r961125_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-010700", "ruleTitle": "In the event of a system failure, Redis Enterprise DBMS must preserve any information necessary to determine cause of failure and any information necessary to return to operations with least disruption to mission processes.", "ruleVulnDiscussion": "Failure to a known state can address safety or security in accordance with the mission/business needs of the organization.\n\nFailure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system.\n\nPreserving information system state information helps to facilitate system restart and return to the operational mode of the organization with less disruption of mission/business processes.\n\nSince it is usually not possible to test this capability in a production environment, systems should either be validated in a testing environment or prior to installation. This requirement is usually a function of the design of the IDPS component. Compliance can be verified by acceptance/validation processes or vendor attestation.\n\nAdditional information can be found at:\nhttps://docs.redislabs.com/latest/rs/administering/troubleshooting/cluster-recovery/", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001665", "ruleFixText": "In the Redis Enterprise web UI, select databases and then select the individual databases.\n\nFor each database, select configuration.\n\nCheck the box and configure the following as defined by the ISSO/ISSM: \"Persistence\", \"Periodic backup\", and \"Alerts\" \n\nEnsure that organizationally defined path for the centralized log server is also applied and configured external to the database.", "ruleFixId": "F-54630r804912_fix", "ruleCheckSystem": "C-54676r804911_chk", "ruleCheckContent": "In the Redis Enterprise web UI, select settings and then alerts.\n\nVerify the alerts documented by the ISSO/ISSM are checked.\n\nIf required alerts are not checked, this is a finding.\n\nIn the Redis Enterprise web UI, select databases, then select the individual databases.\n\nFor each database, select configuration.\n\nVerify that \"Persistence\", \"Periodic backup\", and \"Alerts\" are all configured as organizationally defined and documented by the ISSO or ISSM. \n\nVerify that organizationally defined path for the centralized log server is also applied and configured external to the database.\n\nIf any of these items are not configured as documented, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2692, "benchmarkId": 37, "groupId": "V-251242", "title": "SRG-APP-000231-DB-000154", "description": "", "ruleId": "SV-251242r961128_rule", "ruleWeight": "10.0", "ruleSeverity": "high", "ruleVersion": "RD6X-00-010800", "ruleTitle": "Redis Enterprise DBMS must protect the confidentiality and integrity of all information at rest.", "ruleVulnDiscussion": "This control is intended to address the confidentiality and integrity of information at rest in non-mobile devices and covers user information and system information. Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive, tape drive) within an organizational information system. Applications and application users generate information throughout the course of their application use. \n\nUser data generated, as well as application-specific configuration data, needs to be protected. Organizations may choose to employ different mechanisms to achieve confidentiality and integrity protections, as appropriate. \n\nIf the confidentiality and integrity of application data is not protected, the data will be open to compromise and unauthorized modification.\n\nRedis Enterprise does not inherently encrypt data at rest and is designed to have the OS handle encryption for data at rest.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001199", "ruleFixText": "Red Hat Enterprise Linux natively supports partition encryption through the Linux Unified Key Setup-on-disk-format (LUKS) technology. The easiest way to encrypt a partition is during installation time.\n\nFor manual installations, select the \"Encrypt\" checkbox during partition creation to encrypt the partition. When this option is selected the system will prompt for a passphrase to use in decrypting the partition. The passphrase will subsequently need to be entered manually every time the system boots.\n\nFor automated/unattended installations, it is possible to use Kickstart by adding the \"--encrypted\" and \"--passphrase=\" options to the definition of each partition to be encrypted. For example, the following line would encrypt the root partition:\npart / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=[PASSPHRASE]\n\nAny [PASSPHRASE] is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly. Omitting the \"--passphrase=\" option from the partition definition will cause the installer to pause and interactively ask for the passphrase during installation.\n\nDetailed information on encrypting partitions using LUKS can be found on the Red Hat Documentation website: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-encryption", "ruleFixId": "F-54631r804915_fix", "ruleCheckSystem": "C-54677r804914_chk", "ruleCheckContent": "If the application owner and Authorizing Official have determined that encryption of data at rest is NOT required, this is not a finding.\n\nVerify the operating system implements encryption to protect the confidentiality and integrity of information at rest.\n\nIf a disk or filesystem requires encryption, ask the system owner, DBA, and SA to demonstrate the use of filesystem and/or disk-level encryption. If this is required and is not found, this is a finding.\n\nTo check if full disk encryption is enabled, log in to RHEL as an admin user and run the following commands:\n# lsblk\n\nIdentify the partition that Redis Enterprise is located on.\n# blkid /dev/[name of partition]\n\nIf the output shows TYPE=\"crypto_LUKS\" then the partition is encrypted.\n\nIf encryption must be used and is not employed, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2695, "benchmarkId": 37, "groupId": "V-251245", "title": "SRG-APP-000243-DB-000128", "description": "", "ruleId": "SV-251245r961149_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-011300", "ruleTitle": "Database contents must be protected from unauthorized and unintended information transfer by enforcement of a data-transfer policy.", "ruleVulnDiscussion": "Security functions are the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001090", "ruleFixText": "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.", "ruleFixId": "F-54634r804924_fix", "ruleCheckSystem": "C-54680r804923_chk", "ruleCheckContent": "Review the procedures for the refreshing of development/test data from production.\n\nReview 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.\n\nVerify that copies of production data are not left in unprotected locations. \n\nIf 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.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2696, "benchmarkId": 37, "groupId": "V-251246", "title": "SRG-APP-000243-DB-000373", "description": "", "ruleId": "SV-251246r961149_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-011400", "ruleTitle": "Redis Enterprise DBMS must prevent unauthorized and unintended information transfer via shared system resources.", "ruleVulnDiscussion": "The purpose of this control is to prevent information, including encrypted representations of information, produced by the actions of a prior user/role (or the actions of a process acting on behalf of a prior user/role) from being available to any current user/role (or current process) that obtains access to a shared system resource (e.g., registers, main memory, secondary storage) after the resource has been released back to the information system. Control of information in shared resources is also referred to as object reuse.\n\nFor more information, refer to:\nhttps://redis.io/topics/acl more information on creating clearly defined categories and adding/editing users to categories and ACLs.\nand\nhttps://docs.redislabs.com/latest/rs/administering/access-control/user-roles/", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001090", "ruleFixText": "Users and ACLs can be created and modified from the Redis Enterprise UI by navigating to the access control tab as an admin user. Update the user roles and ACLs to reflect organizational requirements.", "ruleFixId": "F-54635r804927_fix", "ruleCheckSystem": "C-54681r804926_chk", "ruleCheckContent": "Verify all returned users with security permissions are documented as requiring the permissions.\n\nIn the web UI, select access control >> Redis acls.\n\nVerify that the documented users have the correct ACL(s) assigned to them by clicking the \"Used By\" link for each listed ACL.\n\nVerify that all documented ACLs match each of the listed ACLs.\n\nIf \"Redis ACL name\" and \"Used By\" do not match the documentation, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2697, "benchmarkId": 37, "groupId": "V-251247", "title": "SRG-APP-000243-DB-000374", "description": "", "ruleId": "SV-251247r961149_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-011500", "ruleTitle": "Access to database files must be limited to relevant processes and to authorized, administrative users.", "ruleVulnDiscussion": "Developers and implementers can increase the assurance in security functions by employing well-defined security policy models; structured, disciplined, and rigorous hardware and software development techniques; and sound system/security engineering principles.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001090", "ruleFixText": "Configure the operating system to define default permissions for all authenticated users in such a way that the user can only read and modify their own files.\n\nAdd or edit the line for the \"UMASK\" parameter in \"/etc/login.defs\" file to \"077\":\n\nUMASK 077\n\nSet the permissions of the log files (/var/opt/redislabs/log) and persisted files (/var/opt/redislabs/persist/redis/) to an appropriate organizationally defined setting.", "ruleFixId": "F-54636r804930_fix", "ruleCheckSystem": "C-54682r804929_chk", "ruleCheckContent": "Review the permissions granted to users by the operating system/file system on the database files, database log files, and database backup files. \n\nIf any user/role who is not an authorized system administrator with a need to know or database administrator with a need to know, or a system account for running DBMS processes, is permitted to read/view any of these files, this is a finding.\n\nReview the directory contents and files and verify that the appropriate file permissions are set. Verify that the file owner and group is set to Redis Labs or a group defined per site requirements.\n\nTo check permissions of log files (Note: This may vary depending on the installation path.):\n# /var/opt/redislabs/log\n\nTo check persisted files from memory if they are being used run the following command (Note: This may vary depending on the installation path.)\n# ls -ltr /var/opt/redislabs/persist/redis/ \n\nTo check the default file permissions to verify that all authenticated users can only read and modify their own files:\n# cat/etc/login.defs|grep UMASK\n\nVerify the value is set to 077 or an appropriate organizationally defined setting.\n\nInvestigate the permissions on these files. If the permissions allow access by other, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2698, "benchmarkId": 37, "groupId": "V-251248", "title": "SRG-APP-000441-DB-000378", "description": "", "ruleId": "SV-251248r961638_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-011600", "ruleTitle": "Redis Enterprise DBMS must maintain the confidentiality and integrity of information during preparation for transmission.", "ruleVulnDiscussion": "Information can be either unintentionally or maliciously disclosed or modified during preparation for transmission, including, for example, during aggregation, at protocol transformation points, and during packing/unpacking. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information.\n\nUse of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process.\n\nWhen transmitting data, the DBMS, associated applications, and infrastructure must leverage transmission protection mechanisms.\n\nFor more detailed information, refer to:\nhttps://docs.redislabs.com/latest/rs/administering/designing-production/security/", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002420", "ruleFixText": "To configure TLS and configure only organizationally defined CA-signed certificates, refer to the following document: \nhttps://docs.redislabs.com/latest/rs/administering/cluster-operations/updating-certificates/", "ruleFixId": "F-54637r804933_fix", "ruleCheckSystem": "C-54683r863374_chk", "ruleCheckContent": "Redis has optional support for TLS on all communication channels, including client connections, replication links, and the Redis Cluster bus protocol.\n\nBy default, each cluster node has a different set of self-signed certificates. These certificates can be replaced with a DoD-acceptable certificate, preferably a certificate issued by an intermediate certificate authority (CA).\n\nFor security reasons, Redis Enterprise only supports only the TLS protocol. Therefore, verify that the Redis client or secured tunnel solution is TLS v1.2 or above.\n\nFirst, verify that the host operating system is encrypted. \n\nIf the host operating system is not encrypted, this is a finding.\n\nIf the host operating system is encrypted, run the following commands and verify that only DoD-approved PKI certificates are present:\n# cd /etc/opt/redislabs\n# ls \n\nVerify the proxy_cert.pem file is present.\n\nIf no certificates are found, this is a finding.\n\nVerify that TLS is configured to be used. To check this:\n1. Log in to the Redis Enterprise web UI as an admin user.\n2. Navigate to the Databases tab and select the database and then configuration.\n3. Review the configuration and verify that TLS is enabled for all communications.\n\nIf TLS is not configured to be used, this is a finding.\n\nTo check the current TLS version, run the following commands on one of the servers that is hosting Redis Enterprise as a privileged user:\n# ccs-cli\n# hgetall min_control_tls_version\n\nIf TLS is not FIPS compliant, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2699, "benchmarkId": 37, "groupId": "V-251249", "title": "SRG-APP-000442-DB-000379", "description": "", "ruleId": "SV-251249r961641_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-011700", "ruleTitle": "Redis Enterprise DBMS must maintain the confidentiality and integrity of information during reception.", "ruleVulnDiscussion": "Information can be either unintentionally or maliciously disclosed or modified during reception, including, for example, during aggregation, at protocol transformation points, and during packing/unpacking. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information.\n\nThis requirement applies only to those applications that are either distributed or can allow access to data nonlocally. Use of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. \n\nWhen receiving data, the DBMS, associated applications, and infrastructure must leverage protection mechanisms.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002422", "ruleFixText": "To encrypt the connection to the database endpoint with TLS, enter the contents the client certificate to the TLS field.\n\nIf configured, Redis Enterprise Software (RS) can use industry-standard encryption to protect the data in transit between a Redis client and RS. For this purpose, RS uses transport layer security (TLS) protocol, which is the more secure successor to SSL.\n\nTo enable TLS, the RS cluster nodes, the database, and client must be configured as detailed below.\n\nConfiguration of the RS nodes:\nBy default, each cluster node has a different set of self-signed certificates. These certificates can be replaced with another certificate, preferably a certificate issued by an intermediate certificate authority (CA).\n\nConfiguration of the database:\nTo encrypt the connection to the database endpoint with TLS, enter the contents the client certificate to the TLS field.\nNote: Once TLS encryption is enabled for the database endpoint, the database does not accept unsecured connections. TLS encryption can significantly impact database throughput and latency.\n\nAdding TLS CA signed certificates to the proxy:\nThe proxy is responsible for terminating the TLS connection.\nServer certificate and key are located on /etc/opt/redislabs:proxy_cert.pem - server certificate thatproxy_key.pem - server certificate key*any update on these requires a proxy restart\n\nEnabling of TLS is done via the \"ssl authentication\" field in the UI. It is a requirement to add a client-side certificate as a TLS connection via client certificate authentication (not just server-side authentication).\n\nInstalling CA signed certificates:\nReplace the RS server certificates and key on all nodes with the CA signed certificate and restart the proxy.\nNote: A certificate for the databases' endpoint should be assigned for the same domain as the cluster name. For example, for a cluster with the name \"redislabs.com\" the certificate should be for \"*.redislabs.com\".\n\nAdd the TLS client certificates in the UI including CA certificates and any intermediate certificates by chaining the certificate into one file (use a cat command to chain the certificates).\nOn the client side make sure to import and trust the CA and intermediate certificates (chain the CA certificate with intermediate as one file to use and import).\n\nClient configuration:\nTo connect to a database configured with TLS encryption, either use one of the Redis clients that inherently support SSL encryption, or use any Redis client and create a secured tunnel between the client machine and the RS nodes.\n\nTo create a secure tunnel between the client machine and the RS nodes, use tools that enable this functionality, such as spiped or stunnel. An example of how to use stunnel is detailed below.\nNote: For security reasons, RS supports only the TLS protocol. Therefore, make sure that the Redis client or secured tunnel solution used supports TLS, preferably TLS v1.2.\n\nWhen using self-signed certificates on the cluster nodes, make sure to copy these certificates to the client machines as well, thereby enabling the client to validate the cluster nodes.\n\nWhen using a certificate issued by an intermediate certificate authority (CA) on the cluster nodes, make sure that the CA root certificate is installed on the client machines.\n\nExample of how to secure client connection with TLS using stunnel: \nThe instructions below explain how to use stunnel for setting up a secure tunnel between a client machine and the RS nodes when the client is running on Ubuntu, using the default RS nodes' self-signed certificates, and a self-signed certificate on the client machine.\n\n1. Install stunnel version 5 or higher on the client machine. Older versions of stunnel do not support the TLS protocol.\n\n2. Create a self-signed certificate on the client machine:\n\n3. Generate a private key by running the following commands:\nsudo su\nopenssl genrsa -out /etc/stunnel/keyclient.pem 4096\n\n4. Generate a client certificate by running the following commands:\nopenssl req -new -x509 -key /etc/stunnel/keyclient.pem\n-out\n/etc/stunnel/cert.pem -days 1826\n\n5. When prompted, enter the appropriate configuration details for the certificate.\n\n6. Copy the RS node certificates from all nodes to the client machine. The certificates are saved in a file named proxy_cert.pem, which is stored in /etc/opt/redislabs in each node.\n\n7. Rename the certificate files fetched from the RS nodes as certsvr.pem. For example: certsvr1.pem, certsvr2.pem.\n\n8. Create a single file for all of the server certificates on the client machine by running the following command from the OS CLI. For example: cat /etc/stunnel/certsvr1.pem /etc/stunnel/certsvr2.pem > /etc/stunnel/servercerts.pem\n\n9. Configure stunnel for the connection to RS by using the steps below:\n\n10. Create a redislabs.conf file in /etc/stunnel folder.\n\n11. Make sure that the certificates that have been generated exist in the following folder: /etc/stunnel.\n\n12. Edit the redislabs.conf content to look as follows:cert = /etc/stunnel/cert.pem key = /etc/stunnel/keyclient.pem cafile = /etc/stunnel/servercerts.pem verify = 2 delay = yes output = /tmp/stunnel.log pid = /tmp/stunnel.pid[redislabs] client = yes accept = [server IP address]:[configured port] connect = [database endpoint value] Where [database endpoint value] is the database endpoint as can be retrieved from RS.\n\nNote: The value for the accept parameter is the local IP and port that is used for redirecting the traffic through the secure tunnel to the database endpoint configured in the connect parameter.\n\n13. Copy the contents of the client certificate from cert.pem and enter them in the SSL Client Authentication field, in the RS UI, of the database to be secured. When done, be sure to save the change.\n\n14. Start the stunnel service by running the following command: service stunnel restart\n\nNote: Any change made to the stunnel configuration requires restarting the stunnel service.\n\n15. Check the stunnel log file to verify that the connection is working properly. The log file is created under the root folder within the configuration mentioned above.\n\n16. Test the connection to the Redis database from the client machine. Use redis-cli to run commands on the client machine, and the commands are redirected from the local machine's port [configured port] to the RS database endpoint. Note that the connection to the Redis database is done through the local port; do not try to connect directly to the database endpoint.\n\nTLS version information:\nTo set the minimum TLS version that can be used for encrypting the data in transit between a Redis client and a Redis Enterprise cluster, use the REST API or the following rladmin command:\nrladmin> cluster config min_data_TLS_version [version, e.g., 1.2]\n\nNote that if a client supports an older TLS version, the communication is not be allowed.", "ruleFixId": "F-54638r804936_fix", "ruleCheckSystem": "C-54684r863376_chk", "ruleCheckContent": "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.\n\nIf Redis Enterprise DBMS, associated applications, and infrastructure do not employ protective measures against unauthorized disclosure and modification during reception, this is a finding.\n\nRedis Enterprise Software (RS) can use industry-standard encryption to protect data in transit between a Redis client and RS. For this purpose, RS uses transport layer security (TLS) protocol.\n\nRun the following commands and verify certificates are present:\n# cd /etc/opt/redislabs\n# ls \n\nVerify the proxy_cert.pem file is present.\n\nIf no certificates are found, this is a finding.\n\nVerify that TLS is configured to be used. To check this:\n1. Log in to the Redis Enterprise web UI as an admin user.\n2. Navigate to the Databases tab and select the database and then configuration.\n3. Review the configuration and verify that TLS is enabled for all communications.\n\nIf TLS is not configured to be used, this is a finding.\n\nTo check the current TLS version, run the following commands on one of the servers that is hosting Redis Enterprise as a privileged user:\n# ccs-cli\n# hgetall min_control_tls_version\n\nIf TLS is not FIPS compliant, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2700, "benchmarkId": 37, "groupId": "V-251250", "title": "SRG-APP-000251-DB-000391", "description": "", "ruleId": "SV-251250r961158_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-011900", "ruleTitle": "Redis Enterprise DBMS and associated applications must reserve the use of dynamic code execution for situations that require it.", "ruleVulnDiscussion": "With respect to database management systems, one class of threat is known as code injection. It takes advantage of the dynamic execution capabilities of various programming languages, including dialects of LUA and SQL. In such cases, the attacker deduces the manner in which code is processed, either from inside knowledge or by observing system behavior in response to invalid inputs. When the attacker identifies scenarios where code is executed dynamically, the attacker is then able to craft input strings that subvert it. Potentially, the attacker can gain unauthorized access to data, including security settings, and severely corrupt or destroy the database.\n\nThe principal protection against code injection is not to use dynamic execution except where it provides necessary functionality that cannot be used otherwise. Use strongly typed data items rather than general-purpose strings as input parameters to task-specific, pre-compiled stored procedures and functions (and triggers).\n\nBecause Redis does not rely on a query language, there is no known method of SQL injection that would apply to Redis. Redis is a key value store and relies on commands that do not have a unified query language. Redis does have an embedded LUA interpreter and the user will need to disable these.\n\nWhen dynamic execution is necessary, ways to mitigate the risk include the following, which should be implemented both in the on-screen application and at the database level, in the stored procedures:\n- Allow strings as input only when necessary. \n- Rely on data typing to validate numbers, dates, etc. Do not accept invalid values. If substituting other values for them, think carefully about whether this could be subverted.\n- Limit the size of input strings to what is truly necessary.\n- If single quotes/apostrophes, double quotes, semicolons, equals signs, angle brackets, or square brackets will never be valid as input, reject them.\n- If comment markers will never be valid as input, reject them. \n- If HTML and XML tags, entities, comments, etc., will never be valid, reject them.\n- If wildcards are present, reject them unless truly necessary. \n- If there are range limits on the values that may be entered, enforce those limits.\n- Institute procedures for inspection of programs for correct use of dynamic coding by a party other than the developer.\n- Conduct rigorous testing of program modules that use dynamic coding, searching for ways to subvert the intended use.\n- Record the inspection and testing in the system documentation.\n- Bear in mind that all this applies not only to screen input, but also to the values in an incoming message to a web service or to a stored procedure called by a software component that has not itself been hardened in these ways. Not only can the caller be subject to such vulnerabilities, but it may also itself be the attacker.\n\nThis calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers, and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001310", "ruleFixText": "Redis does not rely on a query language and there is no known method of SQL injection that would apply to Redis. Redis is a key value store and relies on commands that do not have a unified query language. Redis has an embedded LUA interpreter that is recommended to disable.\n\nTo disable the interpreter run the following REST API command:\ncurl -v -kL -u \":\" --location-trusted -H \"Content-type: application/json\" -d '{ \"disabled_commands\": \"EVAL, EVALSHA\" }' -X PUT https://:PORT/v1/bdbs/", "ruleFixId": "F-54639r804939_fix", "ruleCheckSystem": "C-54685r804938_chk", "ruleCheckContent": "Redis does not rely on a query language and there is no known method of SQL injection that would apply to Redis. Redis is a key value store and relies on commands that do not have a unified query language. Redis has an embedded LUA interpreter that is recommended to disable.\n\nInterview the system administrator and ask if the practice of disabling LUA scripting is a documented practice or has been completed. To check if LUA scripting is disabled on the desired database:\n1. Connect to one of the nodes/servers in the redis enterprise cluster as an admin (sudo su -).\n2. Type: rladmin status to get the DB ID of the database on which LUA scripting is to be disabled\n3. Run the following command, substituting in the bdb_id from the previous step: \nccs-cli hget bdb: \n\nIf the response is NIL or doesn't return EVAL, EVALSHA, this is a finding.\n\nIf no documentation exists or if the database otherwise accepts LUA scripts, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2701, "benchmarkId": 37, "groupId": "V-251251", "title": "SRG-APP-000251-DB-000392", "description": "", "ruleId": "SV-251251r961158_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-012000", "ruleTitle": "Redis Enterprise DBMS and associated applications, when making use of dynamic code execution, must scan input data for invalid values that may indicate a code injection attack.", "ruleVulnDiscussion": "With respect to database management systems, one class of threat is known as code injection. It takes advantage of the dynamic execution capabilities of various programming languages, including dialects of LUA and SQL. In such cases, the attacker deduces the manner in which code is processed, either from inside knowledge or by observing system behavior in response to invalid inputs. When the attacker identifies scenarios where code is executed dynamically, the attacker is then able to craft input strings that subvert it. Potentially, the attacker can gain unauthorized access to data, including security settings, and severely corrupt or destroy the database.\n\nThe principal protection against code injection is not to use dynamic execution except where it provides necessary functionality that cannot be used otherwise. Use strongly typed data items rather than general-purpose strings as input parameters to task-specific, pre-compiled stored procedures and functions (and triggers).\n\nBecause Redis does not rely on a query language there is no known method of SQL injection that would apply to Redis. Redis is a key value store and relies on commands that do not have a unified query language. Redis does have an embedded LUA interpreter and the user will need to disable these.\n\nWhen dynamic execution is necessary, ways to mitigate the risk include the following, which should be implemented both in the on-screen application and at the database level, in the stored procedures:\n- Allow strings as input only when necessary. \n- Rely on data typing to validate numbers, dates, etc. Do not accept invalid values. If substituting other values for them, think carefully about whether this could be subverted.\n- Limit the size of input strings to what is truly necessary.\n- If single quotes/apostrophes, double quotes, semicolons, equals signs, angle brackets, or square brackets will never be valid as input, reject them.\n- If comment markers will never be valid as input, reject them. \n- If HTML and XML tags, entities, comments, etc., will never be valid, reject them.\n- If wildcards are present, reject them unless truly necessary. \n- If there are range limits on the values that may be entered, enforce those limits.\n- Institute procedures for inspection of programs for correct use of dynamic coding, by a party other than the developer.\n- Conduct rigorous testing of program modules that use dynamic coding, searching for ways to subvert the intended use.\n- Record the inspection and testing in the system documentation.\n- Bear in mind that all this applies not only to screen input, but also to the values in an incoming message to a web service or to a stored procedure called by a software component that has not itself been hardened in these ways. Not only can the caller be subject to such vulnerabilities; it may itself be the attacker.\n\nThis calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers, and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-001310", "ruleFixText": "Redis does not rely on a query language and there is no known method of SQL injection that would apply to Redis. Redis is a key value store and relies on commands that do not have a unified query language. Redis has an embedded LUA interpreter that is recommended to disable.\n\nTo disable the interpreter run the following REST API command:\ncurl -v -kL -u \":\" --location-trusted -H \"Content-type: application/json\" -d '{ \"disabled_commands\": \"EVAL, EVALSHA\" }' -X PUT https://:PORT/v1/bdbs/", "ruleFixId": "F-54640r804942_fix", "ruleCheckSystem": "C-54686r804941_chk", "ruleCheckContent": "Redis does not rely on a query language and there is no known method of SQL injection that would apply to Redis. Redis is a key value store and relies on commands that do not have a unified query language. Redis has an embedded LUA interpreter that is recommended to disable.\n\nInterview the system administrator and ask if the practice of disabling LUA scripting is a documented practice or has been completed. To check if LUA scripting is disabled on the desired database:\n1. Connect to one of the nodes/servers in the redis enterprise cluster as an admin (sudo su -).\n2. Type: rladmin status to get the DB ID of the database on which LUA scripting is to be disabled.\n3. Run the following command, substituting in the bdb_id from the previous step: \nccs-cli hget bdb: \n\nIf the response is NIL or doesn't return EVAL, EVALSHA, this is a finding\n\nIf no documentation exists or if the database otherwise accepts LUA scripts, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2702, "benchmarkId": 37, "groupId": "V-251252", "title": "SRG-APP-000454-DB-000389", "description": "", "ruleId": "SV-251252r961677_rule", "ruleWeight": "10.0", "ruleSeverity": "low", "ruleVersion": "RD6X-00-012400", "ruleTitle": "When updates are applied to Redis Enterprise DBMS software, any software components that have been replaced or made unnecessary must be removed.", "ruleVulnDiscussion": "Previous versions of DBMS components that are not removed from the information system after updates have been installed may be exploited by adversaries. \n\nSome DBMSs' installation tools may remove older versions of software automatically from the information system. In other cases, manual review and removal will be required. In planning installations and upgrades, organizations must include steps (automated, manual, or both) to identify and remove the outdated modules.\n\nA transition period may be necessary when both the old and the new software are required. This should be considered in the planning.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002617", "ruleFixText": "When a new update is available and installed, all old install files must be removed from the locations below:\n/opt/redislabs - Main Installation directory for all Redis Enterprise Software binaries\n/opt/redislabs/config - System configuration files\n/opt/redislabs/lib - System library files\n/var/opt/redislabs - Default storage location for the cluster data, system logs, backups and ephemeral, persisted data\n/tmp - Temporary files\n\nThe GREP command can be used to search for old Redis files in the above locations.\n\nIf software from a previous/outdated version of Redis Enterprise remains in any of the following locations/directories, run the following to remove it: \nrm -r ", "ruleFixId": "F-54641r804945_fix", "ruleCheckSystem": "C-54687r804944_chk", "ruleCheckContent": "When the Redis software is upgraded to a new version, the old version install file remains on the server. The users must remove this manually. To verify if the old install files have been deleted, check the locations below:\n/opt/redislabs - Main Installation directory for all Redis Enterprise Software binaries\n/opt/redislabs/config - System configuration files\n/opt/redislabs/lib - System library files\n/var/opt/redislabs - Default storage location for the cluster data, system logs, backups and ephemeral, persisted data\n/tmp - Temporary files\n\nThe GREP command can be used to search for old Redis files in the above locations. \n\nIf software components that have been replaced or made unnecessary are not removed, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2703, "benchmarkId": 37, "groupId": "V-251253", "title": "SRG-APP-000456-DB-000390", "description": "", "ruleId": "SV-251253r1001008_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-012500", "ruleTitle": "Security-relevant software updates to Redis Enterprise DBMS must be installed within the time period directed by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs).", "ruleVulnDiscussion": "Security flaws with software applications, including database management systems, are discovered daily. Vendors are constantly updating and patching their products to address newly discovered security vulnerabilities. Organizations (including any contractor to the organization) are required to promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling must also be addressed expeditiously. \n\nOrganization-defined time periods for updating security-relevant software may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). \n\nThis requirement will apply to software patch management solutions that are used to install patches across the enclave and also to applications themselves that are not part of that patch management solution. For example, many browsers today provide the capability to install their own patch software. Patch criticality, as well as system criticality, will vary. Therefore, the tactical situations regarding the patch management process will also vary. This means that the time period used must be a configurable parameter. Time frames for application of security-relevant software updates may be dependent upon the Information Assurance Vulnerability Management (IAVM) process.\n\nThe application will be configured to check for and install security-relevant software updates within an identified time period from the availability of the update. The specific time period will be defined by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs).\n\nFor more information, refer to:\nhttps://docs.redislabs.com/latest/rs/installing-upgrading/upgrading/", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-002605", "ruleFixText": "To update to the current version of the software, perform the following steps listed from the Redis Labs Enterprise site. To upgrade the Redis Enterprise Software (RS) software on a cluster, upgrade each of the nodes and then upgrade each of the databases in the cluster.\n\n- To upgrade the cluster to v6.0, the cluster must first be on 5.4.0 or above and the databases must be running Redis 5.\n- To upgrade the cluster to v5.6, the cluster must first be on 5.0.2-30 or above.\n- To upgrade the cluster to v5.4, the cluster must first be on 5.0 or above.\n- To upgrade the cluster to v5.2, the cluster must first be on 4.5 or above.\n\nThe upgrade process for a Redis Enterprise Software cluster is \"ongoing\" when the nodes in the cluster have mixed versions. The upgrade is only considered complete when all of the nodes are upgraded to the new version.\n\nWARNING Using features from the newer version before all nodes are upgraded can produce unexpected results or cause failures in the cluster.\n\nUpgrading a node: \nUpgrading the software on a node requires installing the RS installation package on all of the machines on which RS is installed.\n\nWARNING: The master node must be upgraded before upgrading the other nodes. It is recommended to keep all nodes up until the upgrade is completed on all nodes. The node role is shown in the output of the rladmin status nodes command. The installation path and user cannot be changed during upgrade. Node upgrade fails if the SSL certificates were configured in version 5.0.2 or above by manually updating the certificates on the disk instead of updating them through the API. For assistance with this issue, contact Support.\n\nRun install.sh from the directory where the media was untarred just like what is done for a new installation. The software recognizes this is an upgrade and proceeds accordingly.\n\nAs with a new installation, user must sudo or be root to do the upgrade.\n\nTo upgrade a node, run:\nsudo ./install.sh\n\nThe node upgrade process restarts the services running RS, which causes a short interruption to connections to the proxy, node, and databases.\n\nWARNING: To ensure cluster and databases' availability, it is important to upgrade the nodes one by one, and not attempt to upgrade more than one node at a time. To make sure that the node is functioning properly, run rlcheck and rladmin status extra all on the node both before and after the upgrade.\n\nIf the RS management UI is open in the browser while upgrading the nodes, make sure to refresh the browser before trying to work with the UI again.\n\nUpgrading a database \nSome RS upgrades add support for new Redis versions. In these cases, Redis Labs recommends upgrading the databases to the new Redis version, although this is not mandatory because RS upgrades are backward compatible. RS also supports a mix of Redis database versions.\n\nRS always supports two Redis versions. By default, new Redis databases are created with the latest version, and existing databases get upgraded to the latest version according to the instructions detailed below. If there is a desire to change the default Redis version to the previous version supported, it is recommended to use the tune cluster default_redis_version command in the rladmin CLI and set it to the previous Redis version supported.\n\nTo determine whether the Redis database versions match the latest Redis version supported by RS:\nIn the rladmin CLI, run the status command. If the Redis version is not the latest supported, an indication appears in the command output next to the database's status.\n\nIn the Management UI, Navigate to the Cluster >> Configuration page. The page lists the latest Redis version supported.\n\nIf the Redis database versions are older than the version supported by RS, Redis Labs recommends upgrading the Redis databases.\n\nTo upgrade the database:\n- Ensure that all of the nodes in the RS cluster are upgraded. Databases cannot be upgraded before all of the nodes in the cluster are upgraded.\n- In the rladmin CLI on any node in the cluster, run this command for each database: \nrladmin upgrade db \n\nDuring the database upgrade process, the database is restarted. As a result:\nFor databases that have replication enabled, a failover is done before the master database restarts to make sure that there is no downtime.\n\nFor databases without replication but with persistence enabled, the database is unavailable during the restart because data is restored from the persistence file. The length of the downtime is different for each persistence option. For example, AOF usually takes longer than an RDB file.\n\nFor databases that have neither replication nor persistence enabled, the database loses all its data after it is restarted.\n\nUpgrading Active-Active databases \nWhen upgrading an Active-Active (CRDB) database, the following may also be upgraded:\n\nProtocol version - RS 5.4.2 and higher include a new CRDB protocol version to support new Active-Active features. The CRDB protocol is backward-compatible so that RS 5.4.2 CRDB instances can understand write-operations that come from instances with the older CRDB protocol, but CRDB instances with the older protocol cannot understand write-operations of instances with the newer protocol version. As a result, after upgrading the CRDB protocol on one instance, instances that were not upgraded yet cannot receive write updates from the upgraded instance. The upgraded instance receives updates from upgraded and non-upgraded instances.\n\nNote: Upgrade all instances of a specific CRDB within a reasonable time frame to avoid temporary inconsistencies between the instances. Make sure that all instances of a specific CRDB are upgraded before performing global operations on the CRDB, such as removing instances and adding new instances.\n\nAfter upgrading an instance to use the new protocol version, it automatically receives any missing write-operations.\n\nFeature set version: RS 5.6.0 and higher include a new feature set version to support new Active-Active features. When updating the feature set version for an Active-Active database, the feature set version is updated for all of the database instances.\n\nTo upgrade a CRDB instance:\nUpgrade RS on each node in the clusters where the CRDB instances are located.\n\nTo confirm the status of the CRDB instances, run: rladmin status\n\nThe statuses of the CRDB instances on the node can indicate:\nOLD REDIS VERSION\nOLD CRDB PROTOCOL VERSION\nOLD CRDB FEATURESET VERSION\ncrdb-upgrade-node\n\nTo upgrade each CRDB instance including the Redis version and CRDB protocol version, run:\nrladmin upgrade db \n\nIf the protocol version is old, read the warning message carefully and confirm. crdb-upgrade-protocol\n\nThe CRDB instance uses the new Redis version and CRDB protocol version.\n\nTo upgrade the CRDB instance without upgrading the protocol version:\nIf the feature set version is old, all of the CRDB instances must be upgraded. Then, to update the feature set for each active-active database, run:\ncrdb-cli crdb update --crdb-guid --featureset-version yes\n\nRetrieve the with the following command:\ncrdb-cli crdb list\n\nLook for the fully qualified domain name (CLUSTER-FDQN) of the cluster and use the associated GUID.", "ruleFixId": "F-54642r804948_fix", "ruleCheckSystem": "C-54688r804947_chk", "ruleCheckContent": "To determine the current version of the software, perform the steps below:\n\n1. Log in to the Redis Enterprise UI as an Admin user.\n2. Navigate to the Cluster tab in the red banner.\n3. Click on the Configuration option.\n4. Find the Version number of the Cluster, Latest Redis version supported, and Latest Memcached version supported.\n5. Compare to current Redis Enterprise version available.\n\nIf the organization is not following their own defined time periods to apply updates, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2704, "benchmarkId": 37, "groupId": "V-251426", "title": "SRG-APP-000089-DB-000064", "description": "", "ruleId": "SV-251426r960879_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-012600", "ruleTitle": "Redis Enterprise DBMS must generate audit records for DoD-defined auditable events within all DBMS/database components.", "ruleVulnDiscussion": "Redis Enterprise does not generate all the DoD-required audit records.\n\nThis could lead to incomplete information as follows:\n- Without an audit trail, unauthorized access to protected data and attempts to elevate or restrict privileges could go undetected. \n- It would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.\n- Without the creation of certain audit logs, it would be difficult to identify attempted attacks, and an audit trail would not be available for some forensic investigation for after-the-fact actions. \n\nFor a complete list of unsupported audit requirements, email \"disa.letterkenny.re.mbx.stig-customer-support-mailbox@mail.mil\". Once the identity of the requester has been verified and the specifics of missing audit requirements obtained, risk can be assessed and a determination made as to whether it is acceptable.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-000169", "ruleFixText": "This requirement is a permanent finding and cannot be fixed.\n\nThis audit requirement must be continuously monitored.\n\nIt must be marked as an \"open\" finding to serve as a reminder to the AO and other stakeholders that this is an approved risk and needs to be reviewed periodically.", "ruleFixId": "F-54814r806432_fix", "ruleCheckSystem": "C-54859r808341_chk", "ruleCheckContent": "This requirement is a permanent finding and cannot be fixed. Redis Enterprise does not currently support session or transactional auditing on the database. \n\nRedis Enterprise does not generate all the DoD-required audit records; therefore this is a finding.\n\nThe site must seek AO or ISSO approval for use of Redis Enterprise 6.x with the understanding that not all of the DoD audit requirements are being met.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2705, "benchmarkId": 37, "groupId": "V-251428", "title": "SRG-APP-000164-DB-000401", "description": "", "ruleId": "SV-251428r1018620_rule", "ruleWeight": "10.0", "ruleSeverity": "medium", "ruleVersion": "RD6X-00-008750", "ruleTitle": "If DBMS authentication using passwords is employed, Redis Enterprise DBMS must enforce the DOD standards for password complexity and lifetime.", "ruleVulnDiscussion": "OS/enterprise authentication and identification must be used (SRG-APP-000023-DB-000001). Native DBMS authentication may be used only when circumstances make it unavoidable and must be documented and authorizing official (AO)-approved.\n\nThe DOD standard for authentication is DOD-approved PKI certificates. Authentication based on User ID and Password may be used only when it is not possible to employ a PKI certificate, and requires AO approval.\n\nIn such cases, the DOD standards for password complexity and lifetime must be implemented. DBMS products that can inherit the rules for these from the operating system or access control program (e.g., Microsoft Active Directory) must be configured to do so. For other DBMSs, the rules must be enforced using available configuration parameters or custom code.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-004066", "ruleFixText": "Configure LDAP/AD to enforce password complexity.\n\nTo enable LDAP:\n1. Import the saslauthd configuration.\n2. Restart saslauthd service.\n3. Configure LDAP users.\n\nTo provide the LDAP configuration information:\n1. Edit the configuration file located at /etc/opt/redislabs/saslauthd.conf or the installation directory used during initial configuration.\n\n2. Provide the following information associated with each variable:\nldap_servers: the ldap servers that authenticate against and the port to use\n- Port 389 is standardly used for unencrypted LDAP connections.\n- Port 636 is standardly used for encrypted LDAP connections and is strongly recommended.\n- Ldap_tls_cacert_file: The path to the CA Certificates. This is required for encrypted LDAP connections only.\n- ldap_filter: the filter used to search for users.\n- ldap_bind_dn: The distinguished name for the user that will be used to authenticate to the LDAP server.\n- ldap_password: The password used for the user specified in ldap_bind_dn.\n\n3. Import the saslauthd configuration into Redis Enterprise using the command below, which will distribute the configuration to all nodes in the cluster:\nrladmin cluster config saslauthd_ldap_conf \n\nNote: For this command to work on a new server installation, a cluster must be set up already.\n\n4. Restart saslauthd:\nsudo supervisorctl restart saslauthd\n\nAn example configuration for reference may be found below:\nldap_servers: ldaps://ldap1.mydomain.com:636 ldap://ldap2.mydomain.com:636\nldap_tls_cacert_file: /path/to/the/CARootCert.crt\nldap_search_base: ou=coolUsers,dc=company,dc=com\nldap_search_base: ou=coolUsers,dc=company,dc=com\nldap_filter: (sAMAccountName=%u)\nldap_bind_dn: cn=admin,dc=company,dc=com\nldap_password: secretSquirrel\n\nTo set up an LDAP user, select an external account type when configuring the user following the procedure to configure users.\n\nIf LDAP cannot be configured, configure the password complexity profile. To enable the password complexity profile, run the following curl command against the REST API:\ncurl -k -X PUT -v -H \"cache-control: no-cache\" -H \"content-type: application/json\" -u \":\" -d '{\"password_complexity\":true}' https://:9443/v1/cluster\nTo disable the password complexity requirement, run the same command, but set \"password_complexity\" to \"false\".", "ruleFixId": "F-54817r998305_fix", "ruleCheckSystem": "C-54863r998304_chk", "ruleCheckContent": "Redis Enterprise Software supports Lightweight Directory Access Protocol (LDAP) admin console users. LDAP must be enabled to enforce password complexity. If LDAP is not in use, a password complexity profile can be configured in Redis Enterprise; however, it currently does not meet the DOD standard.\n\nReview the LDAP settings relating to password complexity. To check the LDAP settings:\n1. Log in to the server housing the Redis Enterprise as an admin user.\n2. CAT /etc/opt/redislabs/saslauthd.conf or the installation choice used during initial configuration.\n3. Verify the following is configured: \nldap_servers\nLdap_tls_cacert_file\nldap_filter\nldap_bind_dn\nldap_password\n\nIf LDAP cannot be configured, this check can be downgraded if the password complexity profile has been configured:\n- At least eight characters\n- At least one uppercase character\n- At least one lowercase character\n- At least one number (not first or last character)\n- At least one special character (not first or last character)\n\nIn addition, the password:\n- Cannot contain the user ID or reverse of the user ID\n- Cannot have more than three repeating characters\n\nTo verify this, either attempt a password change or view the password complexity settings in the REST API.\n\nIf LDAP or the password complexity profile is not in use, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" }, { "id": 2706, "benchmarkId": 37, "groupId": "V-265880", "title": "SRG-APP-000456-DB-000400", "description": "", "ruleId": "SV-265880r999546_rule", "ruleWeight": "10.0", "ruleSeverity": "high", "ruleVersion": "RD6X-00-007950", "ruleTitle": "Redis Enterprise products must be a version supported by the vendor.", "ruleVulnDiscussion": "Unsupported commercial and database systems should not be used because fixes to newly identified bugs will not be implemented by the vendor. The lack of support can result in potential vulnerabilities. Systems at unsupported servicing levels or releases will not receive security updates for new vulnerabilities, which leaves them subject to exploitation.\n\nWhen maintenance updates and patches are no longer available, the database software is no longer considered supported and should be upgraded or decommissioned.", "ruleFalsePositives": "", "ruleFalseNegatives": "", "ruleDocumentable": "false", "ruleMitigations": "", "ruleIdent": "CCI-003376", "ruleFixText": "Remove or decommission all unsupported software products.\n\nUpgrade unsupported DBMS or unsupported components to a supported version of the product.", "ruleFixId": "F-69703r999545_fix", "ruleCheckSystem": "C-69799r999544_chk", "ruleCheckContent": "Review the system documentation and interview the database administrator. Identify all database software components.\n\nReview the version and release information.\n1. Log in to the adminUI console as an authorized user.\n2. Navigate to the cluster tab and select configuration.\n3. Check the version number next to Redis Labs Enterprise Cluster.\n\nAccess the below Redis website or use other means to verify the version is still supported:\nhttps://docs.redislabs.com/latest/rs/administering/product-lifecycle\n\nIf the DBMS or any of the software components are not supported by the vendor, this is a finding.", "createdAt": "2025-10-21T11:13:15.656Z", "updatedAt": "2025-10-21T11:13:15.656Z" } ], "profiles": [ { "id": 266, "benchmarkId": 37, "profileId": "MAC-1_Classified", "title": "I - Mission Critical Classified", "description": "", "createdAt": "2025-10-21T11:13:16.620Z", "updatedAt": "2025-10-21T11:13:16.620Z" }, { "id": 267, "benchmarkId": 37, "profileId": "MAC-1_Public", "title": "I - Mission Critical Public", "description": "", "createdAt": "2025-10-21T11:13:16.620Z", "updatedAt": "2025-10-21T11:13:16.620Z" }, { "id": 268, "benchmarkId": 37, "profileId": "MAC-1_Sensitive", "title": "I - Mission Critical Sensitive", "description": "", "createdAt": "2025-10-21T11:13:16.620Z", "updatedAt": "2025-10-21T11:13:16.620Z" }, { "id": 269, "benchmarkId": 37, "profileId": "MAC-2_Classified", "title": "II - Mission Support Classified", "description": "", "createdAt": "2025-10-21T11:13:16.620Z", "updatedAt": "2025-10-21T11:13:16.620Z" }, { "id": 270, "benchmarkId": 37, "profileId": "MAC-2_Public", "title": "II - Mission Support Public", "description": "", "createdAt": "2025-10-21T11:13:16.620Z", "updatedAt": "2025-10-21T11:13:16.620Z" }, { "id": 271, "benchmarkId": 37, "profileId": "MAC-2_Sensitive", "title": "II - Mission Support Sensitive", "description": "", "createdAt": "2025-10-21T11:13:16.620Z", "updatedAt": "2025-10-21T11:13:16.620Z" }, { "id": 272, "benchmarkId": 37, "profileId": "MAC-3_Classified", "title": "III - Administrative Classified", "description": "", "createdAt": "2025-10-21T11:13:16.620Z", "updatedAt": "2025-10-21T11:13:16.620Z" }, { "id": 273, "benchmarkId": 37, "profileId": "MAC-3_Public", "title": "III - Administrative Public", "description": "", "createdAt": "2025-10-21T11:13:16.620Z", "updatedAt": "2025-10-21T11:13:16.620Z" }, { "id": 274, "benchmarkId": 37, "profileId": "MAC-3_Sensitive", "title": "III - Administrative Sensitive", "description": "", "createdAt": "2025-10-21T11:13:16.620Z", "updatedAt": "2025-10-21T11:13:16.620Z" } ] }