Chapter 3

Chapter 3
Database Management Systems Security

™ Database Security refers to the collective measures used to protect and secure a database
management software from illegitimate use and malicious threats and attacks. It is a broad
domain term that includes a multitude of processes tools and methodologies that ensure
security within a database environment.
™ Database Security is the process of protecting the data from the malicious data. For
example: Adding Birr in your bank accounts.

Importance of Data:
9 Bank Accounts
9 Credit card/debit card, Salary, Income Tax data.
9 University Admission (Ministry of Education), Marks/Grades.
9 Licenses
9 Medical Records
9 Data = Crown jewels for organizations
If the data has these kinds of importance, definitely they might be a chance of hackers to intrude.

In the News (a Small Sample):

Recent Headlines:
™ July 2014: Chinese hackers break into US federal Employee Database.
™ March 2014: Ebay Account information’s were breached.
™ April 2011: Major Data breach at sony.
™ Sep 2016: 57 millions of Uber users data hacked also 600,000 drivers data exposed.
™ Presently Facebook data were breached by Cambridge Analytica Organization.

Database Security Overview

All organizations public, governmental or private, small or large |depend on computerized information
systems for carrying out their daily activity. At the heart of each such information system, there is a
database. At a very general level, we can define a database as a persistent collection of related data,
where data are facts that have an implicit meaning. For instance, an employee's name, social security
number, or date of birth are all facts that can be recorded in a database.

Typically, a database is built to store logically interrelated data representing some aspects of the real
world, which must be collected, processed, and made accessible to a given user population. The database
is constructed according to a data model which denies the way in which data and interrelationships
between them can be represented. The collection of software programs that provide the functionalities for
defining, maintaining, and accessing data stored in a database is called a database management system
(DBMS).

Database technologies are a core component of many computing systems. They allow data to be retained
and shared electronically and the amount of data contained in these systems continues to grow at an
exponential rate. So does the need to insure the integrity of the data and secure the data from unintended
1                              Compiled by: Dr. Azath Hussain 
Chapter 3

access. The Privacy Rights Clearing House (2010) reports that more than 345 million customer records
have been lost or stolen since 2005 when they began tracking data breach incidents, and the Ponemon
Institute reports the average cost of a data breach has risen to $202 per customer record (Ponemon, 2009).
In August 2009, criminal indictments were handed down in the United States to three perpetrators
accused of carrying out the single largest data security breach recorded to date. These hackers allegedly
stole over 130 million credit and debit card numbers by exploiting a well known database vulnerability, a
SQL injection ( Phifer , 2010).

Some of the differences between databases and operating systems that make it necessary for a DBMS to
support security features are as follows.

™ Protection level: A DBMS usually needs to protect data at a fine granularity level (e.g., a record
of a file), while an operating system protects data at the file level.
™ Object differences: There is a greater variety of object types in a DBMS than in an operating
system. The typical object type in an operating system is a file; in a DBMS there can be relations
(tables), tuples (rows within a table), attributes (columns within a table), indexes, metadata, and
others.
™ Data interrelationships: A database may include many logical objects with complex semantic
interrelationships that must be protected. By contrast, the number of physical objects that the
operating system protects is less and no semantic interrelationships are supported.
™ Dynamic versus static objects: Data objects in a DBMS can be obtained by dynamically
aggregating data from different physical objects in an operating system. By contrast, files tend to
be more static making their protection easier.
™ Lifetime of data: The lifetime and frequency of access of data in a DBMS is quite different than
the lifetime of data stored as files in an operating system.
™ User views of data While in an operating system, users are either granted or denied access to data
(files), in a DBMS it is possible to give access to a portion of an object by defining different
views for different users.

Database Security Requirements:

Security Requirements
The basic security requirements of database systems are not unlike those of other computing systems we
have studied. The basic problems access control, exclusion of spurious data, authentication of users, and
reliability have appeared in many contexts so far in this book.

Following is a list of requirements for database security.

™ Physical database integrity. The data of a database are immune to physical problems, such as
power failures, and someone can reconstruct the database if it is destroyed through a catastrophe.
™ Logical database integrity. The structure of the database is preserved. With logical integrity of a
database, a modification to the value of one field does not affect other fields, for example.
™ Element integrity. The data contained in each element are accurate.
™ Audit ability. It is possible to track who or what has accessed (or modified) the elements in the
database.

2                              Compiled by: Dr. Azath Hussain 

Chapter 3

™ Access control. A user is allowed to access only authorized data, and different users can be
restricted to different modes of access (such as read or write).
™ User authentication. Every user is positively identified, both for the audit trail and for permission
to access certain data.
™ Availability. Users can access the database in general and all the data for which they are
authorized.

Database Security

Layers Upon Layers

Physical Level Security using DB Encryption

Example: What if a Laptop/disk/USB key with critical data is lost from your office/Hotel room?
Partial Solution: Encrypt the database at storage level, transparent to application.
™ Column Encryption [actually for securing the sensitive information’s like credit card/debit
card.

3                              Compiled by: Dr. Azath Hussain 

Chapter 3

Database Encryption
™ Standard practice how to encrypts credit card information and other sensitive information.
o Its not just a good idea, it’s the law in United States of America.
o HIPAA -Health Insurance Portability and Accountability Act (Encryption of
sensitive medical data].

Security at the Database\Application Program

™ Authentication & Authorization mechanisms to allow specific users access only to
required data.
o Authentication: Who are You? Prove it.
o Authorization: What you are allowed to do!.
™ Authorization:
o Screen level authorization [login information].
o Authorization at the database Layers consist of:
ƒ Read Authorization
ƒ Insert Authorization
ƒ Update Authorization
ƒ Delete Authorization.

Authorization in SQL
SQL Language has extensive set of features for authorization.
™ Privileges, Objects, Users, Roles.
™ Grant of Specific Privileges( read, write, insert….) on specific objects to specific
users/roles.
o Grant Select on Employee to Manager.
™ Objects: Relations, Views, Stored Procedure etc.
™ Grant of roles to users
o Grant Manager to Shimulus.

Application Program Security

™ Database won’t create problems, unless application software creates the problems.
™ Application programs often a major source of insecurity.
™ Poor coding of application may allow unauthorized access.
o Eg: SQL Injection.
o Missing Authorized Checks (Students tried to misuse the website before the results got
published, its illegal authorization).
™ Application code may be very big, easy to make mistakes and leave security holes.
o Eg: Database Security workshop at IIT Bombay, india (2003).
ƒ Careless coding was exposed by the student, database password to outside world.

4                              Compiled by: Dr. Azath Hussain 

Chapter 3

SQL Injection Attacks

Example: Web form
Username:
Password:
™ Example query for badly written application creates query text.
o Query = ‘Select userinfo from Users where’ + ‘userid=’ +Username+’and
password=’+’Password’;
o Malicious User types Username
XYZ’‐‐
9 -- deletes rest of the text (Password check).
9 Malicious User gets information without supplying correct password!
9 Proper Programming style will avoid this problem, but many programmers make these
mistakes.

SQL Injection Attacks Evidences

™ The Great Cyberheist (New York times, 14 Nov 2010).
o SQL Injection attack was used to attack credit card company computers.
™ Sony Attack April 2011:
o The group said the attack was carried out SQL injection, “one of the most primitive &
common vulnerabilities, as we should all know by now. “From a single injection we
accessed everything …..” the group said in a statement.

Integrity of the Database

Integrity of the database as a whole is the responsibility of the DBMS, the operating system, and the
(human) computing system manager. From the perspective of the operating system and the computing
system manager, databases and DBMSs are files and programs, respectively. Therefore, one way of
protecting the database as a whole is to regularly back up all files on the system. These periodic backups
can be adequate controls against catastrophic failure.

Database Integrity
Databases amalgamate data from many sources, and users expect a DBMS to provide access to the data
in a reliable way. When software engineers say that software has reliability, they mean that the software
runs for very long periods of time without failing. Users certainly expect a DBMS to be reliable, since the
data usually are key to business or organizational needs. Moreover, users entrust their data to a DBMS
and rightly expect it to protect the data from loss or damage. Concerns for reliability and integrity are
general security issues, but they are more apparent with databases.

Database concerns about reliability and integrity can be viewed from three dimensions:

™ Database integrity: concern that the database as a whole is protected against damage, as from the
failure of a disk drive or the corruption of the master database index. These concerns are
addressed by operating system integrity controls and recovery procedures.
™ Element integrity: concern that the value of a specific data element is written or changed only by
authorized users. Proper access controls protect a database from corruption by unauthorized users.
5                              Compiled by: Dr. Azath Hussain 
Chapter 3

™ Element accuracy: concern that only correct values are written into the elements of a database.
Checks on the values of elements can help prevent insertion of improper values. Also, constraint
conditions can detect incorrect values.

Two-Phase Update
A serious problem for a database manager is the failure of the computing system in the middle of
modifying data. If the data item to be modified was a long field, half of the field might show the new
value, while the other half would contain the old. Even if errors of this type were spotted easily (which
they are not), a more subtle problem occurs when several fields are updated and no single field appears to
be in obvious error. The solution to this problem, proposed first by Lampson and Sturgis [LAM76] and
adopted by most DBMSs, uses a two-phase update.

Update Technique
During the first phase, called the intent phase, the DBMS gathers the resources it needs to perform the
update. It may gather data, create dummy records, open files, lock out other users, and calculate final
answers; in short, it does everything to prepare for the update, but it makes no changes to the database.
The first phase is repeatable an unlimited number of times because it takes no permanent action. If the
system fails during execution of the first phase, no harm is done because all these steps can be restarted
and repeated after the system resumes processing.

The last event of the first phase, called committing, involves the writing of a commit flag to the database.
The commit flag means that the DBMS has passed the point of no return: After committing, the DBMS
begins making permanent changes. The second phase makes the permanent changes. During the second
phase, no actions from before the commit can be repeated, but the update activities of phase two can also
be repeated as often as needed. If the system fails during the second phase, the database may contain
incomplete data, but the system can repair these data by performing all activities of the second phase.
After the second phase has been completed, the database is again complete.

Two-Phase Update Example

Suppose a database contains an inventory of a company's office supplies. The company's central
stockroom stores paper, pens, paper clips, and the like, and the different departments requisition items as
they need them. The company buys in bulk to obtain the best prices. Each department has a budget for
office supplies, so there is a charging mechanism by which the cost of supplies is recovered from the
department. Also, the central stockroom monitors quantities of supplies on hand so as to order new
supplies when the stock becomes low.

6                              Compiled by: Dr. Azath Hussain 

Chapter 3

Suppose the process begins with a requisition from the accounting department for 50 boxes of paper
clips. Assume that there are 107 boxes in stock and a new order is placed if the quantity in stock ever
falls below 100. Here are the steps followed after the stockroom receives the requisition.
1. The stockroom checks the database to determine that 50 boxes of paper clips are on hand. If not, the
requisition is rejected and the transaction is finished.
2. If enough paper clips are in stock, the stockroom deducts 50 from the inventory figure in the database
(107 - 50 = 57).
3. The stockroom charges accounting's supplies budget (also in the database) for 50 boxes of paper clips.
4. The stockroom checks its remaining quantity on hand (57) to determine whether the remaining
quantity is below the reorder point. Because it is, a notice to order more paper clips is generated, and the
item is flagged as "on order" in the database.
5. A delivery order is prepared, enabling 50 boxes of paper clips to be sent to accounting.

All five of these steps must be completed in the order listed for the database to be accurate and for the
transaction to be processed correctly. Suppose a failure occurs while these steps are being processed. If
the failure occurs before step 1 is complete, there is no harm because the entire transaction can be
restarted. However, during steps 2, 3, and 4, changes are made to elements in the database. If a failure
occurs then, the values in the database are inconsistent. Worse, the transaction cannot be reprocessed
because a requisition would be deducted twice, or a department would be charged twice, or two delivery
orders would be prepared.
When a two-phase commit is used, shadow values are maintained for key data points. A shadow data
value is computed and stored locally during the intent phase, and it is copied to the actual database during
the commit phase. The operations on the database would be performed as follows for a two-phase
commit.

Intent:
1. Check the value of COMMIT-FLAG in the database. If it is set, this phase cannot be performed. Halt
or loop, checking COMMIT-FLAG until it is not set.
2. Compare number of boxes of paper clips on hand to number requisitioned; if more are requisitioned
than are on hand, halt.
3. Compute TCLIPS = ONHAND - REQUISITION.
4. Obtain BUDGET, the current supplies budget remaining for accounting department. Compute
TBUDGET = BUDGET - COST, where COST is the cost of 50 boxes of clips.
5. Check whether TCLIPS is below reorder point; if so, set TREORDER = TRUE; else set TREORDER
= FALSE.

Commit:
1. Set COMMIT-FLAG in database.
2. Copy TCLIPS to CLIPS in database.
3. Copy TBUDGET to BUDGET in database.
4. Copy TREORDER to REORDER in database.
5. Prepare notice to deliver paper clips to accounting department. Indicate transaction completed in log.
6. Unset COMMIT-FLAG.

7                              Compiled by: Dr. Azath Hussain 

Chapter 3

Sensitive data
There are several reasons why data are sensitive:
™ Inherently sensitive (location of missiles).
™ From a sensitive source (an informer’s identity may be compromised).
™ Declared sensitive (military classification, anonymous donour).
™ Part of a sensitive record/attribute
™ Sensitive in relation to previously disclosed information (longitude plus latitude).

Inference Control
Inference is a way to infer or derive sensitive data from non- sensitive data. The inference problem is a
subtle vulnerability in database security.
INFERENCE means deriving sensitive data from non-sensitive data.

Statistical inference attacks

™ Direct attack
o finding sensitive information directly with queries that yield only a few records.
™ Indirect attacks seeks to infer the final result based on a number of intermediate statistical
results.
o sum
o count
o median
o tracker attack: means finding sensitive information by using additional queries that each
produce a small result

Basic controls for statistical inference attacks

In general there are three types of controls:
™ query restriction (suppression)
o reject query without response (data withheld).
™ perturbation (data or output) (concealing)
o provide an inexact answer to the query.
™ Query analysis, i.e. track what the user knows.
8                              Compiled by: Dr. Azath Hussain 
Chapter 3

o keeping track on previous queries (query history).

o maintain a record for each user of earlier queries.
o this method is extremely costly.

Protecting against inference in Statistical DB’s

Multilevel Security (MLS) Databases

Multi-level secure database management system (MLS-DBMS) security requirements are defined in
terms of the view of the database presented to users with different authorizations. These security
requirements are intended to be consistent with DOD secure computing system requirements. An
informal security policy for a multi-level secure database management system is outlined, and
mechanisms are introduced that support the policy. Security constraints are the mechanism for defining
classification rules, and query modification is the mechanism for implementing the classification policy.
These mechanisms ensure that responses to users’ queries can be assigned classifications which will
make them observable to the querying users.

9                              Compiled by: Dr. Azath Hussain 

Chapter 3

MLS- DBMS Security Requirements

A multi-level secure database management system (MLS-DBMS) is different from a conventional
DBMS in at least three ways: (1) every data item in the database has associated with it one of several
classifications or sensitivities, that may change dynamically; (2) control of users’ access to data must be
based upon these classifications; and (3) the classification based access controls cannot be avoided or
subverted, that is, they are mandatory.

In such a multi-level secure database system, the critical factor which distinguishes one user from another
is that each is authorized to access only particular sub-sets of the data within the DBMS. An MLS-
DBMS addresses the rather natural expectation that users at different levels should be able to use the
same database, with each seeing only that data for which s/he has appropriate authorization and users
with different authorizations sharing some data.

Although there have been several attempts at designing a general purpose MLS-DBMS, the problems
encountered in designing and building such a system are quite difficult, and have not yet been overcome.
It is only recently and with considerable difficulty that the simpler case, that of providing multi-level
security for operating systems and for their associated resources, has been solved. Such a multi-level
computing system is generally referred to as a trusted computer base (TCB) within the computer security
community. The TCB generally controls the access of user processes to system resources, at the file or
device granularity, according to security classification levels.

Confidentiality
™ Depending on a user's clearance, he/she might get different answers for a query.
o Less precision for low-clearance users.
™ Existence of a record itself could be confidential.
™ Keeping existence hidden can lead to having multiple records with the same primary key, but
different sensitivity (polyinstantiation).
o Admin notices that there is no record for employee Bob Hill and creates one.
o However, Bob Hill is a secret agent, so there already is a record, which admin cannot see.
o DBMS must allow admin's request, else admin would get suspicious.

Partitioning
™ Have separate database for each classification level.
™ Simple, often used in practice.
™ Might lead to data stored redundantly in multiple databases.
o Doesn't address the problem of a high-level user needing access to low-level data
combined with high-level data

10                              Compiled by: Dr. Azath Hussain 

Chapter 3

Encryption
™ Separate data by encrypting it with a key unique its classification level.
™ Must be careful to use encryption scheme in the right way.
o E.g., encrypting the same value in different records with the same key should lead to
different ciphertexts.
™ Processing of a query becomes expensive, many records might have to be decrypted.
o Doing the processing directly on the encrypted data is an active research area
(homomorphic encryption).
Integrity lock
™ Provides both integrity and access control.
™ Each data item consists of
o The actual data item.
o An integrity level (maybe concealed).
o A cryptographic signature (or MAC) covering the above plus the item's attribute name and
its record number.
™ Signature protects against attacks on the above fields, such as attacks trying to modify the
sensitivity label, and attacks trying to move/copy the item in the database.
™ This scheme does not protect against replay attacks
™ Any (untrusted) database can be used to store data items and their integrity locks.
o Locks can consume lots of space (maybe multiple locks per record).
™ (Trusted) procedure handles access control and manages integrity locks.
o E.g., updates integrity level to enforce *-property or re-computes signature after a write
access.
o Expensive.
™ Have to encrypt items and locks if there are other ways to get access to data in database.
o Makes query processing even more expensive.
**********************************************************************************

11                              Compiled by: Dr. Azath Hussain