STIGViewer Support

DB2 must use NIST FIPS 140-2 validated cryptographic modules for cryptographic operations.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-213702DB2X-00-004600SV-213702r961050_ruleCCI-000803high
Description
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. Applications, including DBMSs, utilizing cryptography are required to use approved NIST FIPS 140-2 validated cryptographic modules that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. The security functions validated as part of FIPS 140-2 for cryptographic modules are described in FIPS 140-2 Annex A. The cryptographic functionality in IBM DB2 for LUW includes features that are fully FIPS 140-2 validated, and others that are not. To be sure of using only FIPS 140-2 validated modules, specify SSL (TLS) for communication and IBM Database Native Encryption for data at rest. The decision whether to employ cryptography is the responsibility of the information owner/steward, who exercises discretion within the framework of applicable rules, policies, and law.
STIGDate
IBM DB2 V10.5 LUW Security Technical Implementation Guide2026-05-23

Related Frameworks

1 mapping across 4 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (7) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

IAC-01.2Authenticate, Authorize and Audit (AAA)
1.00
IAC-02Identification & Authentication for Organizational Users
1.00
IAC-03Identification & Authentication for Non-Organizational Users
1.00
IAC-04Identification & Authentication for Devices
1.00
IAC-05Identification & Authentication for Third-Party Technology Assets, Applications and/or Services (TAAS)
1.00
CRY-02Automated Authentication Through Cryptographic Modules
0.50
IAC-12Cryptographic Module Authentication
0.50
NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (36) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

AC-17(1)Monitoring and Control
1.00
AC-17(2)Protection of Confidentiality and Integrity Using Encryption
1.00
AC-2(4)Automated Audit Actions
1.00
AC-3Access Enforcement
1.00
AC-4Information Flow Enforcement
1.00
AC-4(17)Domain Authentication
1.00
AC-6(9)Log Use of Privileged Functions
1.00
AU-12Audit Record Generation
1.00
AU-3Content of Audit Records
1.00
CM-5(1)Automated Access Enforcement and Audit Records
1.00

+26 more (top 10 by confidence shown)

CCI1 mapping
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (2) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

Who does this work

7 NICE work roles and 5 EC-Council certifications.

This is an inference across published mappings, not a single claim by anyone. This check maps to a control, which maps to a Cybersecurity Framework outcome, which NIST assigns to the work roles below. EC-Council separately maps its certifications to those same roles.

A certification prepares someone for a role. It is not evidence that a holder is qualified, and neither NIST nor EC-Council has stated that any certification here addresses this check.

Work-role assignments published by NIST (NICE Framework Components 2.2.0 and the CSF 2.0 OLIR crosswalk). Certification mappings published by EC-Council.

Details

Check Text (C-213702r961050_chk)

If it has been determined that encryption is not required, this is not a finding. Review the cryptographic configuration. If SSL/TLS is not specified for encryption of communications, this is a finding. See below for more detailed instructions. If IBM Database Native Encryption is not specified for encryption of data at rest, this is a finding. See below for more detailed instructions. To Verify SSL is in use: Check the DB2 registry variable DB2COMM to include SSL. $db2set -all If DB2COMM does not include SSL, this is a finding. Find the value of SSL_VERSIONS by running: $db2 get dbm cfg If SSL_VERSIONS is not set to TLSV12, this is a finding. Find the value of SSL_CIPHERSPECS by running: $db2 get dbm cfg If SSL_CIPHERSPECS is not set to a symmetric algorithm key length that is greater than or equal to 112, this is a finding. Find the value of SSL_SVC_LABEL by running: $db2 get dbm cfg If the parameter SSL_SVC_LABEL is not set to a certificate with RSA key length that is greater than or equal to 2048, this is a finding. If the certificate does not have a digital signature with minimum SHA2, this is a finding. The above settings ensure that all connections over SSL in any CLP or Java application strictly adhere to NIST SP 800-131A. To Verify DB2 native encryption is being used, run the following SQL Query: DB2> SELECT SUBSTR(object_name,1,8) AS NAME, SUBSTR(object_type,1,8) TYPE, SUBSTR(algorithm,1,8) ALGORITHM FROM TABLE(sysproc.admin_get_encryption_info()) If value of Algorithm is NULL for the database, this is a finding. If the database is not encrypted with native encryption or any third-party tool, this is a finding.

Fix Text (F-14921r295156_fix)

Modify the cryptographic configuration to employ SSL/TLS for encryption of communications. Modify the cryptographic configuration to employ IBM Database Native Encryption for encryption of data at rest.