What changed in IBM DB2 V10.5 LUW STIG V2R2V2R2 changes

IBM DB2 V10.5 LUW STIG V2R2 (2026-07-01) replaced V2R1 (2023-07-26): 1 check updated. It has 93 checks, against 93 in V2R1.

  • 0 added
  • 0 removed
  • 1 updated

Updated fields: Check text 1Fix text 1Severity 1Discussion 1

Updated in V2R2 (1)

V-213729CAT IDB2 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.Severity, Check text, Fix text, Discussion

Severity

mediumhigh

Check text

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. If the documentation indicates no information requires such protections, this is not a finding. DB2 native encryption can encrypt the data at rest; or third-party tools, likesuch as IBM Guardium, can provide encryption for data at rest. To find if a database is encrypted with DB2 native encryption, run the following SQL Query: DB2> SELECT * FROM TABLE(SYSPROC.ADMIN_GET_ENCRYPTION_INFO()) If the 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

To create the database using DB2 native encryption run the following command: $db2 create db &ltdatabase name> encrypt SeeRefer to the detailed instructions in the link in the note section below to create the encrypted database. Note: Select the following link for details on how to set up DB2 native encryption: http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.admin.sec.doc/doc/t0061766.html?lang=en If a third-party tool is used for database encryption (IBM highly recommends using IBM Guardium) use the third-party tool's specific check and fix.

Discussion

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. Selection 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). The decision of whether to employ cryptography is the responsibility of the information owner/steward, who exercises discretion within the framework of applicable rules, policies, and law.

How these changes are found

Checks are matched across the two releases by V-number. A check counts as updated when DISA gave it a new rule revision (the r number in its SV-…_rule id) and its title, severity, check text, fix text, discussion, CCIs or other fields changed — the same comparison STIG Compare makes. Added checks are new V-numbers; removed checks are V-numbers V2R2 no longer has.

Comparing other releases, or this one against an older release? Pick any two in STIG Compare.