DB2 Security—The Starting Point

This chapter is from the book

Understanding DB2 9 Security

Learn More Buy

This chapter is from the book

This chapter is from the book 

Understanding DB2 9 Security

Learn More Buy

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

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

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:

• CREATETAB
• BINDADD
• CONNECT
• IMPLSCHEMA
• 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

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

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

  Export

  Create and drop foreign keys

• Packages

  Rebind

  Execute

  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.