064 - 7.1 About the Security Policy and Security Plan


Oracle Security
By William Heney, Marlene Theriault
Table of Contents
Chapter 7.  Developing a Database Security Plan

7.1 About the Security Policy and Security Plan

Why does a company need a security policy and plan? What's the point of having them? A security policy, included within a security plan, helps to ensure that everyone is in sync with the company's needs and requirements. With a firm policy in place, every employee knows what is expected what the rules areand how the requirements are to be implemented. The limits are clearly defined and consistent guidance is provided for everyone. Statements within a security plan can help to ensure that each employee knows the boundaries and what the penalties of overstepping those boundaries will be. For example, here are clear, concise rules employees can easily understand and follow:

  • Always log off the system before going to lunch .

  • Never share a password with anyone else.

  • Never bring software from home to put on your machine at work.

In order to have a truly solid and meaningful policy defined, the highest level of management needs to be committed to ensuring that the security policy will be enforceable. The security policy might state:

  • Any employee leaving a computer unsecured will be formally reprimanded.

  • Any employee found sharing a password will be suspended for one day.

  • Unlicensed software found on a personal computer will be removed and the personal computer user will be shot at sunrise . Survivors will be prosecuted.

Under certain circumstances, the requirement to have and enforce a security policy may come from an agency outside the company. In the case of banks, external agencies control and define what constitutes security for the databases within the bank. The company, however, might decide that even more rigid standards are necessary or that further definitions are required to ensure that no financial transactions become compromised and that confidentiality is maintained. The bank may implement a security plan that further defines exactly how the standards will be implemented, maintained , and audited .

7.1.1 Management Considerations

Once you've determined that a security plan is required for a company, a person or team of people will be needed to begin to define the policy. This chapter assumes a team of people. Who's on the team?

Members of the team might include the person or people who will be administering the system, one or more application owners , and at least one management person who is high enough in the corporate structure to ensure that the policyas writtenwill be enforceable. The system administrator may have a different perspective from the database administrator on what comprises security on a system, but the goals of both should be the sameto ensure that the system cannot be compromised. If the policy is to be in effect across divisions within a company, representatives from each division might be included to ensure "buy-in" across the entire corporate structure. The goal is to include enough people to ensure that all areas of corporate need are met, but to keep the group small enough that the team will be able to create an effective, workable policy. Establishing overall requirements

After the team is assembled , you'll first need to identify the overall requirements of the organization in regard to system and database security. The requirements might include (but are not limited to) the following:

  • A uniform approach to security across computer systems and databases

  • Identification of the form and style of authorization required to initiate the creation of an account

  • A determination of who will create user accounts on the operating system, within each application if necessary, and within the databases

  • How those accounts will be created

  • Whether a standard convention for usernames and passwords should be imposed and what it should be

  • Whether password aging will be enabled and in what time frame

  • A determination of access requirements on an application-by-application basis

  • Identification of how users will be tracked to ensure that as an employee's job description or location changes, the access to applications remains correct

  • Identification of sensitive information and an outline of steps to take for data protection

  • A determination of penalties to be enforced as a result of different levels of security breaches

7.1.2 Operating System Security Mechanisms

In implementing a requirement for a uniform security approach across platforms, you need to take into consideration the native security mechanisms available on each platform. For example, most operating systems require each user who will be interacting with that system to have a unique username and password. Access by a user on a UNIX or OpenVMS system can be further restricted by placing users in specific groups. Group membership might enable a user to interact with specific directories on the system. The security plan could detail each of these requirements.

We don't describe the details of operating system security in this book, but see Appendix A, for references to books and other sources of information.

7.1.3 Identifying Key Components

We recommend that you use a spreadsheet approach to identify the components within your company that the security plan must encompassfor example:

  • Each division within the corporation to be included in the policy

  • Each platform within the division

  • Each database housed on each platform along with its function (development, test, pre-production, or production)

  • Each application supported within each database

  • The "owner" of the application, or person responsible for authorization of users within the application

  • Required security controls for each application, such as roles or grants required

  • Username and password composition

  • Type(s) of accessibility (Telnet, client server, external identification)

  • What form of authorization will be accepted for that application (electronic authorization, verbal, email, hard-copy form, World Wide Web)

  • Person authorized to create accounts for each application

  • Forms of backup to be implemented

  • Recovery procedures to be used

  • Database availability

  • Type of auditing required

  • Who will perform the auditing

  • How auditing will be performed

A possible spreadsheet might look like the one shown in Table 7.1.

Table 7.1. Sample Security Plan Spreadsheet


Database A

Database B

Database C


Windows NT (Div. X)

Digital UNIX (Div. Y)

OpenVMS (Div. Z)

Database/SID Name

larry /lar1

curly /cur2

moe /moe1

Database Function





Accounts Payable

Human Resources

Office Equipment Locations

Application Owner

H. Brown

Personnel Manager

Facilities Manager



First initial/last name

Three letters , two numbers



2 letters, 1 number, 1 punctuation mark, 3 letters (e.g., XX#(!)XXX)

Any combination of letters, numbers, and punctuation, up to 8 total

Access Type

Client Server

Log on to application and application connect to database

Telnet to platform and connect directly to database

Authorization Mode


Paper form signed by head of HR

Phone call

Person to Create Account

Application DBA

HR Security Clerk

Database DBA

Auditing Type

Connections to database

Connections to database

SELECT FROM salary table


Form(s) of Backup

Exports nightly

No archivelog mode

File-level backups weekly

Archivelog mode enabled

Exports nightly

Exports nightly

No archivelog mode

Recovery Procedure

Rebuild database and import

Recover per procedures in the System Recovery Document

Rebuild database and import

Database Availability

Mon-Fri 7:30-18:00

7 days a week, 24 hours a day

Mon-Fri 7:30-18:00


Accounts Payable Manager

HR Security Clerk


Roles Required







Grants Required

CREATE SESSION, SELECT FROM ap tables, INSERT/UPDATE ON ap tables (clerk, manager)

DELETE FROM ap tables (mgr only)

CREATE SESSION, SELECT on specific tables (clerk)

INSERT/UPDATE specific tables (clerk)

SELECT, INSERT, UPDATE, DELETE on all tables (manager)



As you can see from this table, many different security requirements may be present in one environment.


Oracle Security
Oracle Security Handbook : Implement a Sound Security Plan in Your Oracle Environment
ISBN: 0072133252
EAN: 2147483647
Year: 1998
Pages: 154

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net