DB2 Security—The Starting Point(3)

DB2 Database Security—Create the Policy

DBAs are notoriously overworked. They are an integral part of the day-to-day database management work and serve as the technological wheels of the corporate vehicle. Given their usual desire to stay "hands-on" and the significant tasks that they face, DBAs seldom have the time or inclination for writing documentation. When security is not a priority, database security policies, if they are documented at all, are often vague and will likely suffer from poor implementation. Given the considerable security risks imposed by ad-hoc policies and spotty enforcement, committing the policies to writing and implementing them consistently and successfully is critical. 字串7

Although a trial-and-error learning approach might work in some database areas, database security is not one of them. It is critical that the DBA who is tasked with creating and implementing the policies understands, and can intelligently implement, all aspects of the DB2 security policies. Auditing is another area that requires a robust comprehension of DB2. For these reasons, the database security policies should not be created or implemented until the DBA has a true comprehension of the available DB2 security options. 字串4

Using the Plan to Formulate the Policy

If the DB2 database security plan is complete, the creation of the DB2 database security policies will be much easier. Yes, it is true that a database security policy can be put in place even though a database security plan was never created. However, creating only the policy without first laying the foundation of the plan leaves the database policy vulnerable. For example, there might not be a corporate sponsor to favor the necessary work effort, organizational "buy-in" would be missing, and database security efforts would not benefit from the strength of different perspectives.

字串2

That said, if it just is not possible to get a team together and officially write a database security plan, at least writing the database security policy is the next best choice. Plan or no plan, the DB2 database security policies should be written down, not just implemented.

字串9

Review, Approve, Implement, Maintain

Before sitting down to translate the information from the plan into workable database security policies, a structure should be in place to determine what reviews, approvals, auditing, and policy maintenance are needed. The goal here is to strengthen the process, not impede it.

If the corporation has a technology security officer or group, that group should be part of the review, approval, and maintenance process. If no individual or group holds this authority, the CIO or CTO and/or DB2 team lead should be involved. Rather than have numerous levels of authority involved, the objective is to find the smallest common denominator of personnel with the appropriate level of authority and the ability to do the following: 字串7

• Review the policies 字串8

  Do they match the objectives of the plan?

  字串8

  Are the proposed policies able to be implemented as they are described?

  字串6

  Are the appropriate parties tasked with implementing the policies? 字串1

  Are safeguards built in?

  字串9

  Is the policy clearly written?

  字串2

  Has change management been addressed? 字串7

• Approve 字串2

  Who has the authority to approve the policies? 字串7

  Are multiple levels of approval desirable? 字串7

• Implement 字串3

  Identification of personnel to implement

  字串2

  Verification of successful implementation 字串2

  Appropriate change management 字串7

• Audit 字串7

  Validation 字串9

  Quality assurance

  字串6

• Maintain

  字串5

  What is the schedule for cyclical review of the policies? 字串3

  Who will maintain the physical security of the policies? 字串4

  Who will be allowed access to the policies?

  字串4

  How will be policy itself be distributed and secured? 字串9

  How will changes be managed?

  字串1

General Guidelines—Building the DB2 Database Security Policies

When beginning to create a new DB2 database security policy, a good suggestion is to have a master document that supports all the standards and single or various subdocuments to address the exceptions or differences. This approach may ease regulatory compliance efforts because uniformity across environments will aid auditors as they review for compliance.

字串3

One direction would be to create a master DB2 database security policy that covers all corporate instances and databases by stating the general, shared policy rules. Then, any exceptions or differences could be detailed separately and incorporated into the policy documents. The master document might contain items such as the standards and naming conventions for instances and databases or how TCP/IP port numbers for instances are assigned. These are just examples to provide "thought points" for the task of creating the policies. As long as the written policies provide sufficient scope and clarity, the actual form that the final documentation takes is not significant. 字串4

One major point to consider is how to keep the policies themselves secure. The security plan and policies and their working documents, if made available inappropriately, present a security threat to the organization. If the policies are stored on a network that does not provide sufficient security, for example, they might be compromised and used as a blueprint to devise ways to circumvent all the protections so diligently implemented. Likewise, copies of the security policies or their drafts, left lying on desktops, can be acquired improperly. Keeping the plan and policies secure is just as important as keeping the data itself from falling into the wrong hands. 字串7

What to Include?

The determination of what to include and exclude in the database security policies varies greatly depending on the organizational need. Common to most organizations are items such as naming standards, database-to-storage mappings, application-to-database mappings, and access controls. Beyond those topics, larger organizations typically need to include auditing and encryption, especially if they are under regulatory review.

These topics are discussed in general terms here to give some insight on an approach to creating the policies. These topics are indented only to provide a starting point to initiate the process. The successful database security policy at your organization will be unique and a "custom fit" that cannot be easily facilitated by a generic blueprint.

Naming Standards

The most important considerations for creating naming standards are that

字串3

1. They exist.
2. They are not overly complex.
3. They are well documented.
4. They are not so transparent as to aid a hacker.
5. They are enforceable and enforced.

Organizations without naming standards cause undue stress for DBAs whether in relation to security or not. It is so much easier, for example, to troubleshoot any security issues with stored procedures if the DBA knows that all stored procedures begin with the prefix SX_ and that they all are stored on a specific file system. If objects suddenly appear to be stored procedures, but do not begin with SX_ and are not on the appropriate file system, the irregularity is more easily discovered if standards are in place and if enforcement has been strict.

字串7

Mappings

While database, application, and storage mappings exist in most organizations as an aid to administration, the implicit security benefit is not always realized. Mappings can prove invaluable to facilitate identification of irregularities (whether accidental or intentional). If a recovery is required for any reason, you can use mappings to confirm that the environment is restored to the original configuration. Mappings for applications, databases, and storage should be included in the database security policies.

字串9

Access Controls

DB2 offers a rich complement of features that can provide a high level of granularity for enabling access controls. Because a thorough understanding of DB2 access control mechanisms is critical to a secure implementation, these topics are covered in depth in Chapter 5, and Chapter 6, "Label Based Access Control." 字串8

Once determined, access control mechanisms should be thoroughly documented in the database security policies. The goal should be a standardization of implementation that can be followed by anyone tasked with the work. The policy should spell out not only the initial implementation, but how to handle subsequent implementations.

Auditing

Another item for inclusion in the database security policies is auditing. (See Chapter 9, "Database Auditing and Intrusion Detection," for a detailed discussion.) As you read in Chapter 1, "The Regulatory Environment," auditing is a requirement for compliance mentioned by HIPAA, Sarbanes-Oxley, and Gramm-Leach-Bliley Acts. Many governmental agencies require an almost 100 percent auditing implementation. If auditing is required, whether natively in DB2 or by some other mechanism, this, too, should be detailed by the database security policies.

字串5

The broad topics regarding auditing that the policy should (at a minimum) include are as follows:

• What is audited?
• How often will audit records be reviewed?

• What personnel will be tasked with audit review?

  字串3

  How will they be vetted or authorized? 字串3

  What technical skills will they need for the tasks?

  字串1

  Who will they report to?

  字串6

• What storage media will be used and how will it be secured?
• How long do audit records need to be kept?
• What is the issue discovery reporting process?

Auditing might not be required for every database environment in the enterprise, but to the extent that it is, it should be well documented in the database security policies.

Encryption

If your organization is planning to use encryption, the database security policies should address how to determine which data is to be encrypted. It is more important to set standards for encryption rather than just list specifically what is initially encrypted. If the policy states, for example, that Table A, Column B must be encrypted, that provides instruction only for one situation. The policy should go further, setting standards that apply across all data, such as the following:

• All names
• All Social Security numbers
• All dates of birth
• All personnel actions
• User IDs and passwords
• Credit card numbers
• Etc.

Spelling out this information in the policies is necessary because few applications stay static. As new code is introduced and new database objects are created, the database policies can aid in providing a consistency point for encryption. If the requirement is that all SSNs be encrypted, for example, and the policy only states, "Encrypt all Social Security numbers in the Employee table," what happens when another table is added that also holds Social Security numbers? With standards such as "All SSNs are encrypted," there is more assurance that the policy will be effective.

Change Control—Things Are Gonna Change

Throughout this chapter, we have been dealing with the "present" as if the "future" were never going to impact the process. Now it is time to realize that the future is not going to be ignored forever.

It is highly likely that after the plan has been completed (or maybe before), after the policies have been "inked," and after that secure database is in place, there will be changes. With any security implementation, there are always ways to improve, which translates into "change." Then, there are the business changes that occur as a matter of routine for most enterprises. They also spell "change." We cannot forget, too, that technology will advance, hackers will hack, businesses will acquire businesses, best practices will evolve, and employees will move on. To manage the change that is virtually guaranteed in any thriving enterprise, change control is essential. This is not just change control for the database (although that is essential), but also change control for the security architecture and its relevant documentation. At each step along the way, consider how change is going to be managed. 字串4

Last Words

If you do not have executive sponsorship for your secure implementation, stop here and get it now. Without executive sponsorship, the odds of success are slim.

字串2

Security plans and database security policies are essential to creating and maintaining a robust security implementation. They must be effectively written, shared with appropriate personnel, updated when appropriate, and protected just as if they were classified data. They serve as documentation for auditors, management, and appropriate staff and will provide foundational guidance for DBAs and IT departments.

Of course, every organization is different, and the security plan and database security policy must be tailored for the specific organizational need instead of striving to meet some arbitrary set of requirements. That is why the involvement of the appropriate personnel at the start of the creation process is crucial. These stakeholders should play an active role in the formulation of the plan, and from the plan, it should be easier for the DBAs to formulate the DB2 database security policies.

字串1

Taking shortcuts by eliminating documentation introduces significant risk. Even if database security is effectively implemented, when documentation is bypassed, it is increasingly likely that normal changes, which inevitably take place as the application changes, will cause security items to be overlooked. With a security plan and DB2 database security policies, this unintentional oversight is less likely. 字串1

© Copyright Pearson Education. All rights reserved.

Copyright disclaimer:

字串8

“This chapter represents an excerpt from the new book titled, “Understanding DB2 9 Security”, authored by Bond/See/Wong/Chan. Copyright 2007 by International Business Machines Corporation. All rights reserved. ISBN 0131345907. Published by IBM Press in December, 2006. For further information, please visit: www.ibmpressbooks.com.”

字串7