Database security planning, policy, and access control requirements

Database Security

The focus of this study is that of database security. Databases and database technology are such that play critical roles in the use of computers whether it be in business, electronic commerce, engineering, medicine, genetics, law, education or other such entities requiring the use of computer technology. A database is quite simply a collection of data that is related such as a database containing customer information, supplier information, employee information, project databases, and the sort. Some databases are small while others are of a great size and quite complex. A database management system is "a general purpose software system that facilitates the processes of defining, constructing, manipulating, and sharing databases among various users and applications." (Oracle Security, 1998, p.1) Defining a database is reported to involve "specifying the data types, structures and constraints of the data to be stored in the database." (Oracle Security, 1998, p.1)

I. Database Security Plan

Securing the database system and its data requires several steps and the first step is the development of a security policy outlining and mapping the security plan enforcement. The security policy, contained within a security plan, assist with ensuring that everyone understands the needs and requirement of the company. A security policy that is firm ensures that employees understand what is expected, what the rules to using the system are, and how implementation of the requirements takes place. Limitations are defined clearly and guidance is consistent and set out for each user of the system.

II. Security Policy

The security policy must be enforceable and management at the highest level must be committed to enforcing the security policy. After it is determined what is required for the company security plan a-team of individuals should be formed. The team will be formed by those who will administer the system. The system administrator and the database administrator should have the same goals, which are ensuring the system is unable to be compromised.

III. Database Security Requirements

Following the team being assembled there is a need to conduct identification of the requirements of the organization relating to the system and database security. Requirements are likely to 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. (Oracle Security, 1998, p.1)

IV. Operating System Security

Operating system security mechanisms requires considering the native security mechanisms that may be used on each platform since most operating systems make a requirement that each user interacting with the system to have a username and password that is unique. User access on a UNIX or Open VMS system is likely to be under a requirement of a username and password that is unique as well. In addition there may be an additional restriction since users are likely to be divided into specific user groups. The groups are divided based upon what directories the group will be using on the system all of which is specified in the security plan. (Oracle Security, 1998, paraphrased)

A spreadsheet approach should be used in identifying the components that the security plan covers. Examples stated include the following:

(1) Each division within the corporation to be included in the policy

(2) Each platform within the division

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

(4) Each application supported within each database

(5) The "owner" of the application, or person responsible for authorization of users within the application

(6) Required security controls for each application, such as roles or grants required

(7) Username and password composition

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

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

(10) Person authorized to create accounts for each application

(11) Forms of backup to be implemented

(12) Recovery procedures to be used

(13) Database availability

(14) Type of auditing required

(15) Who will perform the auditing

(16) How auditing will be performed (Oracle Security, 1998, p.1)

V. User Accounts

Users connect to the database through use of user accounts of which there are several including operating system and database accounts:

(1) Although they are created with the CREATE USER command, some accounts are used to house application schemas. These accounts own objects like tables, views, indexes, triggers, procedures, etc.

(2) Another type of account is used by the system itself to enable the database engine work to be performed; these accounts are sys and system.

(3) In later versions of the RDBMS, an account to enable the intelligent agent to connect to each database is automatically created during database creation. This account is dbsnmp and carries full DBA privileges.

(4) Each application might need one or more accounts to enable work to be performed.

(5) Each user in your system may require an individual account with specific privileges to enable the user to work with an application.

(6) One or more accounts may be needed to enable one or more DBAs to perform database maintenance and duties.

(7) Each account type must be considered and a decision reached on whether that account type will be used and how it will be set up and administered. In smaller organizations, there may be little need for some types of accounts discussed in this section. In very large organizations, there may be a need for more extensive divisions of database account types. (Oracle Security, 1998, p.1)

VI. Database Administration

One of the account types is the database administration account. Smaller companies have only one person acting as the system administrator and network administration while larger companies are likely to have several individuals in this capacity. A decision has to be made as to who will have the access to the code area for installation and maintenance of the company software. One or more accounts must be established for the varied tasks of administration of the account including privilege sets for operating system and database privileges to perform the required tasks. (Oracle Security, 1998, paraphrased)

VII. Auditing

Auditing of the database is used for tracking database access and activity of users. Auditing is used for identification of who has accessed objects on the database and what actions were taken and notes any data that has been changed. However, it is important to understand that auditing of the database does not actually prevent security breaches but does make available a means of identifying whether breaches have occurred. Common categories of auditing for a database include the following:

(1) Monitoring database access attempts,

(2) Data Control Language (DCL) activities

(3) Data Definition Language (DDL) activities, and (4) Data Manipulation Language (DML) activities (Yang, 2009 cited in: Murray, 2010)

According to the work of Murray (2010) monitoring access attempts includes "retaining information on successful and unsuccessful logon and logoff attempts. DCL audits record changes to user and role privileges, user additions, and user deletions. DDL audits record changes to the database schema such as changes to table structure or attribute data types. DML audits record changes to data. In addition, database errors should be monitored." (Yang, 2009 cited in Murray, 2010)

Murray (2010) reports that database auditing is "…implemented via log files and audit tables. The challenge of database auditing is deciding what and how much data to retain and how long to keep it. Several options exist. A basic audit trail usually captures user access, system resources used, and changes made to the structure of a database. More complete auditing captures data reads as well as data modifications." According to Murray (2010) auditing "plays a central role in a comprehensive database security plan. The primary weakness of the audit process is the time delay between when data is recorded and when analysis is performed. Consequently, breaches and other unauthorized activities are identified after the fact, making it difficult to mitigate adverse effects in a timely manner. However, solutions are being introduced that allow for real-time monitoring of database activity looking for patterned events indicative of potential breaches and enacting real-time notification to database administrators when such actions occur." (Murray, 2010)

VIII. Database Security Best Practices

Database security best practices are reported to include the need to separate the database and web servers. The database should reside on a separate database server "located behind a firewall, not in the DMZ with the web server." (Applicure Technologies Ltd., 2012) Stored files should be encrypted since it is estimated by WhiteHat that "83% of all web sites are vulnerable to at least one form of attack. The stored files of a web application often contain information about the databases the software needs to connect to. This information, if stored in plain text like many default installations do, provides the keys an attacker needs to access sensitive data." (Applicure Technologies Ltd., 2012) In addition, it is important to encrypt back-up files since "Not all data theft happens as a result of an outside attack. Sometimes, it's the people we trust most that are the attackers." (Applicure Technologies Ltd., 2012) Web-application firewalls are important to use since a misconception that exists is that "protecting the web server has nothing to do with the database. Nothing could be further from the truth. In addition to protecting a site against cross-site scripting vulnerabilities and web site vandalism, a good application firewall can thwart SQL injection attacks as well. By preventing the injection of SQL queries by an attacker, the firewall can help keep sensitive information stored in the database away from prying eyes." (Applicure Technologies Ltd., 2012) It is also necessary to keep patches current since this is reported as "one area where administrators often come up short. Web sites that are rich with third-party applications, widgets, components and various other plug-ins and add-ons can easily find themselves a target to an exploit that should have been patched." (Applicure Technologies Ltd., 2012) Third-party applications should be minimized. As well the use of a shared web server should be avoided if the database stores sensitive information.

Summary and Conclusion

This study has examined database security. This study has informed the reader that a database security plan and database security policy set out the expectations of who will be using what aspects of the system's applications and directories. User access permissions must be set up along with group access permissions depending on what level of access each individual user and user group will need to perform their tasks. This is an approach that must be uniform in nature with various decision made on rules and penalties for access and unauthorized access respectively. Operating system security has been address in this study and an approach stated for setting out operating system security requirements. Security breaches have been addressed in this study as well as have the need for auditing of the system's security breaches. Finally, best practices for database security have been examined.