Home > Articles > Data > DB2

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

The DB2 Security Plan

Because you’re reading this book, it’s obvious that you have an interest in protecting the data assets held by your organization; but unless you have a very small organization with a single very small database, you need a plan and a leader. Formalization of that plan will provide great assistance toward the goal of database security, and during the formulation of that plan, a leader (corporate sponsor) should emerge.

Many organizations already have some type of security plan in place that may or may not include specifics on database protection. If your organization has an enterprise-level security plan, the DB2 database security plan should be a significant and highly visible part of that document. If you do not have an enterprise level security plan in place, the DB2 database security plan should still be created, even if it must be undertaken as a standalone document. Given the criticality of protecting the data stored in those DB2 databases, ignoring the security responsibilities may mean unacceptable organizational risk.

The DB2 security plan document is a road map that will provide the foundation for the enforcement of the operational DB2 database security policies that will be implemented. It should provide a meeting of the minds with regard to the security of the organization databases and how DB2 should be used to fulfill those needs.

If you are a DB2 database administrator, you have a vested interest in getting a DB2 security plan in writing. This plan, once written and approved by management, can be your guideline for setting up your database security policies. It can be referred to when questions arise, such as access levels, provided to auditors to facilitate their reviews, and should be reviewed or revised when new applications are installed. A major bonus for you is that when finalized, it will keep you from having to answer the same questions about security over and over again, saving you time and allowing preservation of your sanity.

So, if necessary, take the lead on getting a committee involved in formalizing a written DB2 security plan. You may get resistance, but remember that the database you are trying to protect is potentially one of the greatest assets held in trust by your organization (and the people it serves), and, therefore, it should be treated and protected just as any other valuable corporate asset would.

Security Plan Meeting Participants

The first step toward achieving your database security plan is to identify the team members who should be involved in the creation and review of the document. In a typical organization, the positions listed in Table 2.1 might be considered key to this task.

Table 2.1. Database Security Plan Team Members

All Appropriate Members of Management



Vice presidents

Division managers

Technical team leads

Application subject matter experts (SMEs)

Network administrators

Systems administrators

Database administrators (DBAs)

Corporate security officers

One important factor in determining who to include is the realization that the matters discussed in these meetings could be used by internal or external sources in inappropriate ways. Because the focus of the meetings is to discuss and mitigate current and future threats, the core meeting group should consist of individuals who are trusted by the organization to maintain the confidentiality of issues discussed.

To succeed, the database security plan needs a corporate sponsor. This should be someone within the organization who has the appropriate level of interest, authority, and responsibility to approve, communicate, and enforce the resultant plan. If your corporation has a security officer, especially if the position that person holds has sufficient status within the organization, the security officer may be able to fulfill the sponsor role.

Obviously in large organizations, division personnel should be involved in the process. It is important to get their unique perspective on database security because they may face challenges that are not easily identified. Depending on your organizational structure, division technical personnel should be invited to the meeting if they have discrete environments or can provide technical expertise relevant to database or application security.

Communication and information from application SMEs will likely be necessary to determine the granularity of database security needed. These are the individuals who can indicate which data needs the most protection, which users should have access and the level of that access, and how to determine whether a breach has occurred. These individuals may be technical leads, application programmers, or just those who know the application well because of their role. For example, an accountant might be the individual who knows the most about the general ledger applications.

The remaining participants should be the hands-on technical individuals who typically have the roles of network administrator, system administrator, and DBA. Participation of individuals who fulfill these roles is absolutely critical to successfully designing a plan because each will bring a unique focus to the process.

Gather Information

Before any meetings are scheduled, there should be some gathering and summarization of information if it is not already readily available to the team. A minimum starting list of items includes the following:

  • Current security documents
  • Standards (formal or informal)

    Any written security guidelines

    Any informal security policies that have been enforced in the past

  • Hardware in use or proposed for DB2 databases

    Machine specifics

    Physical location

  • Connectivity mechanisms in use
  • Current authentication methods
  • Operating system information

    OS type

    OS level

  • Maintenance procedures, such as patch management, currently in place
  • Licensing agreements
  • User and group information
  • List of DB2 instances by hardware

    The type of instance

    • Development
    • Test
    • Production
  • The database manager configuration parameters in use per instance (DBM configuration)
  • The product and level of the DB2 code base installed (DB2LEVEL command output)
  • List of DB2 databases by instance
  • Database configuration(s) (DB configuration)
  • Backup procedures including types, frequency, and storage location
  • Applications currently being run (as observed or proposed)
  • Typical number of users
  • Access control measures in place
    • Authorities
    • Privileges
  • List of applications
    • Type
    • Web-based
    • Third-party
    • Batch
  • Application “owners”
  • Prior risk assessments
  • Information on known data classification
  • Special security considerations
    • Federated
    • Information Integrator
    • High Availability Cluster Multi-Procesing (HACMP™)
  • Results and recommendations of any security audits that have been performed

Meeting Goals and Desired Outcomes

After you get the appropriate parties and the initial information together, meeting goals should be established. It is difficult to create a database security plan in only one meeting unless your organization is very small, so it might be best to create overall goals and then plan enough meetings to allow time for discussion.

Segment the discussion with the idea that internal and external security may pose different threats and, therefore, require a different set of goals. Uniformity of standards can simplify security policies and should be considered to the extent that they can be implemented across the organization without incurring increased risk.

The result of these meetings should include a comprehensive, written policy addressing the components of the database security plan, including at a minimum, the following:

  1. Appropriate analysis of internal and external database security risks and the current approach toward their mitigation
  2. External security authorization mechanism
    1. Group and user naming standards
    2. Password standards and change guidelines
  3. Operating system standards (for DB2 files, file systems, logical volumes)
  4. A workable blueprint for setting up the DB2 database security policies

    What security standards should be set for all databases?

    1. A List of access control levels by database
      1. Who needs access and at what level?
      2. Granularity of access control needed
      3. What security access is needed by the following?
        1. Application
        2. Group
        3. User
        4. Database
  5. Who will be responsible for internal user and/or group account setup?
    1. How will user accounts be tracked?
    2. How will terminations and revocations be handled?
    3. How will necessary access changes be conveyed?
  6. What approvals are needed?
    1. What forms are required?
    2. What sign-offs must be in place?
  7. Identification and classification of extremely sensitive information
    1. By database
    2. By application
    3. By table
    4. By column
    5. By row
  8. Identification of overall DB2 security management responsibility
    1. Who is the owner?
    2. Who can delegate?
    3. Who is the custodian?
  9. Uniformity of database policies and any acceptable deviations
  10. Auditing requirements
  11. Incident handling procedures
  12. The review cycle for the formulated database security plan
    1. Are there regulatory requirements for the review cycle?
    2. Should the entire plan be reviewed at once?
    3. Will there be a review after hardware changes?
    4. Will there be a review after software changes?

Meeting Facilitation Tools

When considering an analysis of internal and external database security risks, you can use a grid approach. Table 2.2 shows a basic example.

Table 2.2. Database Security Risk Grid Example




Shared passwords


New password policy.

Disgruntled employees


Review access levels before personnel actions are undertaken.

Users granted inappropriate access to data


Check and review current database grants; create an access control policy.




Introduction of vulnerabilities due to lack of maintenance


Schedule maintenance window for patches.

Hacker attack


Keep current with patches; encrypt sensitive data; change passwords on a regular basis; enforce password standards; undertake vulnerability assessment.

Web users with incorrect access


Check and review current database grants; create an access control policy.

It is likely that this grid (or any other facilitation mechanism used to capture this detail) can grow quite large. It should be viewed as a brainstorming tool to assist in determining the scope of risk. As in the example, it is likely that the items under the Plan column may contain duplications that might occur when one risk can be mitigated by the same action as another risk. An example of this is a risk of external resources and internal resources holding inappropriate access to data. Whereas each presents a different threat to the database and potentially a different level of risk, one action that should be included in the plan for proposed mitigation of both is to review current database access levels and create an enforceable access control policy.

The formation of this grid may assist in identifying the highest-priority items that should be addressed first (even before the plan is completed) and might lead to discovery of threats not currently on the corporate radar. As a first step before tackling the robust work of actually formulating the part of the plan that will serve as a blueprint for the DB2 database security policy, the grid will facilitate an assessment of where the corporation stands now with regard to database security and potentially assist in identification of any serious lapses.

After the assessment of internal and external threats has been completed, the results should be summarized and organized to be used as input for the next steps.

Determining the Authentication Method and User/Password Security

Authentication for DB2 databases is handled by a security facility outside of DB2, such as the operating system, Kerberos, or other plug-in. Although it is not necessary at this point in the process to be specific as to the parameter settings (authentication is discussed in detail in Chapter 5, “Authorization—Authority and Privileges”), the overall authentication requirements should be documented. The discussion should include a determination as to where the authentication should take place (that is, client, server, DB2 connect server, host) and whether encryption (Chapter 7, “Encryption [Cryptography] in DB2”) is required.

Standards should be developed for naming conventions for groups and users. Part of this strategy should be that known default or easily identifiable group names and usernames are not allowed. Some that are commonly used in many DB2 shops (and should therefore be avoided) include the following

  • db2admin
  • db2as
  • db2inst1
  • db2fenc1

Another important discussion regarding groups revolves around the DB2 group known as PUBLIC. DB2 comes with this group by default. This group can (and should) be locked down unless there is some documented reason for this group to maintain certain low-level privileges. Prior to DB2 9, this group always received a number of privileges from the moment the database was created. With DB2 9, an alternative for dealing with the PUBLIC group privileges is made available. When creating a new database, adding the keyword RESTRICTIVE changes the default behavior, and no privileges are automatically granted to the PUBLIC group. If this keyword is not used, the following permissions are available to the PUBLIC group after the database has been created:

  • EXECUTE with GRANT on all procedures in schema SQLJ
  • EXECUTE with GRANT on all functions and procedures in schema SYSPROC
  • BIND on all packages created in the NULLID schema
  • EXECUTE on all packages created in the NULLID schema
  • CREATEIN on schema SQLJ
  • CREATEIN on schema NULLID
  • USE on table space USERSPACE1
  • SELECT access to the SYSIBM catalog tables
  • SELECT access to the SYSCAT catalog views
  • SELECT access to the SYSSTAT catalog views
  • UPDATE access to the SYSSTAT catalog views

As you can see, the privileges for the PUBLIC group on a newly created database are significant. If discussions yield no valid reason for PUBLIC privileges, the RESTRICTIVE clause should be used for newly created databases.

Excellent password security is one of the elements of a strong security plan. In addition to identifying the responsibility for password security enforcement and the mechanisms for change, the following topics should be considered:

  • Changes

    Will users change their own passwords?

    If not, how will they be notified of the changes?

  • Length of time between required resets/changes

    If not reset/changed, how long until lockout of the account?

    How many cycles must be completed before passwords can be reused?

  • Resets

    • Who will hold responsibility for password resets?
    • Will a secondary authentication be used to allow the user to reset it?
      • Secondary authentication question answered correctly
      • Biometric authentication
      • Electronic device such as a key card
  • Lockouts

    How many password attempts before lockout?

    What forms and approvals are to be in place?

    Who will have the authority to retrieve a lost password or credential?

In considering passwords, a discussion of composition standards for those passwords is necessary. The human factor in password issues is well recognized. If your users are allowed to create their own passwords, without any applicable standards, the strength of those passwords will be suspect. If complex passwords that are not easy to remember are instead assigned to users, in variably they will be written down someplace, and that overrides the strength of the complex password.

One approach to this is to create a security password template. This provides the mechanism to ensure that the password meets certain standards, such as three capital letters, two numbers, one symbol, and two lowercase letters. However, this can be problematic. Consider that internal employees will know the template. This information could provide an unintended assist if an internal or former employee wanted to gain access through password hacking.

It is critical that forbidden passwords include usernames, employee IDs, dictionary words (in any language), and true words with numeric replacements of ones or zeros. All these are easily hacked by a brute-force approach.

It’s easy to say that passwords should never be shared, but harder to enforce that standard unless there is some strength behind the security plan, policies, and procedures that can bring consequences to those who violate this essential security foundation. Passwords should also be expired, but this brings up the question “When?” Too-frequent password expiration is problematic because users are tempted to write them down somewhere. A longer time between password changes means a longer exposure period. Changing passwords on a regular interval can be beneficial, but if this actual interval is widely known, this, too, can be a risk. Would you really want a hacker to know that passwords expire on the first Saturday of every other month? Encryption of all passwords is a strong recommendation. DB2 provides easily implemented encryption security features to protect passwords (and more), as discussed in Chapter 7.

As with all security features, knowledge of current industry standards and practices regarding password topics will provide the best guidance. As security evolves, so do the attempts to thwart that security, so keeping current through a proactive approach is wise.

Discussing the Blueprint

Now that you have summarized the results of the internal and external risk assessment for database security and addressed authentication, it is time to begin work on the part of the plan that will eventually be used as a foundation for creating the actual DB2 database security policies. At this point, the team needs to have a good understanding of the internal and external threats that should be addressed to protect the database.

During this phase of the meeting process, the team should begin to discuss the security standards for all corporate DB2 databases. Depending on the structure, complexity, and size of the organization, this can be intricate with multiple considerations per division, per database, per machine, and so on. The goal of this part of the plan is to integrate information discovered in previous steps to facilitate creation of the DB2 database security policies.

At this phase of the process, the team should begin to discuss a workable set of security standards and how they should be applied.

Questions to be answered and topics to be codified in the plan include the following:

  • The ability to uniformly apply database security standards

    Are there needs for differing standards based upon ...?

    • Divisions
    • OS types and levels
    • File system storage versus raw devices
    • Firewall
    • VPN
    • Federated
    • Replication
    • LDAP

    Are there special considerations for specific third-party applications?

    If so, how will these differences be identified and handled?

  • Access control plan

    A statement identifying responsibility and ownership

    • Account/group setup
    • Account tracking
    • Terminations
    • Changes

    Matrixes of access levels needed (see Table 2.3)

    • For authorities
    • For privileges
    • Special

    Identification of necessary maintenance steps

    • Approvals
    • Forms
    • Sign-offs
  • Identification of extremely sensitive information for special consideration

Table 2.3. Database Authorities Matrix

Instance Level

Corporate Tech Arch Group

Corporate DBAs

Division 1 Tech Group

Division 1 DBA Team Lead

Conversion Team

























Database Level

Corporate Tech Arch Group

Corporate DBAs

Division 1 Tech Group

Division 1 DBA Team Lead

Conversion Team







LOAD (with insert privilege)






As mentioned previously, matrixes can aid in identifying access requirements. You can then use these matrixes as input for the DB2 database security policies. The examples in Tables 2.3 and 2.4 consider specific access levels and decode, by group, the level(s) that should be applied. Although the examples represent true discussion points, the values assigned here are for a fictional company, and no special meaning should be ascribed to them.

Table 2.4. Database Privileges Matrix


All Groups

Software Development

Conversion Group

ETL Group

Connect to database






Create new packages






Create tables






Unfenced stored procedures or UDFs






Implicitly define schemas






Connect to database that is in quiesce state






Allow user to create a procedure for use by other applications or users






Definitions and detailed explanations of authorities and privileges are covered in Chapter 5.

You can build similar matrixes to assist in identification of the additional security privileges to be addressed in the DB2 database security policies. These could include the following:

  • Schema

    Create objects within the schema

    Alter objects within the schema

    Drop objects within the schema

  • Tablespace

    Create tables in a specific tablespace

  • Tables and views

    Control of a table or view

    Add columns

    Add or change comments

    Add a primary key

    Add a unique constraint

    Create or drop a table check constraint

    Select, insert, update, and/or delete rows

    Create indexes


    Create and drop foreign keys

  • Packages



    Allow package privileges for others

  • Drop and control on indexes
  • Execute routines
  • Use and alter on sequences
  • Passthru (in a Federated database environment)

Next Steps

Now that the plan has been visualized, it is time to put it to paper. In thinking about what has been covered, it should be obvious that some of the information provided in this living document could be sensitive in nature. It is detailing how your corporation plans to mitigate security risks for the database and, therefore, could provide information to hackers or an internal employee and become an unintended aid for the very risks the plan is meant to address.

Think about the “security” of the database security plan document. It should be protected while it is being written. Leaving parts of it lying around while it is being typed is not appropriate. The persons doing the typing should be trusted employees, too. At a minimum, the electronic copies of the plan should be password protected.

Because of the sensitivity of the information, it is best to disseminate the plan on an “as needed” basis. One possible scenario is to create a security library with all security documentation provided through a signed checkout process. Other steps such as limiting the use of the document to one room that does not have a copier and stamping each page with a highly specific watermark to verify authenticity could provide some measure of further security.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020