Secure IBM Db2 with cnspec

Scan your IBM Db2 (LUW) databases to find security risks before they become incidents. cnspec evaluates database authorities, roles and their members, audit policies, configuration parameters and registry variables, and the privileges granted on tables, routines, and table spaces.

cnspec connects over the Db2 protocol and inventories the database through read-only queries against the system catalog (SYSCAT) and the administrative views (SYSIBMADM). It never touches your data.

If you're new to cnspec, start with the Quickstart. For an overview of every database cnspec can scan, see the database scanning overview.

Prerequisites

To scan Db2 with cnspec, you must have:

• cnspec installed on your workstation
• Network access to the database (port 50000 by default)
• A user with CONNECT on the database and read access to SYSCAT and SYSIBMADM

Authenticate

cnspec authenticates with a database user and password and connects to a named database:

cnspec shell db2 --host db.contoso.com --database PRODDB --user auditor --ask-pass

Prefer a least-privileged auditing user. The account needs CONNECT plus read access to the catalog and administrative views, for example membership in a role granted SELECT on SYSCAT and SYSIBMADM. A read that hits a missing privilege (SQL0551N or SQL0552N, SQLSTATE 42501) degrades to empty rather than failing the scan, so confirm db2.instance.authorities is populated before trusting a passing check.

Connection options

Verify with a quick Db2 check

cnspec shell db2 --host db.contoso.com --database PRODDB --user auditor --ask-pass

cnspec> db2.instance { serviceLevel instanceName databaseName }
db2.instance: {
  serviceLevel: "DB2 v11.5.8.0"
  instanceName: "db2inst1"
  databaseName: "TESTDB"
}

If cnspec connects and shows the service level, you're ready to scan.

Scan Db2

cnspec scan db2 --host db.contoso.com --database PRODDB --user auditor --ask-pass

When a scan completes, cnspec prints a summary of all the checks it ran, grouped by policy, along with a risk score from 0 (no risk) to 100 (highest risk). Failed checks include remediation guidance to help you fix issues. To learn more about reading scan results, read Understand cnspec Results.

Mondoo doesn't yet ship an out-of-the-box Db2 policy. The resources are shaped around the CIS IBM Db2 Benchmark, so the checks below map closely to its recommendations. Use them as a starting point and create your own policies to meet your requirements.

Explore and test checks interactively

cnspec shell db2 --host db.contoso.com --database PRODDB --user auditor --ask-pass

List database authorities

cnspec> db2.instance.authorities { grantee granteeType dbadm securityadm dataaccess accessctrl }

Read configuration parameters

dbmConfig holds the database-manager (instance-level) parameters and dbConfig the database-level ones:

cnspec> db2.instance.dbmConfig.where(name == "authentication" || name == "sysadm_group") { name value }
db2.instance.dbmConfig.where: [
  0: { name: "authentication"  value: "SERVER" }
  1: { name: "sysadm_group"    value: "DB2IADM1" }
]

List roles and their members

cnspec> db2.instance.roles { name grantees }

Read registry variables

This is the SQL equivalent of db2set -all. A variable that was never set is absent from the list:

cnspec> db2.instance.registryVariables.where(name == "DB2COMM") { name value level }

List audit policies

cnspec> db2.instance.auditPolicies { name secMaintStatus sysAdminStatus checkingStatus errorType }

Example security checks

Ensure authentication is not delegated to the client

CLIENT authentication trusts the connecting machine to state who the user is:

cnspec> db2.instance.dbmConfig.where(name == "authentication").none(value == "CLIENT")
[ok] value: true

Ensure administrative authority is limited

DBADM, SECADM, and DATAACCESS each grant sweeping control over the database:

cnspec> db2.instance.authorities.where(dbadm || securityadm || dataaccess) { grantee granteeType }

Ensure PUBLIC holds no meaningful authority

Anything granted to PUBLIC is held by every user that can connect:

cnspec> db2.instance.authorities.where(grantee == "PUBLIC").none(dataaccess || bindadd || createtab || implicitSchema || externalRoutine)
[ok] value: true

Ensure PUBLIC cannot read the system catalog

cnspec> db2.instance.tablePrivileges.where(grantee == "PUBLIC" && schema == "SYSCAT").none(select == true)
[ok] value: true

Ensure PUBLIC cannot execute the authorization routines

cnspec> db2.instance.routinePrivileges.none(grantee == "PUBLIC" && specificName == "AUTH_LIST_ROLES_FOR_AUTHID" && execute)
[ok] value: true

Ensure PUBLIC holds no table space privilege

cnspec> db2.instance.tablespacePrivileges.where(grantee == "PUBLIC").none(use == true)
[ok] value: true

Ensure an audit policy records grants and revokes

secMaintStatus of B audits both successes and failures, S successes only:

cnspec> db2.instance.auditPolicies.any(secMaintStatus == "B" || secMaintStatus == "S")
[ok] value: true

Ensure audit failures are themselves audited

An errorType of A records failures of the audit facility, so a silenced audit is visible:

cnspec> db2.instance.auditPolicies.all(errorType == "A")
[ok] value: true

Ensure no user object lives in a system table space

cnspec> db2.instance.tables.where(tablespace == "SYSTOOLSPACE") { schema name }

Review CONTROL grants on tables

CONTROL on a table carries every privilege on it, including the right to grant them onward:

cnspec> db2.instance.tablePrivileges.where(control) { grantee granteeType schema table }

Learn more

• IBM Db2 Resource Pack Reference: every Db2 resource and field cnspec can query
• Write Effective MQL: guide to authoring checks and queries

Some CIS Db2 recommendations cover files and operating system groups, for example db2sysc permissions, SYSADM/SYSCTRL/SYSMAINT group membership, and diagnostic directory permissions. Those aren't reachable over SQL. Scan the database host with the os provider to cover them.