Introduction
to Database Security Issues
1. Types of Security
Database security is a broad area that
addresses many issues, including the following:
·
Various
legal and ethical issues regarding the right to access certain information—for
example, some information may be deemed to be private and can-not be accessed
legally by unauthorized organizations or persons. In the United States, there
are numerous laws governing privacy of information.
·
Policy
issues at the governmental, institutional, or corporate level as to what kinds
of information should not be made publicly available—for example, credit
ratings and personal medical records.
·
System-related
issues such as the system levels at
which various security functions should be enforced—for example, whether a
security function should be handled at the physical hardware level, the
operating system level, or the DBMS level.
·
The need
in some organizations to identify multiple security
levels and to categorize the data and users based on these
classifications—for example, top secret, secret, confidential, and
unclassified. The security policy of the organization with respect to
permitting access to various classifications of data must be enforced.
Threats to Databases. Threats to databases can result in the loss or
degradation of some or all of the following commonly accepted security goals:
integrity, avail-ability, and confidentiality.
Loss of integrity. Database integrity refers to the requirement
that information be protected from improper modification. Modification of data
includes creation, insertion, updating, changing the status of data, and
deletion. Integrity is lost if unauthorized changes are made to the data by
either intentional or accidental acts. If the loss of system or data integrity
is not corrected, continued use of the contaminated system or corrupted data
could result in inaccuracy, fraud, or erroneous decisions.
Loss of availability. Database availability refers to making objects
available to a human user or a
program to which they have a legitimate right.
Loss of
confidentiality. Database
confidentiality refers to the protection of
data from unauthorized disclosure. The impact of unauthorized disclosure of
confidential information can range from violation of the Data Privacy Act to
the jeopardization of national security. Unauthorized, unanticipated, or
unintentional disclosure could result in loss of public confidence,
embarrassment, or legal action against the organization.
To protect databases against these types of
threats, it is common to implement four
kinds of control measures: access
control, inference control, flow control, and encryption. We discuss each of
these in this chapter.
In a multiuser database system, the DBMS must
provide techniques to enable certain users or user groups to access selected
portions of a database without gaining access to the rest of the database. This
is particularly important when a large integrated database is to be used by
many different users within the same organization. For example, sensitive
information such as employee salaries or performance reviews should be kept
confidential from most of the database system’s users. A DBMS typically
includes a database security and
authorization subsystem that is responsible for ensuring the security of
portions of a database against unauthorized access. It is now customary to
refer to two types of database security mechanisms:
Discretionary security mechanisms. These are used to grant privileges to users, including the capability to
access specific data files, records, or fields in a specified mode (such as
read, insert, delete, or update).
Mandatory security mechanisms. These are used to enforce multilevel security by classifying the data and
users into various security classes (or lev-\els) and then implementing the
appropriate security policy of the organization. For example, a typical
security policy is to permit users at a certain classification (or clearance)
level to see only the data items classified at the user’s own (or lower)
classification level. An extension of this is role-based security, which
enforces policies and privileges based on the concept of organizational roles.
We discuss discretionary security in Section
24.2 and mandatory and role-based security in Section 24.3.
2. Control Measures
Four main control measures are used to provide
security of data in databases:
Access
control
Inference
control
Flow
control
Data
encryption
A security problem common to computer systems
is that of preventing unauthorized persons from accessing the system itself,
either to obtain information or to make malicious changes in a portion of the
database. The security mechanism of a DBMS must include provisions for
restricting access to the database system as a whole. This function, called access control, is handled by creating
user accounts and passwords to control the login process by the DBMS. We
discuss access control techniques in Section 24.1.3.
Statistical
databases are used to provide statistical information or summaries of
values based on various criteria. For example, a database for population
statistics may provide statistics based on age groups, income levels, household
size, education levels, and other criteria. Statistical database users such as
government statisticians or market research firms are allowed to access the
database to retrieve statistical information about a population but not to
access the detailed confidential information about specific individuals.
Security for statistical databases must ensure that information about
individuals cannot be accessed. It is sometimes possible to deduce or infer
certain facts concerning individuals from queries that involve only summary statistics
on groups; consequently, this must not be permitted either. This problem,
called statistical database security,
is discussed briefly in Section 24.4. The corresponding control measures are
called inference control measures.
Another security issue is that of flow control, which prevents
information from flowing in such a way that it reaches unauthorized users. It
is discussed in Section 24.6. Channels that are pathways for information to
flow implicitly in ways that vio-late the security policy of an organization
are called covert channels. We
briefly dis-cuss some issues related to covert channels in Section 24.6.1.
A final control measure is data encryption, which is used to protect sensitive data (such as
credit card numbers) that is transmitted via some type of communications
network. Encryption can be used to provide additional protection for sensitive
portions of a database as well. The data is encoded using some coding algorithm. An unauthorized user who
accesses encoded data will have difficulty deciphering it, but authorized users
are given decoding or decrypting algorithms (or keys) to decipher the data.
Encrypting techniques that are very difficult to decode without a key have been
developed for military applications. Section 24.7 briefly discusses encryption
techniques, including popular techniques such as public key encryption, which
is heavily used to support Web-based transactions against databases, and
digital signatures, which are used in personal communications.
A comprehensive discussion of security in
computer systems and databases is out-side the scope of this textbook. We give
only a brief overview of database security techniques here. The interested
reader can refer to several of the references dis-cussed in the Selected Bibliography
at the end of this chapter for a more comprehensive discussion.
3. Database Security and the DBA
As we discussed in Chapter 1, 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 and classifying users and data in accordance with the policy of
the organization. The DBA has a DBA
account in the DBMS, sometimes called a system or superuser account,
which provides powerful capabilities that are not made available to regular
database accounts and users. DBA-privileged commands include commands for
granting and revoking privileges to individual accounts, users, or user groups
and for performing the following types of actions:
Account creation. This action creates a new account and password
for a user or a group of users to
enable access to the DBMS.
Privilege granting. This action permits the DBA to grant certain
privileges to certain accounts.
Privilege revocation. This action permits the DBA to revoke (cancel)
certain privileges that were
previously given to certain accounts.
Security level assignment. This action consists of assigning user accounts
to the appropriate security
clearance level.
The DBA is responsible for the overall security
of the database system. Action 1 in the preceding list is used to control
access to the DBMS as a whole, whereas actions 2 and 3 are used to control discretionary database authorization,
and action 4 is used to control mandatory
authorization.
4. Access Control, User Accounts, and
Database Audits
Whenever a person or a group of persons needs
to access a database system, the individual or group must first apply for a
user account. The DBA will then create a new account number and password
for the user if there is a legitimate need to access the database. The user
must log in to the DBMS by entering
the account number and password whenever database access is needed. The DBMS
checks that the account number and password are valid; if they are, the user is
permitted to use the DBMS and to access the database. Application programs can
also be considered users and are required to log in to the database (see
Chapter 13).
It is straightforward to keep track of database
users and their accounts and pass-words by creating an encrypted table or file
with two fields: AccountNumber and Password. This table can easily be
maintained by the DBMS. Whenever a new account is created, a new record is
inserted into the table. When an account is canceled, the corresponding record
must be deleted from the table.
The database system must also keep track of all
operations on the database that are applied by a certain user throughout each login session, which consists of the
sequence of database interactions that a user performs from the time of logging
in to the time of logging off. When a user logs in, the DBMS can record the
user’s account number and associate it with the computer or device from which
the user logged in. All operations applied from that computer or device are
attributed to the user’s account until the user logs off. It is particularly
important to keep track of update operations that are applied to the database
so that, if the database is tampered with, the DBA can determine which user
did the tampering.
To keep a record of all updates applied to the
database and of particular users who applied each update, we can modify the system log. Recall from Chapters 21 and
23 that the system log includes an
entry for each operation applied to the database that may be required for
recovery from a transaction failure or system crash. We can expand the log
entries so that they also include the account number of the user and the online
computer or device ID that applied each operation recorded in the log. If any
tampering with the database is suspected, a database audit is performed, which consists of reviewing the log to
examine all accesses and operations applied to the database during a certain
time period. When an illegal or unauthorized operation is found, the DBA can
determine the account number used to perform the operation. Database audits are
particularly important for sensitive databases that are updated by many
transactions and users, such as a banking database that is updated by many bank
tellers. A database log that is used mainly for security purposes is sometimes
called an audit trail.
5. Sensitive Data and Types of Disclosures
Sensitivity
of data is a measure of the
importance assigned to the data by its owner, for the purpose of denoting its need for protection. Some
databases contain only sensitive data while other databases may contain no
sensitive data at all. Handling databases that fall at these two extremes is
relatively easy, because these can be cov-ered by access control, which is
explained in the next section. The situation becomes tricky when some of the
data is sensitive while other data is not.
Several factors can cause data to be classified
as sensitive:
Inherently sensitive. The value of the data itself may be so
revealing or con-fidential that it becomes sensitive—for example, a person’s
salary or that a patient has HIV/AIDS.
From a sensitive source. The source of the data may indicate a need for secrecy—for example, an informer whose
identity must be kept secret.
Declared sensitive. The owner of the data may have explicitly declared
it as sensitive.
A sensitive attribute or sensitive record. The particular attribute or record may have been declared sensitive—for
example, the salary attribute of an employee or the salary history record in a
personnel database.
Sensitive in relation to previously disclosed
data. Some data may not be sensitive by itself but will become
sensitive in the presence of some other data—for example, the exact latitude
and longitude information for a loca-tion where some previously recorded event
happened that was later deemed sensitive.
It is the responsibility of the database
administrator and security administrator to collectively enforce the security
policies of an organization. This dictates whether access should be permitted
to a certain database attribute (also known as a table col-umn or a data
element) or not for individual users or for categories of users. Several factors need to be considered before
deciding whether it is safe to reveal the data. The three most important
factors are data availability, access acceptability, and authenticity
assurance.
Data
availability. If a
user is updating a field, then this field becomes inaccessible and other users
should not be able to view this data. This blocking is only temporary and only
to ensure that no user sees any inaccurate data. This is typically handled by
the concurrency control mechanism (see Chapter 22).
Access acceptability. Data should only be revealed to authorized
users. A database administrator may
also deny access to a user request even if the request does not directly access
a sensitive data item, on the grounds that the requested data may reveal
information about the sensitive data that the user is not authorized to have.
Authenticity assurance. Before granting access, certain external
characteristics about the user may also be considered. For example, a user may
only be permitted access during working hours. The system may track previous
queries to ensure that a combination of queries does not reveal sensitive data.
The latter is particularly relevant to statistical database queries (see
Section 24.5).
The term precision,
when used in the security area, refers to allowing as much as possible of the
data to be available, subject to protecting exactly the subset of data that is
sensitive. The definitions of security
versus precision are as follows:
Security: Means of ensuring that data is kept safe from corruption and that access to it is suitably controlled.
To provide security means to disclose only nonsensitive data, and reject any
query that references a sensitive field.
Precision: To protect all sensitive data while disclosing as much
nonsensitive data as possible.
The ideal combination is to maintain perfect
security with maximum precision. If we want to maintain security, some
sacrifice has to be made with precision. Hence there is typically a tradeoff
between security and precision.
6. Relationship
between Information Security versus Information Privacy
The rapid advancement of the use of information
technology (IT) in industry, government, and academia raises challenging
questions and problems regarding the protection and use of personal
information. Questions of who has what rights to information about
individuals for which purposes become
more important as we move toward a world in which it is technically possible to
know just about anything about anyone.
Deciding how to design privacy considerations
in technology for the future includes philosophical, legal, and practical
dimensions. There is a considerable overlap between issues related to access to
resources (security) and issues related to appropriate use of information
(privacy). We now define the difference between security versus privacy.
Security
in information technology refers to many
aspects of protecting a system from
unauthorized use, including authentication of users, information encryption, access
control, firewall policies, and intrusion detection. For our purposes here, we will
limit our treatment of security to the concepts associated with how well a
system can protect access to information it contains. The concept of privacy goes beyond security. Privacy
examines how well the use of personal information that the system acquires
about a user conforms to the explicit or implicit assumptions regarding that
use. From an end user perspective, privacy can be considered from two different
perspectives: preventing storage of
personal information versus ensuring
appropriate use of personal information.
For the purposes of this chapter, a simple but
useful definition of privacy is the ability of individuals to control the
terms under which their personal information is acquired and used. In
summary, security involves technology to ensure that information is
appropriately protected. Security is a required building block for privacy to
exist. Privacy involves mechanisms to support compliance with some basic
principles and other explicitly stated policies. One basic principle is that
people should be informed about information collection, told in advance what
will be done with their information, and given a reasonable opportunity to
approve of such use of the information. A related concept, trust, relates to both security and privacy, and is seen as
increasing when it is perceived that both security and privacy are provided
for.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2023 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.