Top 10 DB2 Family Security Best Practices Part 1

The DB2 database family leads the industry with some of the best security features, safeguards, and mechanisms to secure your data.  Security breaches of any database trouble us all, so it is always good to review the best security practices available.  Below are a list of the top ten that all DB2 DBAs should verify that their configurations and/or implementations have implemented as soon as possible.

  1. Implement a standard user id account ROLES policy. For each database, define separate ROLES for each one of the types of administrators, developers, and end users.  Without ROLES, the job of grouping the various user ids and managing the levels of DB2 security authorities becomes a huge task and big time burden.  Set up ROLES for each all the following types of IDs to give you a better chance of managing the environment more securely.

    SECADM
    SYSADM authority
    SYSCTRL
    SYSMAINT
    SYSMON
    DBADM
    • Some shops have separate ROLES for the DB2 LOAD, BINDADD, CREATETAB authorities

    ACCESSCTRL
    DATAACCESS
    Grant CONNECT to a ROLE set up to group specific application users

    • Same with QUIECSE_CONNECT

    DB2 z/OS and DB2 LUW security ROLES are a great way to consolidate and simplify security definitions.  Check out Chapter 4: Roles and Trusted Context in the Security Functions of IBM DB2 10 for z/OS Redbook.

  2. Only implement the services or connections that are justified and absolutely needed for your system and applications.

    The DB2 LUW system has a number of default settings which provide the system and database the ability to be “discovered” or discover other DB2 systems or databases.  This discovery information is in the Database Manager configuration which can be displayed by using the DB2 “GET DBM CFG” command.  Within the listing of various database manager configuration parameters is the “Discovery Mode” for the entire server instance.  By first connecting to a particular database and using the DB2 “GET DB CFG” command you can get the specific database discovery mode option settings.

    Database Discovery Parameters
    Database Manager Configuration
    Discovery mode                 (DISCOVER) = SEARCH
    Discover server instance     (DISCOVER_INST) = ENABLE

    Database Configuration
    Discovery support for this database    (DISCOVER_DB) = ENABLE

    The DB2 instances security needs to be monitored to make sure that all of your most important production databases are not exposed unnecessarily.  By leveraging the DB2 system settings, the database can discover other DB2 servers and can be “discovered” and respond to meta-data inquiries by users and various vendor products.

    Application developer clients and DB2 can each issue search discovery requests to find DB2 server systems connected to the network.  Search discovery provides functionality to acquire or provide information about the DB2 instance so others can attach and access the DB2 database environment.

    Allowing the DB2 instance server to discover other servers and allowing any production DB2 database server to be discovered by other clients and products may unnecessarily expose your environment to unwanted attention to your PHI and PII database information.

    The automatic “Discovery” or answering of inquiries is on by default, so administrators who only do the default system and database installation risk exposure.  Make sure to analyze whether the DB2 clients, application interfaces, or vendor products need this function before turning it off.  To turn the DB2 Discovery off, update and disable the appropriate DB2 database manager server instance and individual database configurations as soon as possible.  The discovery can be disabled within the DB2 server configuration by setting each of the DB2 configuration parameters DISCOVER, DISCOVER_INST, and DISCOVER_DB to the “DISABLE” setting.
  3. Keep up to date with ALL the software patches on ALL the software running on your system.  Security vulnerabilities can be found in any software running on your system.  Your system, database, and applications are always vulnerable to the weakest or oldest software link, and that is why it’s vital to keep up with all the latest software versions and releases.

    Within the DB2 z/OS environment there are a huge number of interfaces and associated software considerations.  That is why it is best to get the IBM Consolidated Service Test (CST) and Recommended Service Upgrade (RSU) maintenance.  This IBM CST and RSU maintenance is pre-tested with a large number of other of IBM’s products.  The IBM CST and RSU software testing process is continuously running to expose any security issues before the software is released. That way, you can install any needed fixes into your environment prior to exposure to the public.  This includes all the latest preventive HIPERS and PE fixes from a wide range of IBM products to provide your shop with a fully test software base.  For more information about the IBM CST and RSU software click here.

    Within the DB2 LUW environment, it is vital to keep up with all the maintenance, not only for security within DB2 LUW itself, but also for all of its associated products like DB2 Connect, the various ODBC, CLI, JDBC .NET drivers, and other IBM DB2 extenders and related software.  Within the DB2 LUW environment there are sometimes a number of new functions or enhancements that can be leveraged from the new software Fix Packs.  For example DB2 “Cancun” Version 10.5 Fix Pack 4 added six great features that I detailed in a previous blog.  In the DB2 LUW 10.5.4 Cancun Fix Pack there are also new security features to help audit your application environments.  Keeping up with all the DB2 and related software changes is vital.  More information on the DB2 LUW Fix Packs can be found here.
  4. Implement DB2 Trusted Context to improve security and also improve application performance.  During the web application execution the threads from your WebSphere or other web servers are used and created, authorized, and de-allocated.  There is typically thread reuse which minimizes the creation and authorization overhead.  To further optimize and secure the thread creation and authorization overhead, a trusted context between the WebSphere server instance data sources and the DB2 z/OS or DB2 LUW system should be defined.

    A trusted context configuration establishes trust between the WebSphere server instance and DB2 system that pre-authorizes threads from that unique WebSphere application server to allow DB2 SQL access of the database.

    Define the trusted context configuration between each of the WebSphere application servers and your DB2 systems or instances.  Make sure to use a different trusted context name to enhance the DB2 security configuration.  Using different trusted context definitions for each of the WebSphere application server will ease identification of the application server workloads inside the database, help debug application issues, and help identify workload balancing issues across your servers into the database.  Trusted context helps tighten security so only predefined connections can access the DB2 z/OS or DB2 LUW systems and databases through the server while improving possible thread reuse and maximizing security while minimizing its overhead.

    CREATE TRUSTED CONTEXT my_trusted_context_name  
           BASED UPON CONNECTION USING SYSTEM AUTHID user-id 
           ATTRIBUTES (ADDRESS   ‘192.0.2.1’)  
           DEFAULT ROLE trusted_role  
           ENABLE

    Follow the instruction from the DB2 SQL manuals and the information on IBM’s website at this URL: http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.sec.doc/doc/t0050515.html.
  5. Make sure there are many security encryption layers guarding all your database and application connections.  To help guard your data as it travels across your network, make sure to use the AES encrypted DB2 Connect “DATA_ENCRYPT” settings within all your DB2 Connect client definitions.  This encryption setting encrypts all the data exchanged from the DB2 Connect client and the host database system and prevents anyone from sniffing or grabbing data by listening on the network.

    To further secure the communication layer, use the new Transport Layer Security (TLS), the modern version of Secure Sockets Layer (SSL).  The TLS is a client/server cryptographic protocol for TCP/IP that provides a secure handshake and mechanism for exchanging digital certificates within web applications.  For any company doing web commerce, securing and encrypting all database and client communications is critical.  Through the setup and usage of TLS, your application can utilize DB2 security certificates for both your server side and client side security.  There is a great IBM Red Paper on TLS and SSL that describes the steps to configure your secure connection and certificate environment for all types of JDBC, .NET, ODBC, and other connectivity between the database and clients.

This is only Part 1 of the DB2 Family Security Best Practices, and part two will be coming out shortly.  If you don’t have these DB2 security best practices implemented, make sure to schedule them as soon as possible.  Talk to you all soon when DB2 security best practices Part 2 comes out.

Also I will be on The DB2Night Show z/OS Edition #Z60: SQL Performance for a Big Data 22 Billion Row Data Warehouse.

This presentation discusses the design, architecture, performance and complex SQL issues building and reporting within a big data analytics DW system. You will learn 30 SQL tuning tips, the real life issues, agile SQL considerations and SQL design solutions for building a data warehouse of 22+ billion rows in six months through this presentation. Sign up here.


I authored two CIO DB2 Security Audit white papers and a technical DB2 Security Audit white paper for SEGUS.  Also at the link is a webinar talking about the SEGUS security and DB2 audit considerations. The How to establish a Security Audit for DB2 z/OS white paper can be found here (https://www.segus.com/media/wp-security-audit-dba-en.pdf)” and the Is 339° Security Audit Sufficient? White paper is here (https://www.segus.com/media/wp-PSI-339-security-cto-en.pdf) and the Powerpoint webinar discussion presentation with SEGUS is here (https://www.segus.com/events/webinars/db2-for-zos-security-audit-protecting-your-assets/).


Here’s a list with links to other posts that may help you improve your DB2 performance, security, and ease-of-use:

5 More DB2 SQL Performance Tips
Another 5 More DB2 SQL Performance Tips
5 Big Data SQL Performance Tips – Fixing Generated SQL
DB2 11 SQL Performance Improvements
5 More SQL Performance Tips for your Big Data
Hadoop SQL: 4 Reasons Why BigInsights Is the Best
Vital Java DB2 SQL Performance Considerations
More DB2 Family Security Best Practices Part 7: Preventing SQL Injection
DB2 SQL Security Audits


Dave Beulke is a system strategist, application architect, and performance expert specializing in Big Data, data warehouses, and high performance internet business solutions.  He is an IBM Gold Consultant, Information Champion, President of DAMA-NCR, former President of International DB2 User Group, and frequent speaker at national and international conferences. His architectures, designs, and performance tuning techniques help organization better leverage their information assets, saving millions in processing costs.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>