DATABASE SECURITY ISSUES
I. INTRODUCTION.
Database security concerned with ensuring the secrecy, integrity, and availability
of data stored in a database. Secrecy requires that data be protected from unauthorized
disclosure, including indirect disclosure via inference. Integrity requires that data be
protected from unauthorized or erroneous modification, including insertion of false data,
data contamination and destruction of data, all of which leave a database in an invalid
or inconsistent state.
Availability requires that data be available to authorized users at the time of
need. Threats to data integrity affect availability since a user may have to wait for lost or
corrupted data to be recovered or reconstructed from back-up files. Availability is also
threatened by denial-of-service attacks, where an attacker monopolizes system
resources in such a way that other users cannot get needed service.
The secrecy, integrity, and availability requirements of a system are defined by a
security policy, which is then enforced by various security mechanisms. A system is
considered to be secured if it correctly enforces its policy.
Statement of the Problem
1. What are the security measures implemented?
2. Authorized accessed on database systems.
3. What are the procedures on implementing the database systems?
4.Testing procedures on databases?
5. What is inference in databases?
1
II. WHAT AUTHOR SAY.
Database Security by Dorothy E. Denning
The security policy for a database system may have several components:
- A discretionary access policy control, which specifies what users are authorized
perform what operations on what data, and the rules whereby users can, at their
discretion, grant and revoke their authorizations to other users.
- A mandatory access control policy, which specifies the rules whereby users can
obtain direct or indirect access to classified data, and the rules for sanitizing and
reclassifying data. These policies apply only to multilevel databases. which are
databases that contain information of different classifications.
Database Security and Controls by Ravi S. Sandhu and Sushil Jajodia
Secrecy, Integrity and Availability
The objective of data security can be divided into three separate, but interrelated, areas
as follows.
Secrecy is concerned with improper disclosure of information. The terms confidentiality
or non-disclosure are synonyms for secrecy.
Integrity is concerned with improper modification of information or processes.
Availability is concerned with improper denial of access to information. The term denial
of service is also used as a synonym for availability.
These three objectives arise in practically every information system.
For example, in a payroll system secrecy is concerned with preventing an employee
from finding out the boss's salary. Integrity is concerned with preventing an employee
from changing his or her salary; and availability is concerned with ensuring that the
paychecks are printed on time as required by law. Similarly, in a military command and
control system.
Secrecy is concerned with preventing the enemy from determining the target
coordinates of a missile. Integrity is concerned with preventing the enemy from altering
2
the target coordinates and availability is concerned with ensuring that the missile does
get launched when the order is given.
Any system will have these three requirements co-existing to some degree.
There are of course differences regarding the relative importance of these objectives in
a given system. The commercial and military sectors both have similar needs for high
integrity systems. The secrecy and availability requirements of the military are often
more stringent than in typical commercial applications.
These three objectives also differ with respect to our understanding of the
objectives themselves and of the technology to achieve them. It is easiest to understand
the objective of secrecy. Integrity is a less tangible objective on which experts in the
field have diverse opinions. Availability is technically the least understood aspect. In
terms of technology, the dominance of the commercial sector in the marketplace has led
vendors to emphasize mechanisms for integrity rather than for military-like secrecy
needs. The availability objective is so poorly understood that no product today even
tries to address it directly.
Security Policy
Security policy is to elaborate the three generic security objectives of
secrecy, integrity and availability, in the context of a particular system. The generic
objectives have all used the term "improper" in their definition. A statement of security
policy largely consists of defining what is the meaning of "improper" for a particular
system.
The meaning of "improper" is sometimes mandated by law, such as for secrecy
in the classified military and government sectors. Legal and professional requirements
apply to medical records and other sensitive personal information about individuals.
Due to conflict of interest considerations so-called Chinese Walls are required to
prevent business consultants from accessing confidential information for two or more
companies competing in the same market sector. In general, however, security policy is
largely determined within an organization rather than imposed by mandate from outside.
This is particularly so in the integrity and availability arenas. understood that no product
today even tries to address it directly.
Prevention, Detection and Tolerance
The objective of data security can be approached in two distinct, and mutually
supportive, ways.
3
Prevention ensures that security breaches cannot occur. The basic technique is
that the system examines every action and checks its conformance with the security
policy before allowing it to occur. This technique is called access control.
Detection ensures that sufficient history of the activity in the system is recorded
in an audit trail, so that a security breach can be detected after the fact. This technique
is called auditing.
Every system employs some mix of these two techniques. Sometimes the
distinction between these two techniques gets blurred. For example, consider a system
which monitors the audit trail in real time looking for imminent security violations so as
to prevent them. Such a system is preventive in nature, yet the technology used is
basically a detective one. The distinction is nevertheless a useful one. Our focus in this
chapter is on preventive techniques.
Prevention is the more fundamental technique. An effective detection mechanism
requires a mechanism to prevent improper modification of the audit trail. Moreover,
detection is ultimately useful only to the extent that it prevents improper activity by
threatening punitive action.
Finally, there is the third "technique" of tolerance in which the potential for some
security breaches is tolerated; because either these breaches are too expensive to
prevent or detect, or the likelihood of their occurrence is considered sufficiently low, or
security measures are acceptable to users only up to some reasonable point. Every
practical system tolerates some degree of risk with respect to potential security
breaches. It is, however, important to understand what risk is being tolerated and what
is being covered by preventive/detective mechanisms.
Assurance
Security mechanisms, whether preventive or detective in nature, can be
implemented with various degrees of assurance. Assurance is directly related to the
effort required to subvert the mechanism. Low assurance mechanisms are easy to
implement but also relatively easy to subvert. Subtle bugs in system and/or application
software have led to numerous security breaches. On the other hand, high assurance
mechanisms are notoriously difficult to implement. They also tend to sure from
degraded performance. Fortunately, rapid advances in hardware performance are
making the performance penalty acceptable.
4
Access Controls in Current Systems
The access controls provided in the current generation of commercially available
Database Management Systems. Our focus is on relational systems. The access
controls described here are often referred to as discretionary access controls as
opposed to the mandatory access controls of multilevel security.
The purpose of access controls is to ensure that a user is only permitted to
perform those operations on the database for which that user is authorized. Access
controls are based on the premise that the user has been correctly identified to the
system by some authentication procedure. Authentication typically requires the user to
supply his or her claimed identity (e.g., user name, operator number, etc.) along with a
password or some other authentication token. Authentication may be performed by the
Operating System, the Database Management System, a special Authentication Server,
or some combination thereof.
Granularity and Modes of Access Control
Access controls can be imposed at various degrees of granularity in a system. Some
possibilities are enumerated below.
- The entire database.
- Some collection of relations.
- One relation.
- Some columns of one relation.
- Some rows of one relation.
- Some columns of some rows of one relation.
Data Dependent Access Control
Database access controls are often data dependent. For example, some users
may be limited to seeing salaries which are less than $30,000. Similarly, a manager
may be restricted to seeing salaries for employees in his department. We now discuss
two basic techniques, viz., view-based access controls and query modification, for
implementing data-dependent access controls in relational databases.
View based access control - A base relation is a "real" relation in the database, that is it
is actually stored in the Database. A view is a "virtual" relation which is derived from
base relations and other views. The database stores the view definitions and
materializes the view as needed.
Query Modification - is another technique for enforcing data-dependent access controls
for retrieval. In this technique, a query submitted by a user is modified to include
further restrictions as determined by the user's authorization.
5
Granting and revocation allow users to selectively and dynamically grant privileges to
other users, and subsequently revoke them if so desired.
Multilevel Security Requirements
The focus of multilevel security is on secrecy, and this section reflects this focus.
The granting of access is under user control. Users who possess a privilege with the
grant option are free to grant it to whomever they choose to. We first show that this
approach has serious limitations with respect to secrecy requirements. We then
describe how mandatory access controls get around this limitation. Next we introduce
the covert channel problem which even mandatory controls are unable to solve. Finally,
we briefly discuss the evaluation criteria for secure computer systems developed by the
U.S. Department of Defense. It should be noted that although multilevel security has
been developed primarily for the military sector, it is applicable in the commercial sector
also.
Mandatory access controls are based on security labels associated with each
data item and each user. A label on a data item is called a security classification, while
a label on a user is called a security clearance. In a computer system every program
run by a user inherits the user's security clearance. In other words the user's clearance
applies not only to the user as a human being, but also to every program executed by
that user. It is important to understand that a particular program, such as a text editor,
when executed by a Secret user is run as a Secret process; whereas when it is
executed by an Unclassified user it is run as an Unclassified process. Moreover, the
classifications and clearances once assigned cannot be changed (except by the
security officer).
Security labels in the military and government sectors consist of two
components: a hierarchical component and a (possibly empty) set of categories. The
hierarchical component consists of the following, listed in decreasing order of sensitivity.
- Top secret (TS)
- Secret (S)
- Confidential (C)
- Unclassified (U)
The categories consist of items such as NUCLEAR, CONVENTIONAL, NAVY,
ARMY, NATO, etc. The label X is said to dominate label Y provided the hierarchical
component of X is greater than or equal to the hierarchical component of Y, and the
categories of X contain all the categories of Y.
For example:
- X = (TOP-SECRET, {NUCLEAR, ARMY}) dominates Y = (SECRET, {ARMY})
- X = (SECRET, {NUCLEAR, ARMY}) dominates Y = (SECRET, {NUCLEAR})
- X = (TOP-SECRET, {NUCLEAR}) is incomparable to Y = (SECRET, {ARMY}),
i.e., neither one dominates the other.
6
Note that two labels which dominate each other are exactly identical.
Commercial organizations also use similar labels for protecting sensitive
information. The main difference is that procedures for assigning clearances to users
are much less formal than in the military or government sectors. We will henceforth limit
ourselves to hierarchical labels, i.e., labels without any categories. The reader is
cautioned that there are many subtle issues which arise due to incomparable labels
(i.e., labels with categories). However, the basic concepts can be demonstrated with
hierarchical labels. We usually use the labels Secret and Unclassified in our discussion.
When a user signs on (i.e., logs in) to the system he or she specifies the security
level of that session. The level of the session must be dominated by the user's
clearance. That is, a Secret user can sign on as Unclassified, but an unclassified user
cannot sign on as Secret. Once the user is signed on at a specific level all programs
executed by him or her will be run at that level.
The following rules for mandatory access control were formulated by Bell and LaPadula.
- Simple Security: A subject (i.e., a running program) with label X can read an object
(i.e., a data item) with label Y only if X dominates Y.
- Star-Property: A subject with label X can write an object with label Y only if Y
dominates X.
For example, a Secret subject can read Secret and Unclassified data, but cannot
write Unclassified data. So even with Trojan Horses in the software, it is not possible to
copy information from Secret data items to unclassified data items.
The simple-security requirement applies equally to humans and programs. The
star-property on the other hand is not applied to the human users, but rather to
programs. Human users are trusted not to leak information. A Secret user can write an
unclassified document, because it is assumed that he or she will only put unclassified
information in it. Programs, on the other hand, are not trusted because they may have
Trojan Horses embedded in them. A program running at the Secret level is therefore not
allowed to write to unclassified data items.
Covert Channels
Unfortunately, mandatory controls do not solve the Trojan Horse problem
completely. A program running at the Secret level is prevented from writing directly to
Unclassified data item. There are, however, other ways of communicating information to
Unclassified programs.
Unfortunately, mandatory controls do not solve the Trojan Horse problem
completely. A program running at the Secret level is prevented from writing directly to
7
Unclassified data item. There are, however, other ways of communicating information to
Unclassified programs.
For example, the Secret program can acquire large amounts of memory in the
system. This fact can be detected by an Unclassified program which is able to observe
how much memory is available. Even if the Unclassified program is prevented from
directly observing the amount of free memory, it can do so indirectly by making a
request for a large amount of memory itself. Granting or denial of this request will
convey some information about free memory to the Unclassified program. Such indirect
methods of communication are called covert channels. Covert channels present a
formidable problem for multilevel security. They are difficult to detect, and once detected
are difficult to close without incurring significant performance penalties. Covert channels
do tend to be noisy due to interference by the activity of other users in the system.
Nevertheless, standard coding techniques for communication on noisy channels can be
employed by the Trojan Horses to achieve error-free communication, with data rates
which can be as high as several million bits per second.
Evaluation Criteria
In 1985 the U.S. Department of Defense published the Trusted Computer
System Evaluation Criteria, popularly known as the Orange Book. This document
established a metric against which computers systems can be evaluated for security.
The metric consists of a number of levels, A1, B3, B2, B1, C2, C1, and D; listed here in
decreasing order of how secure the system is.
For each level, the Orange Book lists a set of requirements that a system must
have to achieve that level of security. Briefly, the D level consists of all systems which
are not secure enough to qualify for any of A, B, or C levels. Systems at levels C1 and
C2 provide discretionary protection of data, systems at level B1 provide mandatory
access controls, and systems at levels B2 or above provide increasing assurance, in
particular against covert channels. The level A1, which is most rigorous, requires
verified protection of data.
In 1991 the U.S. Department of Defense published the Trusted Database
Interpretation of the Trusted Computer System Evaluation Criteria, popularly known as
the TDI. The TDI describes how a DBMS and the underlying OS can be evaluated
separately and in conjunction. Several efforts are underway to build secure DBMS
products satisfying these criteria.
8
Inference and Aggregation
Even in multilevel secure DBMSs, it is possible for users to draw inferences from
the information they obtain from the database. The inference could be derived purely
from the data obtained from the database system, or it could additionally depend on
some prior knowledge which was obtained by users from outside the database system.
An inference presents a security breach if more highly classified information can be
inferred from less classified information.
There is a significant difference between the inference and covert channel
problems. Inference is a unilateral activity, in which an Unclassified user legitimately
accesses Unclassified information from which that user is able to deduce Secret
information. Covert channels, on the other hand, require cooperation of a Secret Trojan
Horse which transmits information to an Unclassified user by indirect means of
communication. The inference problem will exist even in an ideal system which is
completely free of covert channels.
There are many difficulties associated with determining when more highly
classified information can be inferred from less classified information. The biggest
problem is that it is impossible to determine precisely what a user knows. The inference
problem is somewhat manageable if we adopt the closed-world assumption and
assume that if information Y can be derived using information X, then both X and Y are
contained in the database. In reality, however, the outside knowledge that users bring
plays a significant role in inference.
There are two important cases of the inference problem, which often arise in
database systems.
- An aggregation problem occurs whenever there is a collection of data items that is
classified at a higher level than the levels of individual data items by themselves. A
classic example from a military context occurs when the location of individual ships is
unclassified, but the aggregate information concerning the location of all ships in the
fleet is secret. Similarly, in the commercial sector the individual sales figures for branch
offices might be considered less sensitive than the aggregate sales figures for the entire
company.
- A data association problem occurs whenever two values seen together are classified
at a higher level than the classification of either value individually. As an example, the
list consisting of the names of all employees and the list containing all employee
salaries are unclassified, while a combined list giving employee names with their
salaries is classified.
9
Notice that the data association problem is different from the aggregation problem since
what is really sensitive is not the aggregate of the two lists, but the exact association
giving an employee name and his or her salary.
We now describe some techniques for resolving the inference problem. Although
these methods can be extremely useful, a complete and generally applicable solution to
the inference problem remains an elusive goal.
Appropriate Labeling
If Unclassified information x permits disclosure of Secret information y, one way
to prevent this is to reclassify all or part of information x such that it is no longer possible
to derive y from the disclosed subset of x. To illustrate, suppose that an attribute A is
Unclassified while attribute B is Secret. Suppose the database enforces the constraint
A + B < 20, and that the constraint is known to Unclassified users. The value of B does
not affect the value of A directly, but it does constrain the set of possible values A can
take. Thus we have an inference problem. This inference can be prevented by
reclassifying A as Secret.
Query Restriction
Many inference violations arise as a result of a query which returns data at the
user's level, but its evaluation requires accessing data above the user's level.
Polyinstantiation is another technique that can be used to prevent inference
violations. To illustrate, suppose an Unclassified user wants to enter a row in a relation
in which each row is labeled as S (Secret) or U (Unclassified). If the same key is already
occurring in an S row, we cannot prevent the Unclassified from inserting the U row
without leakage of 1 bit of information by inference. In other words the classification of
the row has to be treated as part of the relation key. Thus U rows and S rows will
always have different keys, since the keys will have different security classes.
Auditing can be used to control inferences. For instance, a history can be kept of
all queries made by a user. Whenever the user makes a query, the history is analyzed
to determine whether the response to this query, correlated with the responses to earlier
queries, could result in an inference violation. If a violation could arise, the systems can
take appropriate action (for example, abort the query).
There is a side benefit of this approach: it may deter many inference attacks by
threatening discovery of violations. There are two disadvantages of this approach: One,
it may be too cumbersome to be useful in practical situation. Two, it can detect very
limited types of inferences (since it is based on the hypothesis that a violation can
always be detected by analyzing the audit records for abnormal behavior.)
10
Tolerating Limited Inferences
Tolerance methods are useful in those cases in which the inference bandwidth is
so small that these violations do not pose any threat. Consider the following example.
Suppose that data are classified at the column level, and that we have two relations,
one called PD with the Unclassified attribute PLANE and Secret attribute
DESTINATION, and another called DF with the Unclassified attribute DESTINATION
and Unclassified attribute FUEL-NEEDED. Suppose also that, although knowledge of
the fuel needed for a particular plane can give information about the destination of the
plane, there are too many destinations requiring the same amount of fuel for this to be a
serious inference threat. Moreover, we do not want to go to the trouble of clearing
everybody responsible for fueling the plane to the Secret level. Thus we wish to make
the derived relation with attributes PLANE and FUEL-NEEDED available to Unclassified
users.
Even though we have decided that this information does not provide a serious inference
threat, we cannot allow Unclassified users to extract the required information from PD
and PF by, say, executing the following query.
SELECT PLANE, FUEL-NEEDED
FROM PD, DF
WHERE PD.DESTINATION = DF.DESTINATION
Doing so opens up a covert channel for leaking Secret information to Unclassified
users.
One solution is to use the snapshot approach, where a trusted user creates a
derived Secret relation with attributes PLANE and FUEL-NEEDED and then
downgrades it to Unclassified. Although this "snapshot" cannot be updated
automatically without opening a covert channel, it can be kept more or less up-to-date
by having the trusted user re-create it from time to time.
A "snapshot" or a "sanitized file" is an important technique for controlling
inferences, especially in offline, static databases. In particular, it has been used quite
effectively by the United States Bureau of the Census.
Integrity Principles and Mechanisms
In this section we discuss the problem of data integrity. Integrity is a much less
tangible objective than secrecy. Our approach to integrity is pragmatic and utilitarian.
We define integrity as being concerned with the improper modification of information
(much as confidentiality is concerned with improper disclosure). We understand
modification to include insertion of new information, deletion of existing information as
well as changes to existing information.
11
The reader may have seen similar definitions of integrity using "unauthorized"
instead of "improper." Our use of the latter term is significant and should not be
dismissed lightly. Integrity breaches can and do occur without authorization violations.
In other words authorization is only one piece of the solution and we must also deal with
the malicious user who exercises his or her authority improperly.
The Insider Threat
It is important to understand that the threat posed by a corrupt authorized user is quite
different in the context of integrity as compared to secrecy.
A corrupt user can leak secrets by using the computer to legitimately access
confidential information, and then passing on this information to an improper destination
by some non-computer means of communication (e.g., a telephone call). It is simply
impossible for the computer to know whether or not step was followed by step. We
therefore have no choice but to trust our insiders to be honest and alert. The military
and government sectors have established elaborate procedures for this purpose, while
the commercial sector is much more informal in this respect. Security research which
focuses on secrecy therefore considers the principal threat to be Trojan Horses
embedded in programs. That is, the focus is on corrupt programs rather than corrupt
users.
Analogously, a corrupt user can compromise integrity by manipulating stored
data, or falsifying source or output documents. A computer system can do little by itself
to solve the problem of false source or output documents, for which we must rely on the
traditional techniques of paper-based manual systems. However, the manipulation of
stored data simply cannot be done without use of the computer. In principle, the
computer system is in a position to detect or prevent such manipulation. Integrity must
therefore focus on the corrupt user as the principal problem. In fact the Trojan Horse
problem can itself be viewed as a problem of corrupt system or application
programmers, who improperly modify the software under their control. Also note that the
problem of the corrupt user remains even if we are willing to trust all our software to be
free of Trojan Horses.
12
Integrity Principles
In this section we identify basic principles for achieving data integrity. Principles
lay down broad goals without specifying how to achieve them. We will map these
principles to DBMS mechanisms. Principles lay out what needs to be done while
mechanisms establish how these principles are to be achieved.
Seven integrity principles are enumerated below.
1.
Well-formed Transactions. The concept of the well-formed transaction is that
users should not manipulate data arbitrarily, but only in restricted ways that
preserve integrity of the database.
2.
Least Privilege. Programs and users should be given the least privilege
necessary to accomplish their task.
3.
Separation of Duties. Separation of duties is a time honored principle for
prevention of fraud and errors, going back to the very beginning of commerce.
Simply stated, no single individual should be in a position to misappropriate
assets on his own. Operationally this means that a chain of events which affects
the balance of assets must require different individuals to be involved at key
points, so that without their collusion the overall chain cannot take effect.
4.
Reconstruction of Events. This principle seeks to deter improper behavior by
threatening its discovery. The ability to reconstruct what happened in a system
stems from the notion of accountability. Users are accountable for their actions to
the extent that it is possible to determine what they did.
5.
Delegation of Authority. This principle concerns the critical issue of how
privileges are acquired and distributed in an organization. Clearly the procedures
to do so must reflect the structure of the organization and allow for effective
delegation of authority.
6.
Reality Checks. Cross-checks with external reality are an essential part of
integrity control. For example, if an internal inventory record does not correctly
reflect the number of items in the warehouse, it makes little difference if the value
of the recorded inventory is being correctly recorded in the balance sheet.
7.
Continuity of Operation. This principle states that system operations should be
maintained to some appropriate degree in the face of potentially devastating
events which are beyond the organization's control. This catch-all description is
intended to include natural disasters, power outages, disk crashes and the like.
With this principle we are clearly stepping into the scope of availability. We have
mentioned it here for the sake of completeness.
13
Well-formed Transactions
The concept of a well-formed transaction corresponds very well to the standard
DBMS concept of a transaction. A transaction is defined as a sequence of primitive
actions which satisfies the following properties.

Correct state transform: each transaction if run by itself in isolation and given a
consistent state to begin with will leave the database in a consistent state.

Serializability: the net effect of executing a set of transactions is equivalent to
executing them in some sequential order, even though they may actually be
executed concurrently (i.e., their actions are interleaved or simultaneous).

Failure atomicity: either all or none of the updates of a transaction take effect.
(We understand update to mean modification, i.e., it includes insertion of new
data, deletion of existing data and changes to existing data.)

Progress: every transaction will eventually complete, i.e., there is no indefinite
blocking due to deadlock and no indefinite restarts due to livelocks.
The basic requirement is that the DBMS must ensure that updates are restricted to
transactions. Clearly, if users are allowed to bypass transactions and directly
manipulate relations in a database, we have no foundation to build upon. In other words
updates should be encapsulated within transactions. This restriction may seem too
strong, because in practice there will always be a need to perform ad hoc updates.
However, ad hoc updates can themselves be carried out by means of special
transactions! Of course the authorization for these special ad hoc transactions should
be carefully controlled and their usage properly audited.
DBMS mechanisms can help in assuring the correctness of a state by enforcing
consistency constraints on the data. Consistency constraints are also often called
integrity constraints or integrity rules in the database literature. Since we are using
integrity in a wider sense we prefer the former term.
The relational data model in particular imposes two consistency constraints.

Entity integrity stipulates that attributes in the primary key of a relation cannot
have NULL values. This amounts to requiring that each entity represented in the
database must be uniquely identifiable.

Referential integrity is concerned with references from one entity to another. A
foreign key is a set of attributes in one relation whose values are required to
match those of the primary key of some specific relation. Referential integrity
requires that a foreign key either be all NULL or a matching tuple exist in the
latter relation. This amounts to ruling out dangling references to non-existent
entities.
14
Entity integrity is easily enforced. Referential integrity on the other hand requires more
effort and has seen limited support in commercial products. The precise manner in
which to achieve it is also very dependent on the semantics of the application. This is
particularly so when the referenced tuple is deleted. There are several choices as
follows: prohibit this delete operation, delete the referencing tuple (with a possibility of
further cascading deletes), or set the foreign key attributes in the referencing tuple to
NULL.
The relational model in addition encourages the use of domain constraints
whereby the values in a particular attribute (column) are constrained to come from some
given set. These constraints are particularly easy to state and enforce, at least so long
as the domains are defined in terms of primitive types such as integers, decimal
numbers and character strings. A variety of dependency constraints which constrain the
tuples in a given relation have been extensively studied in the database literature.
In the limit a consistency constraint can be viewed as an arbitrary predicate
which all correct states of the database must satisfy. The predicate may involve any
number of relations. Although this concept is theoretically appealing and flexible in its
expressive power, in practice the overhead in checking the predicates for every
transaction has been prohibitive. As a result relational DBMS's typically confine their
enforcement of consistency constraints to domain constraints and entity integrity.
Least Privilege
The principle of least privilege translates into a requirement for refine-grained
access control. For purpose of controlling read access DBMSs have employed
mechanisms
Separation of Duties
Separation of duties finds little support in existing products. Although it is
possible to use existing mechanisms for this purpose, these mechanisms have not been
designed with this end in mind. As a result their use is awkward at best. Separation of
duties is inherently concerned with sequences of transactions, rather than individual
transactions in isolation. For example consider a situation in which payment in the form
of a check is prepared and issued by the following sequence of events.
1.
A clerk prepares a voucher and assigns an account.
2.
The voucher and account are approved by a supervisor.
15
3.
The check is issued by a clerk who must be different from the clerk in step
1. Issuing the check also debits the assigned account. (Strictly speaking
we should debit one account and credit another in equal amounts. The
important point for our purpose is that issuing a check modifies account
balances.)
This sequence embodies separation of duties since the three steps must be
executed by different people. The policy moreover has a dynamic favor in that a
particular clerk can prepare vouchers as well as, on different occasions, issue checks.
However, a clerk cannot issue a check for a voucher prepared by himself.
Reconstruction of Events
The ability to reconstruct events in a system serves as a deterrent to improper behavior.
In the DBMS context the mechanism to record the history of a system is traditionally
called an audit trail. As with the principle of least privilege, a high-end DBMS should be
capable of reconstructing events to the finest detail. In practise this ability must be
tempered with the reality that gathering audit data indiscriminately can generate
overwhelming volume. Therefore a DBMS must also allow fine-grained selectivity
regarding what is audited. It should also structure the audit trail logically so that it is
easy to query. For instance, logging every keystroke does give us the ability to
reconstruct the system history accurately. However, with this primitive logical structure
one needs substantial effort to reconstruct a particular transaction.
In addition to the actual recording of all events that take place in the database, an
audit trail must also provide support for true auditing, i.e., an audit trail must have the
capability for an auditor to examine it in a systematic manner. In this respect DBMSs
have a significant advantage, since their powerful querying abilities can be used for this
purpose.
Delegation of Authority
The need to delegate authority and responsibility within an organization is
essential to its smooth functioning. It appears in its most developed form with respect to
monetary budgets. However the concept applies equally well to the control of other
assets and resources of the organization.
In most organizations the ability to grant authorization is never completely
unconstrained. For example, a department manger may be able to delegate substantial
authority over departmental resources to project managers within his department and
yet be prohibited to delegate this authority to project managers outside the department.
Traditional delegation mechanisms based on the concept of ownership, e.g., as
embodied in the SQL GRANT and REVOKE statements, are not adequate in this
context. Further work remains to be done in this area.
16
Reality Checks
This principle inherently requires activity outside of the DBMS. The DBMS does
have obligation to provide an internally consistent view of that portion of the database
which is being externally verified. This is particularly so if the external inspection is
conducted on an ad hoc on-demand basis.
Continuity of Operation
The basic technique to deal for maintaining continuity of operation in the face of
natural disasters, hardware failures and other disruptive events, is redundancy in
various forms. Recovery mechanisms in DBMS's must also ensure that we arrive at a
consistent state.
Fundamentals of Database Systems 5th Edition by Elmarsi/Navathe
Types of Security
- Legal and ethical issues
- Policy issues
- System-related issues
- The need to identify multiple security levels
Threats to databases
- Loss of integrity
- Loss of availability
- Loss of confidentiality
To protect databases against these types of threats four kinds of countermeasures can
be implemented:
- Access control
- Inference control
- Flow control
- Encryption
A DBMS typically includes a database security and authorization subsystem that is
responsible for ensuring the security portions of a database against unauthorized
access.
Two types of database security mechanisms:
- Discretionary security mechanisms
- Mandatory security mechanisms
17
The security mechanism of a DBMS must include provisions for restricting access to the
database as a whole. This function is called access control and is handled by creating
user accounts and passwords to control login process by the DBMS.
The security problem associated with databases is that of controlling the access to a
statistical database, which is used to provide statistical information or summaries of
values based on various criteria.
The countermeasures to statistical database security problem is called inference control
measures.
Another security is that of flow control, which prevents information from flowing in such
a way that it reaches unauthorized users.
Channels that are pathways for information to flow implicitly in ways that violate the
security policy of an organization are called covert channels.
A final security issue is data encryption, which is used to protect sensitive data (such as
credit card numbers) that is being transmitted via some type communication network.
The data is encoded using some encoding algorithm. An unauthorized user who access
encoded data will have difficulty deciphering it, but authorized users are given decoding
or decrypting algorithms (or keys) to decipher data.
Data Security and The Database Administrator
The database administrator (DBA) is the central authority for managing a database
system.
The DBA’s responsibilities include
- granting privileges to users who need to use the system
- classifying users and data in accordance with the policy of the organization
The DBA is responsible for the overall security of the database system.
The DBA has a DBA account in the DBMS.
Sometimes these are called a system or SUPERUSER account
These accounts provide powerful capabilities such as:
1. Account creation
2. Privilege granting
3. Privilege revocation
4. Security level assignment
Action 1 is access control, whereas 2 and 3 are discretionarym and 4 is used to control
mandatory authorization.
18
Access Protection, User Accounts, and Database Audits
Whenever a person or group of person s need to access a database system, the
individual or group must first apply for a user account. The DBA will then create a new
account id and password for the user if he/she deems there is a legitimate need to
access the database he user must log in to the DBMS by entering account id and
password whenever database access is needed.
The database system must also keep track of all operations on the database that are
applied by a certain user throughout each login session. To keep a record of all updates
applied to the database and of the particular user who applied each update, we can
modify system log, which includes an entry for each operation applied to the database
that may be required for recovery from a transaction failure or system crash.
If any tampering with the database is suspected, a database audit is performed A
database audit consists of reviewing the log to examine all accesses and operations
applied to the database during a certain time period. A database log that is used mainly
for security purposes is sometimes called an audit trail.
Discretionary Access Control Based on Granting and Revoking Privileges
The typical method of enforcing discretionary access control in a database system is
based on the granting and revoking privileges.
Types of Discretionary Privileges
The account level: At this level, the DBA specifies the particular privileges that
each account holds independently of the relations in the database.
The relation level (or table level): At this level, the DBA can control the privilege
to access each individual relation or view in the database.
The privileges at the account level apply to the capabilities provided to the account itself
and can include






the CREATE SCHEMA or CREATE TABLE privilege, to create a schema or base
relation;
the CREATE VIEW privilege;
the ALTER privilege, to apply schema changes such adding or removing
attributes from relations;
the DROP privilege, to delete relations or views;
the MODIFY privilege, to insert, delete, or update tuples;
and the SELECT privilege, to retrieve information from the database by using a
SELECT query.
19
The second level of privileges applies to the relation level

This includes base relations and virtual (view) relations.
The granting and revoking of privileges generally follow an authorization model for
discretionary privileges known as the access matrix model where

The rows of a matrix M represents subjects (users, accounts, programs)

The columns represent objects (relations, records, columns, views, operations).

Each position M( i , j ) in the matrix represents the types of privileges (read, write,
update) that subject i holds on object j.
To control the granting and revoking of relation privileges, each relation R in a database
is assigned and owner account, which is typically the account that was used when the
relation was created in the first place.

The owner of a relation is given all privileges on that relation.

In SQL2, the DBA can assign and owner to a whole schema by creating the
schema and associating the appropriate authorization identifier with that schema,
using the CREATE SCHEMA command.

The owner account holder can pass privileges on any of the owned relation to
other users by granting privileges to their accounts.
In SQL the following types of privileges can be granted on each individual relation R:
SELECT (retrieval or read) privilege on R:

Gives the account retrieval privilege..

In SQL this gives the account the privilege to use the SELECT statement
to retrieve tuples from R.
MODIFY privileges on R:
 This gives the account the capability to modify tuples of R.

In SQL this privilege is further divided into UPDATE, DELETE, and
INSERT privileges to apply the corresponding SQL command to R.

In addition, both the INSERT and UPDATE privileges can specify that only
certain attributes can be updated by the account.
20
In SQL the following types of privileges can be granted on each individual relation R
(contd.):
REFERENCES privilege on R:


This gives the account the capability to reference relation R when
specifying integrity constraints.
The privilege can also be restricted to specific attributes of R
Notice that to create a view, the account must have SELECT privilege on all relations
involved in the view definition.
Specifying Privileges Using Views
The mechanism of views is an important discretionary authorization mechanism in its
own right. For example,

If the owner A of a relation R wants another account B to be able to retrieve only
some fields of R, then A can create a view V of R that includes only those
attributes and then grant SELECT on V to B.

The same applies to limiting B to retrieving only certain tuples of R; a view V’ can
be created by defining the view by means of a query that selects only those
tuples from R that A wants to allow B to access.
Revoking Privileges
In some cases it is desirable to grant a privilege to a user temporarily. For example,

The owner of a relation may want to grant the SELECT privilege to a user for a
specific task and then revoke that privilege once the task is completed.

Hence, a mechanism for revoking privileges is needed. In SQL, a REVOKE
command is included for the purpose of canceling privileges.
Whenever the owner A of a relation R grants a privilege on R to another account B,
privilege can be given to B with or without the GRANT OPTION.
If the GRANT OPTION is given, this means that B can also grant that privilege on R to
other accounts.

Suppose that B is given the GRANT OPTION by A and that B then grants the
privilege on R to a third account C, also with GRANT OPTION. In this way,
privileges on R can propagate to other accounts without the knowledge of the
owner of R.
21

If the owner account A now revokes the privilege granted to B, all the privileges
that B propagated based on that privilege should automatically be revoked by the
system.
Example

Suppose that the DBA creates four accounts
A1, A2, A3, A4

and wants only A1 to be able to create base relations. Then the DBA must issue
the following GRANT command in SQL
GRANT CREATETAB TO A1;

In SQL2 the same effect can be accomplished by having the DBA issue a
CREATE SCHEMA command as follows:
CREATE SCHEMA EXAMPLE AUTHORIZATION A1;

User account A1 can create tables under the schema called EXAMPLE.

Suppose that A1 creates the two base relations EMPLOYEE and DEPARTMENT
 A1 is then owner of these two relations and hence all the relation
privileges on each of them.

Suppose that A1 wants to grant A2 the privilege to insert and delete tuples in
both of these relations, but A1 does not want A2 to be able to propagate these
privileges to additional accounts:
GRANT INSERT, DELETE ON
EMPLOYEE, DEPARTMENT TO A2;
22
Specifying Limits on Propagation of Privileges
Techniques to limit the propagation of privileges have been developed, although they
have not yet been implemented in most DBMSs and are not a part of SQL.

Limiting horizontal propagation to an integer number i means that an account B
given the GRANT OPTION can grant the privilege to at most i other accounts.

Vertical propagation is more complicated; it limits the depth of the granting of
privileges.
3 Mandatory Access Control and Role-Based Access Control for Multilevel Security

The discretionary access control techniques of granting and revoking privileges
on relations has traditionally been the main security mechanism for relational
database systems.

This is an all-or-nothing method:
 A user either has or does not have a certain privilege.

In many applications, and additional security policy is needed that classifies data
and users based on security classes.
 This approach as mandatory access control, would typically be
combined with the discretionary access control mechanisms.

Typical security classes are top secret (TS), secret (S), confidential (C), and
unclassified (U), where TS is the highest level and U the lowest: TS ≥ S ≥ C ≥ U

The commonly used model for multilevel security, known as the Bell-LaPadula
model, classifies each subject (user, account, program) and object (relation,
tuple, column, view, operation) into one of the security classifications, T, S, C, or
U:
 Clearance (classification) of a subject S as class(S) and to the
classification of an object O as class(O).
23
Two restrictions are enforced on data access based on the subject/object
classifications:

Simple security property: A subject S is not allowed read access to an object O
unless class(S) ≥ class(O).

A subject S is not allowed to write an object O unless class(S) ≤ class(O). This
known as the star property (or * property).

To incorporate multilevel security notions into the relational database model, it is
common to consider attribute values and tuples as data objects.

Hence, each attribute A is associated with a classification attribute C in the
schema, and each attribute value in a tuple is associated with a corresponding
security classification.

In addition, in some models, a tuple classification attribute TC is added to the
relation attributes to provide a classification for each tuple as a whole.

The value of the TC attribute in each tuple t – which is the highest of all attribute
classification values within t – provides a general classification for the tuple itself,
whereas each Ci provides a finer security classification for each attribute value
within the tuple.
 The apparent key of a multilevel relation is the set of attributes that would
have formed the primary key in a regular(single-level) relation.
A multilevel relation will appear to contain different data to subjects (users) with different
clearance levels.

In some cases, it is possible to store a single tuple in the relation at a higher
classification level and produce the corresponding tuples at a lower-level
classification through a process known as filtering.

In other cases, it is necessary to store two or more tuples at different
classification levels with the same value for the apparent key.

This leads to the concept of polyinstantiation where several tuples can have the
same apparent key value but have different attribute values for users at different
classification levels.

In general, the entity integrity rule for multilevel relations states that all attributes
that are members of the apparent key must not be null and must have the same
security classification within each individual tuple.
24

In addition, all other attribute values in the tuple must have a security
classification greater than or equal to that of the apparent key.
 This constraint ensures that a user can see the key if the user is permitted
to see any part of the tuple at all.

Other integrity rules, called null integrity and interinstance integrity, informally
ensure that if a tuple value at some security level can be filtered (derived) from a
higher-classified tuple, then it is sufficient to store the higher-classified tuple in
the multilevel relation.

Discretionary Access Control (DAC) policies are characterized by a high degree
of flexibility, which makes them suitable for a large variety of application domains.
 The main drawback of DAC models is their vulnerability to malicious
attacks, such as Trojan horses embedded in application programs.

By contrast, mandatory policies ensure a high degree of protection in a way, they
prevent any illegal flow of information.

Mandatory policies have the drawback of being too rigid and they are only
applicable in limited environments.

In many practical situations, discretionary policies are preferred because they
offer a better trade-off between security and applicability.
Role Based Access Control

Role-based access control (RBAC) emerged rapidly in the 1990s as a proven
technology for managing and enforcing security in large-scale enterprisewide
systems.

Its basic notion is that permissions are associated with roles, and users are
assigned to appropriate roles.

Roles can be created using the CREATE ROLE and DESTROY ROLE
commands.
 The GRANT and REVOKE commands discussed under DAC can then be
used to assign and revoke privileges from roles.

RBAC appears to be a viable alternative to traditional discretionary and
mandatory access controls; it ensures that only authorized users are given
access to certain data or resources.
25

Many DBMSs have allowed the concept of roles, where privileges can be
assigned to roles.

Role hierarchy in RBAC is a natural way of organizing roles to reflect the
organization’s lines of authority and responsibility.

Another important consideration in RBAC systems is the possible temporal
constraints that may exist on roles, such as time and duration of role activations,
and timed triggering of a role by an activation of another role.

Using an RBAC model is highly desirable goal for addressing the key security
requirements of Web-based applications.

In contrast, discretionary access control (DAC) and mandatory access control
(MAC) models lack capabilities needed to support the security requirements
emerging enterprises and Web-based applications.
Statistical Database Security

Statistical database security techniques must prohibit the retrieval of individual
data.

The database may contain confidential data on individuals, which should be
protected from user access.

Users are permitted to retrieve statistical information on the populations, such as
averages, sums, counts, maximums, minimums, and standard deviations.

This can be achieved by prohibiting queries that retrieve attribute values and by
allowing only queries that involve statistical aggregate functions such as COUNT,
SUM, MIN, MAX, AVERAGE, and STANDARD DEVIATION, is called statistical
queries

It is DBMS’s responsibility to ensure confidentiality of information about
individuals, while still providing useful statistical summaries of data about those
individuals to users. Provision of privacy protection of users in a statistical
database is paramount.
26
Flow Control

Flow control regulates the distribution or flow of information among accessible
objects.

A flow between object X and object Y occurs when a program reads values from
X and writes values into Y.
 Flow controls check that information contained in some objects does not
flow explicitly or implicitly into less protected objects.

A flow policy specifies the channels along which information is allowed to move.
 The simplest flow policy specifies just two classes of information:
confidential (C) and nonconfidential (N)
 and allows all flows except those from class C to class N.
Covert Channels

A covert channel allows a transfer of information that violates the security or the
policy.

A covert channel allows information to pass from a higher classification level to
a lower classification level through improper means.

Covert channels can be classified into two broad categories:
 Storage channels do not require any temporal synchronization, in that
information is conveyed by accessing system information or what is
otherwise inaccessible to the user.
 Timing channel allow the information to be conveyed by the timing of
events or processes.

Some security experts believe that one way to avoid covert channels is for
programmers to not actually gain access to sensitive data that a program is
supposed to process after the program has been put into operation.
27
6 Encryption and Public Key Infrastructures

Encryption is a means of maintaining secure data in an insecure environment.

Encryption consists of applying an encryption algorithm to data using some
prespecified encryption key.

The resulting data has to be decrypted using a decryption key to recover the
original data.
The Data and Advanced Encryption Standards

The Data Encryption Standard (DES) is a system developed by the U.S.
government for use by the general public.
 It has been widely accepted as a cryptographic standard both in the
United States and abroad.

DES can provide end-to-end encryption on the channel between the sender A
and receiver B.

DES algorithm is a careful and complex combination of two of the fundamental
building blocks of encryption:
 substitution and permutation (transposition).

The DES algorithm derives its strength from repeated application of these two
techniques for a total of 16 cycles.
 Plaintext (the original form of the message) is encrypted as blocks of 64
bits.

After questioning the adequacy of DES, the National Institute of Standards
(NIST) introduced the Advanced Encryption Standards (AES).
 This algorithm has a block size of 128 bits and thus takes longer time to
crack.
Public Key Encryption

In 1976 Diffie and Hellman proposed a new kind of cryptosystem, which they
called public key encryption.
28

Public key algorithms are based on mathematical functions rather than
operations on bit patterns.
 They also involve the use of two separate keys in contrast to conventional
encryption, which uses only one key.
 The use of two keys can have profound consequences in the areas of
confidentiality, key distribution, and authentication.


The two keys used for public key encryption are referred to as the public key and
the private key.
 The private key is kept secret, but it is referred to as private key rather
than a secret key (the word used in conventional encryption to avoid
confusion with conventional encryption).
A public key encryption scheme, or infrastructure, has six ingredients:
 Plaintext: This is the data or readable message that is fed into the
algorithm as input.
 Encryption algorithm: The encryption
transformations on the plaintext.
algorithm
performs
various
 Public and private keys: These are pair of keys that have been selected so
that if one is used for encryption, the other is used for decryption. The
exec transformations performed by the encryption algorithm depend on
the public or private key that is provided as input.

A public key encryption scheme, or infrastructure, has six ingredients
 Ciphertext: This is the scrambled message produced as output. It
depends on the plaintext and the key. For a given message, two different
keys will produce two different ciphertexts.
 Decryption algorithm: This algorithm accepts the ciphertext and the
matching key and produces the original plaintext.

Public key is made for public and private key is known only by owner.

A general-purpose public key cryptographic algorithm relies on
 one key for encryption and a different but related key for decryption.
29
The essential steps are as follows:

Each user generates a pair of keys to be used for the encryption and decryption
of messages.

Each user places one of the two keys in a public register or other accessible file.
This is the public key. The companion key is kept private (private key).

If a sender wishes to send a private message to a receiver, the sender encrypts
the message using the receiver’s public key.

When the receiver receives the message, he or she decrypts it using the
receiver’s private key.
 No other recipient can decrypt the message because only the receiver
knows his or her private key.

Two keys, d and e, are used for decryption and encryption.
 An important property is that d and e can be interchanged.
 n is chosen as a large integer that is a product of two large distinct
prime numbers, a and b.
 The encryption key e is a randomly chosen number between 1 and n that
is relatively prime to (a-1) x (b-1).
 The plaintext block P is encrypted as Pe mod n.
 Because the exponentiation is performed mod n, factoring Pe to uncover
the encrypted plaintext is difficult.
 However, the decryption
(Pe)d mod n = P.
key
d
is
carefully
chosen
so
that
 The decryption key d can be computed from the condition that
d x e= 1 mod ((a-1)x(b-1)).
 Thus, the legitimate receiver who knows d simply
(Pe)d mod n = P and recovers P without having to factor Pe .
30
computes
Digital Signatures

A digital signature is an example of using encryption techniques to provide
authentication services in e-commerce applications.

A digital signature is a means of associating a mark unique to an individual with a
body of text.
 The mark should be unforgettable, meaning that others should be able to
check that the signature does come from the originator.

A digital signature consists of a string of symbols.
 Signature must be different for each use.
 This can be achieved by making each digital signature a function of
the message that it is signing, together with a time stamp.
 Public key techniques are the means creating digital signatures.
Multi-level Database Security Polyinstantiation by Dr. Natarajan Meghanathan
Multi-Level Security (MLS) Database

With the use of Multi-Level Security (MLS), a DBMS can allow subjects with
different security clearances to simultaneously access objects with different
security levels.

The Security clearances and security levels typically considered are: Top Secret
(TS), Secret (S), Confidential (C) and Unclassified (U).

MLS allows subjects with higher security clearance to easily allow access objects
with equal or lower security level.

The ordering among these clearances and security levels is as follows:
– TS > S > C > U

The MLS approach is a classical example for the Mandatory Access Control
(MAC) model as the security clearance and security level for the subjects and
objects are uniformly adopted enterprise-wide.

Typically, each field (element object) in the table is assigned a security level and
the security level for a tuple is the highest of the security evels of its constituent
element objects.
31
Example for MLS Database
Consider the following Storage database wherein, for simplicity, each
tuple is assigned a security level.
Each room contains two compartments (X and Y). The combination of the room number
and the compartment forms the Primary Key. There has to be “two” views of the above
table. The DBA and other managerial-level users have to be able to see all the six
tuples of the above table; whereas, a regular user should not be able to see the third
tuple that has a Confidential information (Bank Records!!)
If a regular user with security clearance ‘Unclassified’ runs the
following SQL Query.
– Select * from Storage
The results should be:
32
However, the above display of records leads the Unclassified user to believe that there
is nothing in the Compartment X of Room no. 451. If the user executes an Insert SQL
query like “INSERT INTO Storage VALUES (‘451’, ‘X’, ‘Fruits’, ‘Unclassified’); then the
DBMS would return an Access denied feedback.
The ‘Access Denied’ feedback could mean to the Unclassified user that there is
already a tuple with the primary key matching with what he is trying to insert and that
the security level of the tuple is greater than his security clearance. This is referred to as
an “Indirect Channel.” If the employee comes to know about the presence of something
that is more than “Unclassified” in Compartment X of Room no. 451, then he/she could
potentially do something harmful to the entity being stored over there and cause
damage to the organization.
Polyinstantiation
To avoid such a dangerous inference, the organization could allow the employee
to insert a tuple at the Unclassified level in the database. However, this would lead to a
situation wherein there are two tuples with the same value for the primary key: Room
no. 451 and Compartment X. The presence of two or more rows (tuples) with the same
value(s) for the primary key, obviously with different security levels for each tuple is
called “Polyinstantiation.”
Example for MLS Database Polyinstantiation
When user with security classification “Confidential” or above executes the SQL query
“Select * from Storage,” all the above 7 tuples would be returned. The user has to
however discard the polyinstantiated tuples with security level below to that of the user.
33
When user with security classification “Unclassified” executes the SQL query “Select *
from Storage,” the tuples that are of security level “Unclassified” would only be returned.
The user is made to believe that there are Fruits in Compartment X of Room No. 451.
This is better than displaying “NULL” for the sensitive attribute and raising suspicion for
the Unclassified that something sensitive is over there.
Visible and Invisible Polyinstantiation
Visible Polyinstantiation occurs when a user with a higher security clearance
attempts to insert a tuple into a database that already has a tuple, with the same
primary key, at a lower security level. Invisible Polyinstantiation occurs when a user with
a lower security clearance attempts to insert a tuple into a database that already has a
tuple, with the same primary key, at a higher security level. The Polyinstantiation that
we created in the previous slides (Storage database Example) is an example for
Invisible Polyinstantiation.
Consequence of Polyinstantiation:
An after-effect of allowing polyinstantiation is that there will be an explosion of
tuples in a database. If the number of security levels is 4, for every tuple, that could be
entered with the highest security level in the database table, there would be at most
three “Cover Story” tuples that could be recorded. Polyinstantiation is inevitable in Multilevel world.
34
Security and Control Issues within Relational Databases
by David C. Ogbolumani, CISA, CISSP, CIA, CISM
Practice Manager – Information Security
Keypoints






The Database Environment
Top Database Threats
Key Control Layers
Security Features within Databases
Applications Systems and Databases
Common Database Issues
The Database Environment
Database servers are the most important systems in virtually all organizations. They
store critical information that supports business including the following:






Email
Financial Data
Sales Data
Personnel Data
Intellectual Property
Operation and Security Data, etc.
Modern Databases are created using Structured Query Language (SQL) which is the
standard for database interoperability.
Relational Database Management System
This refers to the software system that is used to create a database and they include
well known products such as the following:







Oracle
MS SQL and MS Access
IBM DB2 and Informix
Teradata (NCR)
Sybase
Postgre SQL
MySQL
35
Top Database Security Threats
Privilege Abuse


Abusing legitimate privileges for unauthorized purposes
Excessive privileges that exceeds job function requirement
Weak Authentication



Weak or ineffective password policies
Theft of login credentials, social engineering
Poor encryption
Weak Systems Configuration



Use of default Configurations
Installation of improper tools and services
Lack of security baseline
Database and Operating System Vulnerabilities




SQL Injections
Cross Site Scripting
Root Kits
Weak communication protocols
Poor Audit Trail
Front-End Application Vulnerabilities
Backup


Incomplete and failed backups
Theft or improper storage of backup storage media or hard drives
Common Security Features in Databases
Basic Security Mechanism in databases includes






Identification and Authentication requirements
System Privilege and Object Access Control
Audit Trail Mechanism
Data Encryption
Network Security
Auditing/Fine Grain Auditing.
36
Identification and Authentication
Users can access databases through a variety of means including remotely, wireless
access, scanners, through the internal network, etc. There are associated risks with
each access means.
Each user may be identified and authenticated by either the operating system or the
database system. For example:

The Administrator can specify an Oracle password for each Oracle user when
the account is created, or

In UNIX a user account e.g. DavidO can be Oracle user “OPS$DavidO” and
connect without a password

This is feature disabled by default for remote users
MSSQL has mixed authentication. Users may log in with either an operating system ID,
or a separate database user account.
Reviewing Users and Passwords
Obtain a list of all Database User Accounts


Describe dba_users
Select * from sys.dba_users
Identify the purpose and use of each user account




Identify generic accounts
Identify shared account
Service Accounts
Guest or anonymous logins
37
Review Password Policies defined in both the database and operating systems. Check
for the use of common default passwords or blank passwords.
Review user profiles as they contain the following important password control
mechanism such as these settings:






Failed login attempts
Password Expiration
Account lockout duration
Minimum and Maximum password length
Password reuse
Password grace period before the account expires
Earlier versions of SQL prior to SQL 2000 lack controls such as password complexity,
expiration, lockout, and password history.
Application Systems Connections
Popular Application Systems such as JDE, PeopleSoft, SAP/R3 and other
applications also connect directly to the database. Home grown and legacy applications
also connect to the database and in many cases these are done with hard coded
passwords.
Key Security and Control Issues include the following:



Access to data outside the Application System
Application System Access and Security
Application Systems Internal Controls
Many popular applications as well as home grown applications are configured to
use their passwords to login to the database. Such application may supply its UserID
and password and not the end user’s. In this case

Neither the Operating System nor Database is aware of the end user’s identity

Neither the OS or Database (e.g. Oracle) can enforce access control decisions or
monitoring based on end user identity.
Such passwords are sometimes hard coded in the application or script and rarely
changed.
The password may be stored in a user-accessible or unencrypted file


38
Bypassing Application Controls
This can occur when a user has an ID with direct access to the database and the
underlying tables.

They can update compensation tables or other sensitive data

SOL*PLUS would allow the user update access outside the application

Risk Management professionals should evaluate database and application
security to determine if level of protection is sufficient.
Users should not be directly defined in the database if they login with a front end
application.
Reviewing Access Control
Roles, Responsibilities and Privileges - Rules defining what users can do
System Privileges - Allows a user to perform a particular database command or
operation
Object Privileges - Allows a user to access an object in a particular manner
Statement Privileges - Selective auditing of related groups of statements regarding a
particular type of database structure or schema object.
Review the operating system permissions of all key database files. Privileges are
provided directly to users or through roles.
Logging and Monitoring
Define what actions and abuses that need to be checked such as the following:







Successful database access
Changes to database structure
Failed logon attempts
Attempts to access the database with non-existent user names
Attempts to access the database at unusual hours.
Checks for users sharing database accounts
Multiple access attempts using different usernames from the same terminal
Database auditing is viewed as being complex and slow but this is generally not true.
39
Vulnerability Analysis
Conduct periodic Vulnerability Assessments
Vulnerability Assessment Tests probe for known vulnerabilities




Identify vulnerable software versions
Identify vulnerable services
Probes the database for known weaknesses
Test for default and weak passwords
Common tools that are used for the following include


Nessus, Retina, Saint (Generic Assessments)
App Detective, NGSSquirrel, (Specific to Databases)
Common Database Security Issues
Users with excessive privileges

Users with administrative privileges

Users whose privileges are higher than their role requires

Users who have moved or changed job roles

Lack of logging and No Auditing of Privileged users

Failure to Segregate Duties appropriately

Inadequate review of Audit logs

Generic, shared, and terminated users with access to production systems

Guest user in production databases

Improperly configured systems and weak patch management

Incomplete backup and failure to encrypt backup data
40
Database System Security by Paul J. Wagner UMSSIA 2008
Database system security is more than securing the database; to achieve a secure
database system, we need a:






Secure database
Secure DBMS
Secure applications / application development
Secure operating system in relation to database system
Secure web server in relation to database system
Secure network environment in relation to database system
Historical database security framework is to separate set of usernames,
passwords and database administrator assigns privileges for each user. Privileges
assigned by users and level of confidentiality. General password policies ( length,
domain, changing and protection.
Managing Privileges - Have 2 types (System - actions) and (Object – data)
Problem: M (users) x N (privileges) possible combinations.
Solution: Roles (a security pattern) Collections of (usually system) privileges. Manage
with Grant / Revoke, higher level tools Giving (or removing ) privileges or roles to (from)
users.
41
Data Encryption - Sensitive data should be encrypted within database. Most databases
now have utilities for this.
Examine cost of this process


May slow access time,, use resources
May interfere with system administration
Don’t forget about data once out of the database
 Need to decrypt for users
 Ensure data is still protected when DB sends it to a client for usage,, or when
client sends to DB.
Database Issues - Inference Attack
Statistical Database – database used for statistical purposes, usually Online Analytical
Processing (OLAP) as in data warehouse situations. Generally allows only aggregate
functions queries (may be limited to SUM,, COUNT,, AVERAGE) on a group off rows.
and may not all low queries on individual rows.
Problem: it may still be possible to infer individual data values from such a database.
Inference Attack Example:
Base query: find count of all UWEC students
Example SQL:
 SELECT Count(*) FROM StudentDB;
returns single number, ~10,000, doesn't expose any individual information, but we can
do more…
Inference Attack Example
:
Find count of UWEC students that:



Have a local address in Eau Claire
Have a GPA of between 3.1 and 3.2
Are majoring in computer science
SELECT Count(*) FROM StudentDB WHERE cond1 AND cond2 AND cond3 AND …
Getting count down to fewer and fewer students as we add filter conditions. If count gets
down to 1, you know an individual exists with those characteristics.
42
May even be able to gain private information. Find average hourly pay rate for UWEC
students that have the above characteristics.
Inference Attack Prevention Techniques:



Return an approximate number of rows (e.g. between A and B)
Limit the number of filtering conditions on a query.
Return ranges for values, especially for sensitive fields (e.g. salary falls between
X and Y)
Difficult to balance functionality and security with such data.
Database Issue - Correlation Attack
Data in database may be anonymous. However, it may able to be correlated with
another set of data which is not anonymous. Anonymity can thus be removed.
Example: Statistical analysis of public but anonymized Netflix date set using internet
movies database (imdb.com) data. By comparing rankings and timestamps from Netflix
data, authors identified a subset of individuals through correlated data from IMDB.
Secure Application Development
Access to Oracle Database of environment through applications. Need to consider
security of applications using database as well as security of data in database itself.
SQL Injection
Definition - inserting malicious SQL code through an application interface. Often through
web application, but possible with any interface.
Typical scenario

Three-tier application (web interface, application, database)

Overall application tracks own usernames and passwords in database
(advantage: can manage users in real time)

Web interface accepts username and password, passes these to application
layer as parameters
43
Example: Application Java code (receiving username and password from client)
contains SQL statement:
String query = "SELECT * FROM users_table " + " WHERE username = " + " ‘ " +
username + " ‘ " + " AND password = " + " ‘ " + password + " ‘ "
Expected Result:
"SELECT * FROM users_table WHERE username = ‘wagnerpj‘ AND password =
‘paulpass‘;
Note: String values must be single quoted in SQL, so application provides these before
and after each passed string parameter.
Application is expecting one username/password pair row to be returned if success, no
rows if failure.
Common variant to simplify the above check:
SELECT COUNT(*) FROM users_table WHERE username = ‘someuser‘ AND
password = ‘somepass‘;
Attacker enters:

Any username (valid or invalid)

Password of: Aa' OR '' = '
Query becomes:
SELECT * FROM users_table
WHERE username = ‘anyname‘
AND password = ‘Aa‘ OR ‘ ‘ = ‘ ‘;
Note: WHERE clause => ? and F
or T => F or T => T
AND has higher precedence than
OR. All user/pass rows returned to
application. If application checking
for 0 vs. more than 0 rows,
attacker is in.
44
SQL Injection Prevention
Not checking the controlling input properly, specifically, not controlling string input.
Note: there are a variety of ways SQL injection can happen.
Regular inclusion of SQL metacharacters through




Variable interpolation
String concatenation with variables and/or constants
String format functions like sprintf()
String templating with variable replacements
Hex or Unicode encoded metacharacters.
First possible solution: Check content.



Client code check to ensure certain content rules are met
Server code checks content as well
Specifically - don't allow apostrophes to be passed
Problem: there are other characters that can cause problems; e.g.
 // SQL comment character
 ; // SQL command separator
 % // SQL LIKE subclause wildcard character
Many possible variations os SQL Injection. Many potential metacharacters to filter,
dependent on DBMS variety. Maybe filtering input by blacklisting metacharacters isn't
the best approach.
Regular Statements - SQL query (a string) is generated entirely at run-time. Custom
procedure and data are complied and run. Compilation allows combination of procedure
and data, allowing problems with SQL metacharacters.
Better Solution - Prepared statements (Parameterized Queries). SQL query is
precompiled with placeholders. Data is added in at run-time, converted to correct type
for the given fields.
Issues with Prepared Statements
Cannot use them in all situations. Generally limited to replacing field values in SELECT,
INSERT, UPDATE, DELETE statements.
Example: if also asking user for information that determines choice of table name,
cannot use a prepared statement.
45
Additional Precautions

Do not access the database as privileged user, attacker who gains access
through user will have that user's privileges.

Limit database user to only what they need to do, e.g. reading information from
database, no insert/update/delete.

Do not allow direct access to database from the internet, requires user to go
through your(controlled) applications.

Do not embed database accounts passwords in your code, encrypt and store
them in a repository that is read at application startup.

Do not expose information in error messages, e.g. do not display stack traces.
Applications Issues
Be aware of how information is transmitted between client applications and database.
Student Research Project at UWEC tested 5 DBMSs and various clients (vendor and
user)




Most common client applications (vendor-supplied or user-programmed) at least
encrypt the connection password.
Some clients encrypt the connection user
Certain DBMSs have varying levels of security (e.g. PostgreSQL)
One DBMS transmits the connection password length (MS SQL Server 2005
Edition)
Be aware of how application exposes information.
Example: Panel rating system displays each reviewer’s rating for each proposal,
but doesn't display individual ratings for a given proposal unless you've entered your
rating. Default display is in recommended discussion ordered, so no information
disclosed.
However, panel rating system also allows you to sort data by any column,
including ratings (average). This allows you to see the approximate average rating by
other reviewers before entering your rating. Not a big deal here, but point is that
applications may be able to be used in certain ways to expose information
46
Secure Application Development
Application Security in the Enterprise Environment



J2EE – JDBC, Servlets, JSPs, JNDI, EJBs, .....
.NET – many components
Need to be aware of security issues with each component, interaction of
components.
Use of Proxy Applications


Assume network filtering most evil traffic
Application can control fine-grain behavior, application protocol security.
Security Patterns (from J2EE Design Patterns Applied)
Single-Access Point Pattern, single point of entry into system. Example violation: online
course system.
Check Point Pattern - centralized enforcement of authentication and authorization.
Role Pattern - disassociation of users and privileges.
Secure Operating System
DBMS interacts with operating system.





File manipulation
Can often run shell commands from DBMS
DBMS procedural languages often have packages that interact directly with OS
Installation of DBMS uses file system
DBMS uses OS resources
Interaction of Oracle and OS
Windows



Secure administrative accounts
Control registry access
Need good account policies
47
Linux/Unix





Choose different account names that standard suggestions
Restrict use of the account that owns Oracle software
Secure temporary directory
Some oracle files are SUID(root)
Command line SQL*Plus with user/pass parameters appears under ps output
Secure Web Server.
Interaction of Oracle and Web Server. Apache now provided within Oracle as its
application server, started by default.
Apache issues



Standard configuration has some potential problems.
Ensure secure communication from web clients to web server.
Use MaxClients to limit possible connections.
Internet Information Server (IIS) issues.


Integration with other MS products (e.g. Exchange Server)
May known vulnerabilities over past versions (patches available)
Secure Network
Interaction of Databases and Network.
Features for:



Authentication
Integrity
Encryption- use of SSL
Server generally behind firewall


Good to separate DB and Web servers
Connections normally initiated on port 1521, but then dynamically selected.
Other network issues to consider
 Possibility of hijacking a sys/sysmgr connection.
 Various sniffing and spoofing issues.
48
Auditing

Good policy; develop a comprehensive audit system for database activity
tracking

Database system: can accomplish with triggers

Can write to OS as well as into database for additional security, accountability for
all working with databases.
Overall Security Examination of Database System in Networked Environment
1. Database: Set-up client(s), test databases for:
 Privileged access accounts
 Public access through other known/discovered usernames
2. DBMS: Check for known vulnerabilities
 Check overall system level, patch level
 Test for specific problems gathered from web search, literature
3. Application
 Test for SQL Injection, other application weaknesses.
Similar types for tasks for OS, Web Server, Network components
Task: develop report, including specifics for all areas.
III. ANALYSIS:
Has I read all the articles from different authors and gathered information about
database security issues they have different approach on how to detailed their work,
aside from the explanations included.
Some authors say that security issues are from the Database Administration,
wrong implementation of system, some are compatibility issues and interference that
unauthorized access to the databases. As a whole the articled I read is tackled all sides
for security issues and steps on how to prevent data loss and unauthorized access
occur. Some issues fall under hardware and compatibility other are user accessibility on
how to query a report depending confidentially of the data.
49
IV. CONCLUSION:
For this research, database security not only focus on one segment of the
system but also the attributes are validated and tested, to secure the database system
security to all levels of confidential information stored in it. Knowing the steps and what
are the thing needed when I comes to deploy and application or integrated system
V.RECOMMENDATION:
Database security is more on testing and data confidentiality on how to protect
information from unauthorized access. Authors discussed about procedures on how to
check policies limit the view of users and access with restrictions. Recommend this
research about database security for more information gathering in all aspects of
database management system at this time there are more new databases like NoSQL,
NewSQL, Graph DB etc... there are new database security procedures, test will deploy
and check the validity of all its attributes, new database management systems must
scrutinize for the complete security of the data stored on new database systems.
REFERENCES:
http://searchsecurity.techtarget.com/tip/Implementing-database-security-and-integrity
http://www.slideshare.net/amiable_indian/database-systems-security
http://databases.about.com/od/security/Database_Security_Issues.htm
http://www.darkreading.com/database
50
DATABASE SECURITY ISSUES
Davie Ben B. Estrella
PUPOU - MSIT
Dr. Rosicar E. Escober
Advance Database Organization
51