Database Journal
MS SQL Oracle DB2 Access MySQL PostgreSQL Sybase PHP SQL Etc SQL Scripts & Samples Links Database Forum

» Database Journal Home
» Database Articles
» Database Tutorials
MS SQL
Oracle
DB2
MS Access
MySQL
» RESOURCES
Database Tools
SQL Scripts & Samples
Links
» Database Forum
» Sitemap
Free Newsletters:
DatabaseDaily  
News Via RSS Feed


follow us on Twitter
Database Journal |DBA Support |SQLCourse |SQLCourse2
 

Featured Database Articles

DB2

Posted Jan 23, 2007

DB2 Security�The Starting Point - Page 2

By DatabaseJournal.com Staff

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

Internal

Threat

Plan

Shared passwords

High

New password policy.

Disgruntled employees

Medium

Review access levels before personnel actions are undertaken.

Users granted inappropriate access to data

Medium

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

External

Threat

Plan

Introduction of vulnerabilities due to lack of maintenance

High

Schedule maintenance window for patches.

Hacker attack

High

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

Web users with incorrect access

High

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:

  • 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, invariably 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

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.3 Database Authorities Matrix

Instance Level

Corporate Tech Arch Group

Corporate DBAs

Division 1 Tech Group

Division 1 DBA Team Lead

Conversion Team

SYSADM

Y

N

N

N

N

SYSCTRL

N

Y

N

Y

N

SYSMAINT

N

Y

Y

Y

N

SYSMON

N

N

N

Y

N

DBADM

N

Y

Y

Y

N

LOAD (with insert privilege)

N

N

N

N

Y

Table 2.4 Database Privileges Matrix

 

Public

All Groups

Software Development

Conversion Group

ETL Group

Connect to database

N

Y

Y

Y

Y

Create new packages

N

N

Y

Y

Y

Create tables

N

N

N

Y

N

Unfenced stored procedures or UDFs

N

N

N

N

Y

Implicitly define schemas

N

N

N

N

N

Connect to database that is in quiesce state

N

N

N

N

Y

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

N

N

Y

Y

Y

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.



DB2 Archives

Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 



















Thanks for your registration, follow us on our social networks to keep up-to-date