by Rebecca Bond, Kevin Yeung-Kuen See, Carmen Ka Man Wong, Yuk-Kuen Henry Chan
First Words—What's the Plan?
When thinking about organizational information security, your mind might jump to the technical details such as firewalls, access control lists, certificates, auditing, encryption, and all those well-known electronic trappings that present a mental vision of a secure architecture. In fact, if you review the security implementations for most organizations, you will indeed see all those things.
Did you ever wonder how those physical and logical layers of security ever started out? I did, and what I found out may surprise you. Despite all the electronic gadgetry, despite the fact that these environments were created by information technologists, despite this being the electronic age, despite the "paperless" society, the best security implementations ... the ones that still stand up to the test of time ... began as a written security plan on good, old-fashioned paper!
If you're seeking to emulate what other companies have shown to be successful, first you need to have a plan, and then you need to stick to it. That does not mean that you should create the security plan and never modify it, but it does mean that this plan should be solid enough to guide formulation of your organization's day-to-day database security policies.
In today's lightning-speed development and production environments, slowing down long enough to actually create a plan may appear to be an unaffordable luxury. Consider, however, that this plan does not need to be an impediment to progress, but rather an empowering document, facilitating the time and commitment of resources that must be dedicated to the security initiative.
If you happen to be a DBA, that written database security plan can be a lifesaver, both on initial database setup and as an ongoing reminder of the symbiotic relationship between the database and the security of the organization's information assets. It should give you guidance both before and after a database has been launched. It will be an important guide as you formulate your DB2 database policies. It must be an active document, referred to for guidance on a regular basis and updated as change arises. For the corporation's sake, the database security plan should not suffer the fate of so many others and become yet another a dusty binder stored on the top of someone's filing cabinet.
Perhaps, one of the most important benefits to be gained from creating a database security plan is that the very act of committing the plan to writing will assist in identifying potential security risks that might not be uncovered in a benign way otherwise. If security is not on the corporate conscious, the true threat is masked by all the tasks and energies required just to keep day-to-day operations or development going. Working on any security plan funnels the combined thoughts of the organization into one readable whole and presents in a clearer fashion the ways to address and mitigate those threats.
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
Technical team leads
Application subject matter experts (SMEs)
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.
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
- Connectivity mechanisms in use
- Current authentication methods
Operating system information
- 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
- 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
List of applications
- Application "owners"
- Prior risk assessments
- Information on known data classification
Special security considerations
High Availability Cluster Multi-Procesing (HACMP™)
- Results and recommendations of any security audits that have been performed