Industry Standards

  • Db2® conforms with the following industry standards for SQL:
    • ISO/IEC 9075-1:2016, Information technology - Database languages - SQL - Part 1: Framework (SQL/Framework)
    • ISO/IEC 9075-2:2016, Information technology - Database languages - SQL - Part 2: Foundation (SQL/Foundation)
    • ISO/IEC 9075-3:2016, Information technology - Database languages - SQL - Part 3: Call-Level Interface (SQL/CLI)
    • ISO/IEC 9075-4:2016, Information technology - Database languages - SQL - Part 4: Persistent Stored Modules (SQL/PSM)
    • ISO/IEC 9075-10:2016, Information technology - Database languages - SQL - Part 10: Object Language Bindings (SQL/OLB)
    • ISO/IEC 9075-11:2016, Information technology - Database languages - SQL - Part 11: Information and Definition Schemas (SQL/Schemata)
    • ISO/IEC 9075-13:2016, Information technology - Database languages - SQL - Part 13: Java Routines and Types (SQL/JRT)
    • ISO/IEC 9075-14:2016, Information technology - Database languages - SQL - Part 14: XML-Related Specifications (SQL/XML)
    • ISO/IEC 13249-3:2011, Information technology - Database languages - SQL multimedia and application packages - Part 3: Spatial
  • Db2 conforms with the following industry technical report for SQL:
    • ISO/IEC TR 19075-6:2016, Information technology - Database languages - SQL - Part 6: SQL support for JavaScript Object Notation (JSON)
  • Character Data Representation Architecture Reference and Registry, at Character Data Representation Architecture.
  • The Unicode Standard, at http://www.unicode.org
  • Cryptographic standards

    Db2 uses one or more of the following FIPS 140-2 approved cryptographic providers:

    • IBMJCEFIPS (certificate 376)
    • IBMJSSEFIPS (certificate 409)
    • IBM® Crypto for C (ICC) (certificate 3064)

    The following behavior is default starting with Db2 releases that contain KI DT223175:

    When a cryptographic algorithm is available in the FIPS 140 certified ICC, Db2 prefers the algorithm provided by the certified IBM Crypto for C (ICC) over the non-certified IBM Crypto for C (ICC). If the algorithm is not available in the FIPS 140 certified IBM Crypto for C (ICC), or the implementation in the certified IBM Crypto for C (ICC) is affected by a known vulnerability, the uncertified IBM Crypto for C (ICC) is used.

    Enforcing the use of only FIPS certified IBM Crypto for C (ICC) To enforce the use of only the FIPS certified IBM Crypto for C (ICC), and to disallow any use of the uncertified IBM Crypto for C (ICC), strict FIPS mode must be enabled. Enabling strict FIPS mode is done by setting the DB2AUTH registry variable to STRICT_FIPS. If the DB2AUTH variable is already set, multiple options can be separated by commas.

    db2set DB2AUTH=STRICT_FIPS

    In an environment without a Db2 registry, such as the Data Server Driver, the DB2AUTH registry variable can be set in the environment.

    Unix/Linux: export DB2AUTH=STRICT_FIPS

    Windows: setx DB2AUTH STRICT_FIPS /m

    If the LDAP authentication plugins are in use, the FIPS_MODE parameter can be set to STRICT in the IBMLDAPSecurity.ini

    FIPS_MODE=STRICT
    Important: Db2 releases that contain KI DT223175 no longer include a FIPS 140 certified IBM Crypto for C (ICC) on MacOS. Only the uncertified IBM Crypto for C (ICC) is available.
    Warning:

    In response to CVE-2023-32342, Db2 releases with KI DT223175 uses the non-FIPS IBM Crypto for C (ICC) for TLS ciphers that use RSA key exchange, as the FIPS certified IBM Crypto for C (ICC) is vulnerable to CVE-2023-32342. Customers with a requirement to use only FIPS 140 certified cryptographic modules must enable Strict FIPS mode.

    In strict FIPS mode, Db2 releases with KI DT223175 disables all TLS ciphers and versions that are vulnerable to CVE-2023-32342. Note: RSA certificates are not affected by CVE-2023-32342, and do not need to be changed.

    The following restrictions apply to TLS when strict mode is enabled:

    • TLS 1.0 and 1.1 are disabled in strict mode, as TLS 1.1 and earlier only support ciphers that use RSA key exchange. If the SSL_VERSIONS DBM CFG parameter is unset, or is set to TLSV1, TLS 1.2 is enabled in its place.
    • TLS 1.2 ciphers that use RSA key exchange (TLS_RSA_*) are disabled. If there are no remaining ciphers in the SSL_CIPHERSPECS DBM CFG parameter, all supported ECDHE ciphers are enabled. For instances using RSA certificates, Db2 automatically prefers TLS_ECDHE_RSA ciphers for TLS 1.2 and no certificate change is required.
    • TLS 1.3 is unaffected by CVE-2023-32342

    Db2 is compliant with NIST SP 800-131A and provides enhanced and stronger cryptographic keys along with more robust algorithms.

    The certificates are listed on the NIST website at Validated FIPS 140-1 and FIPS 140-2 Cryptographic Modules.

  • File change monitoring for compliance with the Payment Card Industry Data Security Standard (PCI-DSS)
    When monitoring for ransomware and viruses, you can exclude most files that sit outside of the Db2 installation directory and the /sqllib directory. Files that sit outside of these directories change frequently and are less likely to be targets for malware. Some files and folders within the /sqllib directory do change frequently and can also be omitted from malware monitoring:
    • /cfg: contains configuration files that users can modify.
    • /db2dump: contains diagnostic files generated by Db2.
    • /tmp: temporary directory that various tools use for writing data.
    • /userprofile: On Linux and UNIX systems, customers can change this file to customize the shell environment.

    For more information, see Instance directory.

  • Distributed relational database architecture
  • JDBC
  • Object Management Group (OMG) Common Warehouse Metadatamodel (CWM)
  • Open Geospatial Consortium (OGC)