Security Techniques Across Dbms Computer Science Essay

Published Date: 02 Nov 2017

MSc Project (Jan 2013)

Project Co-ordinator: Dr. Thomas Lancaster

Project Supervisor: Stuart Hutchison

Authored by:

Soumya Radhakrishna (S12764972)

MSc Business Computing

[email protected]

Table of Contents

Aim

The main aim of the research is to explore the different tools and techniques to handle database security and the data integrity across different DBMS (Database Management Systems).

Objectives

To ensure the user security by user id and password management

To assign roles and privileges to users

To create triggers, auditing, tracing and tracking

To manage data integrity constraints

To create profiles and system resource allocation

To investigate and apply vendor-specific security techniques

Project Philosophy

The project is about the comparison of various database tools and techniques used in different DBMS in the market. For the purpose of research, three types of DBMS are considered – Oracle, IBM DB2 and Microsoft SQL Server as they are the most preferred database management systems in the market. These techniques are used to secure the central database system and protect the data from unauthorised access. It involves the security concepts, approaches and using different tools and techniques to ensure the database security. Database administrators (DBAs) setup various user accounts, passwords, and privileges.

Research Methodology

The project includes the analytic stage, synthesis stage and the critical appraisal stage. One key technique for analysis is the literature review which is the systematic review of the current knowledge on the dissertation topic. Observation is also used partly for the research as the project involves programming on the techniques for the database security. As a part of resources for the research, secondary data is used. The resources used are various books (print and ebooks), journals, articles, papers published in conferences and other trusted resources on the internet.

Ethical consideration

The level one ethics self-audit in relation to the proposed project has been completed and no reasonable foreseeable risks are identified (see Appendix – A).

Supervision

The MSc project is carried out under the supervision of Mr. Stuart Hutchison.

Time plan with key deliverables

17/01/2013 – Project Registration

31/01/2013 – Project Proposal

25/04/2013 – Project draft submission

16/05/2013 – Final submission of Project

Support Required

Guidance of Mr. Stuart Hutchison

Library resources

Online resources

Academic Skills Centre

Skills Audit

Scale: 1 to 5, 5 being the maximum

Project planning – 4

Time management – 4

Analytical skills – 3

Problem solving – 4

Communication skills – 4

Structuring and presenting papers – 4

Knowledge retrieval – 4

Learning ability – 4

Introduction

Organisations are using the database systems to maintain daily activities and transactions. In such case, the security of the database becomes the most important issue to be addressed. The database is most vulnerable to be misused and damaged by either external threat or internal threats. According to Bertino and Sandhu (2005),

"Security breaches can be typically categorised as unauthorised data observation, incorrect data modification and data unavailability".

The DBA has to put in maximum efforts for protecting the physical integrity of databases, especially the recordings against sabotage. A simple and basic method to accomplish that is by taking regular backups. The integrity of each and every database element will presume that the value of each field may be built or modified by authorized users only, that too if the input values are correct. The access control is being done taking into consideration the restrictions of the database administrator. DBMS will apply the security policy of the database administrator (DBA) which are to meet the below requirements: (Burtescu, 2008)

Server security. Server security involves limiting access to data stored on the server. It is the most important option that has to be taken in consideration and planned carefully.

Connections to the database. Using the ODBC will have to be followed by checking that each connection corresponds to a single user who has access to data.

Access control table. The access control table is the most common form of securing a database. An appropriate use of the table access control involves a close collaboration between the administrator and the base developer.

Restriction tables. Restriction tables will include lists of unsure subjects who could open set off sessions.

Project Overview

An organisation, while implementing database systems, has to mainly consider the data security. The security factors as stated by Jangra et, al. (2010), are:

Authentication

Authorisation

Encryption

Auditing

Views and Triggers

Privilege management

Authentication

Authentication ensures that only the correct users are connected to the database and to connect, the user has to provide their credentials. Creation of User-id/passwords which will be unique, digital identity of the user, different keys and biometric authentication are some of the measures to be implemented to avoid the authentication problem. Authentication goes into three levels – network, DBMS and operating system.

Oracle supports a strong authentication at levels of network and database. It is also integrated with the authentication services of third party network. Oracle has many authentication tools like internal user authentication, operating system and network authentication tools.

IBM DB2 supports strong authentication at levels of database and operating system and also different third party applications. It supports the policy of secure ID or the leading token which is also referred as hard token. DB2 uses external authentication in which the requests are passed on to the operating system and/or to third party products like IBM’s Tivoli (Jangra et. al, 2010). To support this feature, the DB2 version 8.2 has incorporated open plug-in architecture.

Microsoft SQL Server supports the database authentication through the operating system security. It is very similar to DB2’s implementation. It uses the active directory components which are available in Microsoft admin server. SQL server has a close integration with products supplied by Microsoft for operating system authentication

Authorisation

Once the user is authenticated to the DBMS, the user authorisation assigns the user id with roles based on the data the user can access and the operations performed by the user. The authorisation can be provided to individual user ids or group as a whole. Oracle authorisation is based on users and roles, which can either be local to database or enterprise wide managed with LDAP (Lightweight Directory Access Protocol) compliant server. DB2 provides authorisation to users and groups. Roles which are set of privileges are supported as predefined system roles. In the group authorisation, the users are attached to groups outside the database, into the operating system. In SQL Server, there is a difference between server login and database login ids. The server login and the database login have to be mapped and there are 2-level authorisations – server level login and application level login.

Content and security control can be implemented at 2 different levels – object level and row level. Views are the solution for row level security. They are supported by all types of DBMS. Oracle and DB2 support the views to limit data access. In addition to views, Oracle offers implementation of row-level security with Virtual Private Database (VPD) and Label Security (OLS). VPD enables the implementation of row-level security into the database and the OLS manages labelling of both data and users. This approach assures high performance during run-time security checks. Both Oracle and DB2 have the advantage of RACF (Resource Access Control Facility) in mainframe environment. SQL server supports object level security.

Encryption

Protecting data stored in the database against unauthorised users is enabled for both DB2 and Oracle by data or column encryption. Only Oracle supports tablespace level encryption and SQL server does not support data encryption. Encryption of login role and application role passwords is stored at the server and catalog information, such as view and triggers definitions. DB2 provides column level encryption using this function and enables encryption of all the values in the column with same key called encryption password. Oracle enables encryption within the database and provides four development cycles for data encryption enhancements. SQL Server maintains many open symmetric keys within the database connection. Every encrypted value has the key identifier used for encryption. Encryption can help prevent data loss as well as prevent fraud within an organisation. Key components related to encryption that the security professionals need to understand – data at rest versus data in transit, algorithms and key management. Data encryption takes place at different levels – application encryption, file/disk encryption and database encryption.

Auditing

Auditing is keeping record of user activities in a table of database to track the user activity and to ensure that the user has done the right activities on the stored data. This is done by DBA. Oracle uses the LogMiner utility and it does not drop records even if changes are made to it and is used for recovery of database. It allows the customer to audit the database based on system privileges. Oracle maintains record of all the operations irrespective of whether they are successful or unsuccessful. Oracle has 15 security certificates whereas DB2 and SQL Server have only one certificate each. DB2 uses Tivoli product to enhance the features of auditing like login and access to the resources. There is no competitor for Oracle in terms of auditing as it maintains a compulsory log file to keep track of all entries into database. DB2 because of its plug-in authentication architecture has an advantage over SQL Server.

Views and Triggers

A database view is used to restrict the selection of data from the large amount of records in the tables under consideration. A view is used to display selected database fields or entire table. Views can be sorted to organize the order of records and grouped into sets for the display of records. They have other options such as totals and subtotals. User interaction with the database is carried out using the database views. Properly selected set of views is one of the keys to create a useful database. All views must have a view definition query to tell Oracle which tables, columns and rows are going to make up the new view. Views can be built from other views. The ‘data hiding’ abilities of views provide yet another tool in our security toolkit.

Triggers, as stated by Ullman and Widom (2008), are event-condition-action rules. They differ from the database constraints in three ways stated below

Triggers are activated only when any event already specified in the database occurs. They generally include insert, update or delete to a particular relation

Once the event activates the trigger, it tests a condition. If the condition fails, there will be no response to the event when the trigger occurs

If the condition is satisfied, DBMS performs the action relevant to the trigger. These actions might include enforcing referential integrity, prevent invalid transactions or any other sequence of database operations like gathering statistics on table access.

Privilege Management

A privilege is giving rights for the users to execute an SQL statement or allow the access to another user's object. Two types of privileges are available in DBMS: system privileges and object privileges (BCU Moodle, 2012).

System-level privileges – are general purpose security rights that apply to the user rather than to any one object in the database. Only the database administrator (DBA) or a user with admin-level rights can grant system level privileges. To issue a privilege, GRANT statement is used. For example, a user created in the authentication stage has to be allowed to connect to the database and further create tables.

Object-level privileges – are more specific and focus on a database objects like tables, views, or indexes. In this privilege, the rights can be given by the owner of that object and this strengthens the level of database security. If a privilege to any role is granted as "public", it can be executed by all other users. Also, sysdba cannot be granted as "public".

Initial Literature Review

The DBMS interfaces with application programs, and the data stored in the database is used by several applications and different users pertaining to these applications. The database system allows these users to access and manipulate the data contained in the database in a suitable and efficient manner. Every organization chooses the database management system according to their need and requirement.

The most important concern for any company is to ensure the security of its databases which is indeed a complex issue. The security measures tend to be complex depending on the complexity of the databases. Security measures form an integral part of database even from the initial phase which includes the inception as well as the design phase. Modern techniques used to monitor the security of databases manage the security and protection fortifications at different levels: host, physical, applications, network and data (Jangra et. al, 2010).

Accroding to Pernul (1994), database security is concerned with ensuring the secrecy, integrity, and availability of data stored in a database. secrecy must deal with the possibility that information may also be disclosed by legitimated users acting as an ‘information channel’ by passing secret information to unauthorized users. This may be done intentionally or without knowledge of the authorized user. Integrity requires data to be protected from malicious or accidental modification, including the insertion of false data, the contamination of data, and the destruction of data. Integrity constraints are rules that define the correct states of a database and thus can protect the correctness of the database during operation.

Appendices

Appendix – A: Level One Ethical Review Form

1. Potential physical or psychological harm, discomfort or stress

(a) Is there a significant foreseeable potential for psychological harm or stress? NO

(b) Is there a significant foreseeable potential for physical harm or discomfort? NO

(c) Is there a significant foreseeable risk to the researcher? NO

2. Protection of research subject confidentiality

Are there any issues of confidentiality which are not adequately addressed by the following actions:

(a) Non-attribution of individual responses;

(b) Individuals and organisations to be anonymised in publications and presentations;

(c) Specific agreements have been made with respondents regarding any feedback to collaborators and relating to any publications. NO

3. Data protection and consent

Are there any issues of data handling and consent which are not dealt with by established procedures? This would entail ensuring:

(a) Compliance with the Data Protection Act with reference to safe/secure storage of data and its management on completion of the project.

(b) That respondents have giving consent regarding the collection of personal data by completing a Consent Form.

(c) That there are no special issues arising concerning confidentiality/informed consent. NO

4. Moral issues and Researcher/Institutional Conflicts of Interest

Are there any special moral issues and/or conflicts of interest identified? NO

(a) An example of conflict of interest would be the researcher compromising research objectivity or independence in return for financial or non-financial benefit for him/herself or for a relative or friend.

(b) Particular moral issues or concerns could arise, for example, where the purposes of research are concealed, where respondents are unable to provide informed consent, or where research findings would impinge negatively/differentially upon the interests of participants.

5. Vulnerable participants

Are any of the participants or interviewees in the research vulnerable, e.g. children and young people? NO

6. Bringing the University into disrepute

Is there any aspect of the proposed research which might bring the University into disrepute? NO

Overall assessment

The self audit has been conducted and confirms the absence of ethical risks which can be reasonably foreseen. Hence there is no need for the second level form of ethical review form.