Database Security

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) VI.

Security Breaches Security breaches are a growing problem and since more databases are made accessible through the Internet and web-based applications the exposure of the databases to security threats will continue to grow. The objective is to "reduce susceptibility to these threats." (Murray, 2010) The most publicized database application vulnerability is the SQL injection. SQL injections are reported to make provision of "excellent examples for discussing database security issues, risks inherent to non-validated user input. The threat occurs when users enter malicious code that 'tricks' the database into executing unintended commands.

The vulnerability occurs primarily because of the features of the SQL language that allow such things as embedding comments using double hyphens (- -), concatenating SQL statements separated by semicolons, and the ability to query metadata from database data dictionaries. The solution to stopping an SQL injection is input validation." (Murray, 2010) It is reported that SQL injection vulnerabilities are a result of the "dynamic creation of SQL queries in application programs that access a database system.

The SQL queries are built incorporating user input and passed to the database system as a string variable. SQL injections can be prevented by validating user input. Three approaches are commonly used to address query string validation: using a black list, using a white list, or implementing parameterized queries. The black list parses the input string comparing each character to a predefined list of non-allowed characters. The disadvantage to using a black list is that many special characters can be legitimate but will be rejected using this approach.

The common example is the use of the apostrophe in a last name such as O'Hare." (Murray, 2010) The white list approach is stated to be similar "except that each character is compared to a list of allowable characters. The approach is preferred but special considerations have to be made when validating the single quote. Parameterized queries use internally defined parameters to fill in a previously prepared SQL statement. The importance of input validation cannot be overstated.

It is one of the primary defense mechanisms for preventing database vulnerabilities including SQL injections." ( ) It is reported that a subtle vulnerability found within database technologies is "inference, or the ability to derive unknown information based in retrieved information." (Murray, 2010) The problem stated with inference is that no ideal solution exists to the problem and the only solution recommended includes the controls "related to queries (suppression) or controls related to individual items in a query." (Murray, 2010) Sensitive data a query requests is not provided or the answer provided are close but not exact and the user is prevented from acquiring enough information to make inferences.

Therefore, neither solution is ideal due to their restrictive nature. 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.