Authentication and access control project

ladypatty2003
DataProtectionFeaturesinDatabaseManagementSystems.pdf

Data Protection Features in Database Management Systems

Operating system security mechanisms

typically control read and write access to

entire files, but they cannot be used to

limit access to specific records or fields in

that file. A database management system

(DBMS) typically allows this type of more

detailed access control to be specified.

Definition of Relational Database

A type of database management

system (DBMS) that stores data in

the form of related tables. (A table

describes relationship among

attributes (or entries in its

columns.)

NIST Interagency Report 7693 defines a

database as repository of information or

data, which may or may not be a

traditional relational database system. It

also usually enables access controls to be

specified over a wider range of database

commands, such as select, insert, update,

or delete specified items in the database.

The security services and mechanisms

are more fine-grained in a DBMS than

those provided by a typical operating

system. The most common system is use

today is the relational database

management system (RDBMS).

Relational databases are powerful

because they require few assumptions

about how data is related or how it will

be extracted from the database. As a

result, the same database can be viewed

in many different ways. Modern

databases are generally relational, due to

the much more versatile nature of

relational databases coupled with the

widespread availability of relational

database engines, such as Access and

Oracle.

The relational database model, invented

in 1970 by an IBM mathematician,

remains popular in the field based on the

ability to update, query, and store large

volumes of data. RDBMS software is very

flexible and proficient in handling new

technologies. Current areas of

application include data analytics (e.g.,

artificial intelligence), Internet-of-Things

(IoT) systems, and big data (e.g., data

warehouses, cloud storage).

Sensitive Data

There are two fundamental issues

with sensitive data: how to label it,

and how to decide what individual

users can access.

Sensitivity of data is a confidentiality

issue. People often associate database

confidentiality with the military's

classification scheme: unclassified,

confidential, secret, or top secret. In

reality, database requirements for

sensitive data are much more subtle and

nuanced.

Did You Know?

There are two aspects to database

security: labeling data and

determining access rules.

Several factors go into making data

sensitive, including the data item's

inherent value (e.g., merger decisions,

results of ongoing drug trial), the data

item's source (perhaps from a spy whose

life could be in jeopardy if the source

became known), privacy concerns (e.g.,

health records), or the fact that some

data may become sensitive in

conjunction with other data (e.g., the

time and location of a planned military

attack is much more sensitive than either

one alone).

Definition of Inference

Inference is concerned with the

possibility of inferring or deriving

sensitive (or classified) data from

non-sensitive (or unclassified) data.

Data can be labeled at several levels:

At the field level: Individual fields

(e.g., employee income) may be

labeled as sensitive. The security-

level label can be determined either

by the nature of the field, or by the

content of the field. For example,

maximum altitude capability of an

aircraft might be classified across

the board, or it might only be

classified for certain aircraft (say, an

F-22), but not for other aircraft

(such as a Boeing 737).

At the record level: One

classification approach at the

record level is to use the system-

high model, in which the

classification of a database record is

set at a level corresponding to the

highest field level, also sometimes

referred to as the "high-water

mark." This method, while simple to

implement, might overly restrict

users' access to less sensitive fields

within a record.

At the file (or table) level: Again, a

system-high model might be used,

with the same result of overly

restricting access to a database.

Neither of these is straightforward; some

important subtleties must be considered,

the most important of which is the problem of inference.

For example, using census data showing

an occupation and residential address

might be sufficient information to infer a

household's income. There are typical

attack queries to infer sensitive data.

Two strategies to thwart such attacks are

query control and judicious database

design. Both strategies are difficult to

implement well, and they are topics of

ongoing research.

Statistical databases of interest to us in

this session are databases that support

statistical queries such as count, sum,

max, and average over the result of a

query (query set). The primary concern is

the inference attack. (Inference attacks

on statistical queries are also known as

aggregation attacks because they are on

the aggregated data.) There are two

approaches to minimize inference attacks

in statistical databases:

query restriction to minimize

compromise, and

result perturbation, where query

answers are approximate.

These techniques are not perfect, but

they are often effective.

Database Encryption

Encryption is a powerful tool used in

many databases. As the storage of large volumes of data has shifted to cloud

providers, it turns out a major concern in

cloud computing or outsourcing data

management to outsiders is data

confidentiality.

Encrypting data stored in a cloud

provider is an effective means to address

this concern, but the issue is how to

efficiently query the database when the

fields are encrypted. The NIST document

on cloud computing standards (NIST

SP500-299v2) provides a good overview

of cloud computing service models,

security issues with the various models,

and controls and frameworks needed to

address these security issues.

The government publishes STIGs

(Security Technical Implementation

Guides) detailing the expectations for

hardening computer infrastructure. STIGs

serve as standardized rules for

government networks built using

commercial components, including

operating systems, database

management systems, and

communication systems. The purpose of

the STIGs is to define the usage and

modifications of commercial components

so that environments are configured and

implemented in a highly secure manner.

References

Barker, E., & Roginsky, A. (2011).

National Institute of Standards

and Technology (NIST) SP800-

131A, rev. 2. Transitioning the

Use of Cryptographic Algorithms

and Key Lengths. Retrieved from

https://nvlpubs.nist.gov/nistpubs

/SpecialPublications/NIST.SP.80

0-131Ar2.pdf

National Institute of Standards and

Technology. (2013). NIST Cloud

Computing Standards Roadmap.

SP500-299, ver. 2. Retrieved

from

https://www.nist.gov/document-

4641.

Unclassified DISA STIG List. (2020).

https://www.stigviewer.com/stig

s

Security and Privacy Controls

for Federal Information

Systems and Organizations

© 2021 University of Maryland Global Campus

All links to external sites were verified at the time of

publication. UMGC is not responsible for the validity

or integrity of information located at external sites.

Learning Topic

Print

Take Note

Resources

6/3/21, 1:39 PM Page 1 of 1