Transcript Section 6: Database Security - Computer Science

CS 5950/6030 –
Computer Security and Information Assurance
Section 6: Database Security
Dr. Leszek Lilien
Department of Computer Science
Western Michigan University
Slides based on Security in Computing. Third Edition by Pfleeger and Pfleeger.
Using some slides courtesy of:
Prof. Barbara Endicott-Popovsky and Prof. Deborah Frincke (U. Idaho) — taught at U. Washington
Prof. Csilla Farkas— course taught at U. of South Carolina
Slides not created by the above authors are © 2006 by Leszek T. Lilien
Requests to use original slides for non-profit purposes will be gladly granted upon a written request.
6. Database Security – Outline - 1
Section 6 – Computer Security and Information Assurance – Spring 2006
6.1. Introduction - a DB refresher –
6.2. Security Requirements
a. Physical database integrity requirements
b. Logical database integrity requirements
c. Element integrity requirements
d. Auditability requirements
e. Access control requirements
f. User authentication requirements
g. Availability requirements
6.3. Reliability and Integrity
6.4. Sensitive Data
2
Section 6 – Computer Security and Information Assurance – Spring 2006
6. Database Security – Outline -2
6.5. Inference (Inference Problems)
Direct attacks / Indirect attacks
Inferences in statistical DBs (incl. small/large query set
attacks, tracker attacks, query overlap attacks,
insertion/deletion attacks)
Inferences in general-purpose DBs (incl. inferences via
queries based on sensitive data, inferences via DB
constraints, inferences via updates)
6.6. Multilevel Databases
6.7. Proposals for Multilevel Security
3
6.1. Introduction – DB „Refresher”
- STUDY 6.1 ON YOUR OWN IF NEEDED -
Section 6 – Computer Security and Information Assurance – Spring 2006

Terms you know from database courses:
a) Database
b) Database management system (front end)
c) Records
d) Fields (elements)
e) Schema (logical design)
f) Subschema (user view)
g) Entity
h) Attributes
i) Relation
j) Queries (results in subschema)
4
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
Management Challenges

Traditional data file environment

Creating database environment

Challenges exisiting structure — requires restructure

Large initial costs, delayed benefits
Source: Laudon & Laudonr
5
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
File Organization

BIT: Binary Digit (0,1; Y,N; On,Off)

BYTE:
Combination of BITS representing a CHARACTER

FIELD:
Collection of BYTES representing a DATUM or Fact

RECORD:
Collection of FIELDS reflecting a TRANSACTION
Source: Laudon & Laudonr
6
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
File Organization


FILE:
Collection of similar RECORDS
DATABASE:
 Organization’s Electronic Library of FILES
 Organized to serve business applications
Source: Laudon & Laudonr
7
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
File Organization



ENTITY:
Person, place, thing, event about which data must be
kept
ATTRIBUTE:
Description of a particular ENTITY
KEY FIELD:
Field used to retrieve, update, sort RECORD
Source: Laudon & Laudonr
8
Courtesy of: Prof. Barbara Endicott-Popovsky
Key Field


Section 6 – Computer Security and Information Assurance – Spring 2006

Field in Each Record
Uniquely Identifies THIS Record
For RETRIEVAL
UPDATING
SORTING
Source: Laudon & Laudonr
9
Courtesy of: Prof. Barbara Endicott-Popovsky
Problems With Traditional File
Environment

Section 6 – Computer Security and Information Assurance – Spring 2006




Data redundancy
Program / data dependency
Lack of flexibility
Poor security
Lack of data sharing & availability
Flat File
Source: Laudon & Laudonr
10
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
Sequential Vs. Direct File Organization


SEQUENTIAL:
 Tape-oriented;
 One file follows another--physical sequence
DIRECT:
 Disk-oriented;
 Accessible without regard to physical sequence
Source: Laudon & Laudonr
11
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
Filing Methods


Indexed sequential access method (ISAM) :

Each record identified by key

Grouped in blocks and cylinders

Keys in index
Virtual storage access method (VSAM) :

Memory divided into areas & intervals

Dynamic file space
VSAM widely used for relational DBs

Direct file access method (next)
Source: Laudon & Laudonr
12
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
Direct File Access Method

Each record has key field

Key field fed into transformation algorithm

Algorithm generates physical storage location of record
(record address)
Source: Laudon & Laudonr
13
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
Database Management System
(DBMS)

Software to create & maintain data

Enables business apps to extract data

Independent of specific computer programs
DBMS
Source: Laudon & Laudonr
14
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
Components of DBMSs



DATA DEFINITION LANGUAGE:
 Defines data elements in database
DATA MANIPULATION LANGUAGE:
 Manipulates data for applications
DATA DICTIONARY:
 Formal definitions of all variables in database
 Controls variety of database contents
 Data elements
DBMS
Source: Laudon & Laudonr
15
Courtesy of: Prof. Barbara Endicott-Popovsky
Structured Query Language (SQL)


Section 6 – Computer Security and Information Assurance – Spring 2006

Emerging standard
Data manipulation language
For relational databases
DBMS
Source: Laudon & Laudonr
16
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
Elements Of SQL




SELECT:
List of columns from tables desired
FROM:
IDs tables from which columns will be selected
WHERE:
Includes conditions for selecting specific rows, conditions
for joining multiple tables
Example:
Source: Laudon & Laudon
DBMS
SELECT (name, phone)
FROM employees_table
WHERE employer = ‘MWU’ and city = ‘Kalamazoo’
17
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
Two Views Of Data


PHYSICAL VIEW: Where is data physically?

Drive, disk, surface, track, sector (block), record

Tape, block, record number (key)
LOGICAL VIEW: What data is needed by application?

Succession of facts needed by application

Name, type, length of field
DBMS
Source: Laudon & Laudonr
18
Section 6 – Computer Security and Information Assurance – Spring 2006
Courtesy of: Prof. Barbara Endicott-Popovsky
Storage Hierarchy
BIT
BYTE
FIELD
RECORD
FILE
DATABASE
Source: Laudon & Laudonr
19
Courtesy of: Prof. Barbara Endicott-Popovsky
Relational Data Model


Section 6 – Computer Security and Information Assurance – Spring 2006


Data in table format
RELATION: Table
TUPLE: Row (record) in table
FIELD: Column (attribute) in table
HOURS
ABLE
$ 40.50
BAXTER $ 38.00
CHEN
$ 42.70
DENVER $ 35.90
RATE
$ 10.35
$ 8.75
$ 9.25
$ 9.50
TOTAL
$ 419.18
$ 332.50
$ 394.98
$ 341.05
Source: Laudon & Laudonr
20
Courtesy of: Prof. Barbara Endicott-Popovsky
Types Of Relations
ONE-TO-ONE:
STUDENT
CLASS
Section 6 – Computer Security and Information Assurance – Spring 2006
ONE-TO-MANY:
STUDENT
A
MANY-TO-MANY:
ID
STUDENT
B
CLASS
1
STUDENT
A
STUDENT
C
CLASS
2
STUDENT
B
STUDENT
C
Source: Laudon & Laudonr
21
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
Hierarchical Data Model
ROOT
1st
Child
Employer
Compensation
2nd
Ratings
Child
Job
Assignments
Salary
Benefits
Pension Insurance Health
Source: Laudon & Laudonr
22
cf: Prof. Barbara Endicott-Popovsky
Network Data Model

Section 6 – Computer Security and Information Assurance – Spring 2006

Variation of hierarchical model
Best suited for many-to-many relationships
NETWORK
1
NETWORK
A
NETWORK
2
NETWORK
B
NETWORK
C
Source: Laudon & Laudon
23
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
Other Systems



LEGACY SYSTEM: older system
OBJECT - ORIENTED DBMS:
stores data & procedures as objects
OBJECT - RELATIONAL DBMS: hybrid
Source: Laudon & Laudonr
24
Section 6 – Computer Security and Information Assurance – Spring 2006
Courtesy of: Prof. Barbara Endicott-Popovsky
Creating a Database

Conceptual Design

Physical Design
Source: Laudon & Laudonr
25
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
Creating a Database —
Conceptual Design

Abstract model, business perspective

How will data be grouped?

Relationships among elements

Establish end-user needs
Source: Laudon & Laudonr
26
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
Creating a Database —
Physical Design

Detailed model by database specialists

Entity-relationship diagram

Normalization

Hardware / software specific
Source: Laudon & Laudonr
27
Courtesy of: Prof. Barbara Endicott-Popovsky
Elements Of Database Environment
DATA
DATABASE
TECHNOLOGY &
MANAGEMENT
Section 6 – Computer Security and Information Assurance – Spring 2006
ADMINISTRATION
DATABASE
MANAGEMENT
SYSTEM
DATA PLANNING
& MODELING
METHODOLOGY
USERS
Source: Laudon & Laudonr
28
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
Entity- Relationship Diagram
ORDER
ORDER: #, DATE, PART #, QUANTITY
1
CAN
HAVE
1
PART: #, DESCRIPTION, UNIT PRICE,
SUPPLIER #
PART
M
CAN
HAVE
1
SUPPLIER
SUPPLIER: #, NAME,
ADDRESS
Source: Laudon & Laudonr
29
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
Normalization
= Process of creating small data structures
from complex groups of data



EXAMPLES:
Accounts Receivable
Personnel Records
Payroll
Source: Laudon & Laudonr
30
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
Distributed Databases


PARTITIONED:
remote CPUs (connected to host) have files unique to
that site,
e.g., records on local customers
REPLICATED (DUPLICATED as a special case)
ea. remote CPU has copies of common files
e.g., layouts for standard reports and forms
Source: Laudon & Laudonr
31
cf: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
Database Administration

A person or a group of people

Defines / organizes database structure and content

Develops security procedures

Develops database documentation

Maintains DBMS

E.g., software patches and updates
Source: Laudon & Laudonr
32
Courtesy of: Prof. Barbara Endicott-Popovsky
Database Trends - 1

Section 6 – Computer Security and Information Assurance – Spring 2006

Multidimensional Data Analysis:
3D (or higher dimension) groupings to store complex data
Hypermedia:
 Nodes contain text, graphics, sound, video,
programs
 Organizes data as nodes
Source: Laudon & Laudonr
33
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
Database Trends - 2


Data Warehouse:
Organization’s electronic library stores consolidated
current & historic data for management reporting &
analysis
On-Line Analytical Processing (OLAP):
Tools for multi-dimensional data analysis
Source: Laudon & Laudonr
34
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
Components of Data Warehouse
OPERATIONAL,
HISTORICAL DATA
INTERNAL
DATA
SOURCES
DATA WAREHOUSE
DATA
ACCESS &
ANALYSIS
EXTRACT,
TRANSFORM
INFORMATION
DIRECTORY
EXTERNAL
DATA
SOURCES
QUERIES &
REPORTS
OLAP
DATA MINING
Source: Laudon & Laudonr
35
cf: Prof. Barbara Endicott-Popovsky
Database Trends -3

DATA MART:
Small data warehouse for special function
Section 6 – Computer Security and Information Assurance – Spring 2006


E.g., focused marketing based on customer info
DATA MINING:
Tools for finding hidden patterns, relationships, for
predicting trends, etc.
Source: Laudon & Laudonr
36
Courtesy of: Prof. Barbara Endicott-Popovsky
Database Trends - 4
Linking Databases to The Web:
 Web user connects to vendor database
Section 6 – Computer Security and Information Assurance – Spring 2006


Special software converts users query ‘in’ html to SQL
SQL finds data,
server converts result to HTML
Source: Laudon & Laudonr
37
cf: Prof. Barbara Endicott-Popovsky
6.2. Security Requirements

Security requirements for databases and DBMSs:
a. Physical database integrity requirements

b.
(e.g., power failure, flood)
Logical database integrity requirements

c.
Section 6 – Computer Security and Information Assurance – Spring 2006
DB immune to physical problems
DB structure preserved
(e.g., update of a field doen’t affect another)
Element integrity requirements

d.
Accuracy of values of elements
Auditability requirements

e.
Able to track who accessed (read, wrote) what
Access control requirements

f.
Restricts DB access (read, write) to legitinmate users
User authentication requirements

g.
Only authorized users can access DB
Availability requirements

DB info available to all authorized users 24/7
Source:
Pfleeger &
Pfleeger
38
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
--OPTIONAL– Confident. / Integrity / Availability

Requirements can be rephrased / sumarized as follows:
 Data must be trusted
 DBMS designed to manage trust
 DBMS must reconstruct reality
 Data must be accurate
 Field checks
 Access control (CRUD)

CRUD = Create, Read, Update, and Delete
Change log
Trade-offs
 Audit vs. performance
 Access vs. performance
Self-authentication
High availability




Source: Pfleeger & Pfleeger
39
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
6.3. Reliability and Integrity




Reliable software runs long time without failures
Reliable DBMS preserves:

DB Integrity / Element Integrity / Element Accuracy
Basic protection provided by OS underlying DBMS
a) File back ups
b) Access controls
c) Integrity checks
DBMS needs more CIA controls
a) E.g. two-phase commit protocols for updates
b) Redundancy/internal consistency controls
c) DB recovery
d) Concurrency/consistency control
e) Monitors to enforce DB constraints

Range, state, transition constraints

Control structural DB integrity
Source: Pfleeger & Pfleeger
40
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
--SKIP-- a) Two-Phase Update (2PC)



Intent Phase
 Check value of COMMIT-FLAG
 Gathers resources
 Data
 Dummy records
 Open files
 Lock out others
 Calculate final answers
 Write COMMIT-FLAG
Permanent Change Phase
 Update made
Rollback ability at each phase
Source: Pfleeger & Pfleeger
41
Courtesy of: Prof. Barbara Endicott-Popovsky
--SKIP-- b)-e) Detecting Inconsistencies
b) Redundancy/internal consistency controls
 Error detection / error correction


Section 6 – Computer Security and Information Assurance – Spring 2006

Hamming codes
Parity bits
Cyclic redundancy check
Shadow fields
c) DB recovery
 Uses DBMS access log
d) Concurrency control
 Checks/enforcement
e) Monitors for DB constraints
 Range comparisons
 State constraints
More sophisticated
 Transition constraints

Source: Pfleeger & Pfleeger
42
Courtesy of: Prof. Barbara Endicott-Popovsky
--OPTIONAL-
Managing access

Hiding existence

Section 6 – Computer Security and Information Assurance – Spring 2006
6.4. Sensitive Data

Sharing vs. confidentiality
Security vs. precision

Perfect confidentiality

Maximum precision
Source: Pfleeger & Pfleeger
43
cf: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
6.5. Inference (Inference Problems)


Inference attack - inferring sensitive data
from nonsensitive data
Types of inference attacks:
1) Direct attack
 Infer sens. data from results of queries run by attacker
 n-item k-percent rule:
 Data withheld if n items represent > k percent of
the result reported
 Most obvious case: 1-item 100-percent case: 1
person represents 100 % of results reported
2) Indirect attack
 Infer sens. info from statistics (Sum, Count, Median)
also from info external to the attacked DB
 Tracker attacks (intersection of sets)
 Linear system vulnerability
 Use algebra of multiple equations to infer
Source: Pfleeger & Pfleeger
44
cf: Prof. Csilla Farkas
Indirect Information Flow Channels

Indirect Information Flow Channels
1) Covert channels
 Discussed earlier –
in the general context of program security
Section 6 – Computer Security and Information Assurance – Spring 2006

Recall:
 Overt Channel: designed into a system and documented
 Covert Channel: not documented
Covert channels may be deliberately inserted into a
system, but most are accidents of the system design.
2) Inference channels
 Discussed next–
in the context of DBMS
45
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
Inference Controls - Outline
1) Query controls — applied to queries
 Primarily against direct attacks
 Query analysis to prevent inferences
 Query inventory (history) per person
2) Data item controls —applied to individual DB items

Useful for indirect attacks
 Two types:
a) Suppression — data not provided to querying user


Suppress combinations of rows and columns
Combine results (to hide actual answers)
b) Concealing — close answers, not exact given to
querying user




Rounding
Present range of results
Present random sample results
Perturb random data (generate small + and – error)
Source: Pfleeger & Pfleeger
46
Section 6 – Computer Security and Information Assurance – Spring 2006
cf: Prof. Csilla Farkas
Database Inference Problem & Types

DB inference problem:
Nonsensitive
information
+
Meta-data
=
Sensitive
information
where meta-data:
 Working knowledge about the attributes
 Supplementary knowledge (not stored in database)

DB inference types:
1) Statistical database inferences
2) General-purpose database inferences
47
Section 6 – Computer Security and Information Assurance – Spring 2006
cf: Prof. Csilla Farkas
1) Statistical Database Inference


Statistical database goal: provide aggregate information
about groups of individuals
 E.g., average grade point of students
Security risk in statistical database:
disclosure of specific information about a particular individual
 E.g., grade point of student John Smith
48
Section 6 – Computer Security and Information Assurance – Spring 2006
cf: Prof. Csilla Farkas
--OPTIONAL-

Types of Statistics
Macro-statistics: collections of related statistics presented
in 2-dimensional tables
Sex\Year
1997
1998
Sum
Female
4
1
5
Male
6
13
19
Sum
10
14
24
Micro-statistics: Individual data records used for statistics
after identifying information is removed
Sex
Course
GPA
Year
F
CSCE 590
3.5
2000
M
CSCE 590
3.0
2000
F
CSCE 790
4.0
2001
49
Section 6 – Computer Security and Information Assurance – Spring 2006
cf: Prof. Csilla Farkas
Statistical Compromise


Exact compromise:
Find exact value of an attribute of an individual
 E.g., finding that John Smith’s GPA is 3.8
Partial compromise:
Find an estimate of an attribute value corresponding to an
individual
 E.g., finding that John Smith’s GPA is between 3.5 and
4.0)
50
Section 6 – Computer Security and Information Assurance – Spring 2006
cf: Prof. Csilla Farkas
Methods of Attacks and Protection

Small/Large Query Set Attack
 C: characteristic formula that identifies groups of
individuals
If C identifies a single individual I, e.g., count(C) = 1
Find out existence of another property D for I
 If count(C and D)= 1 means I has property D
 If count(C and D)= 0 means I does not have D
OR
 Find value of property
 Sum(C, D), gives value of D


If value of C known already
51
Prevention
Section 6 – Computer Security and Information Assurance – Spring 2006
cf: Prof. Csilla Farkas



Protection from small/large query set attack:
query-set-size control
A query q(C) is permitted only if
N-n  |C|  n
where:
n  0 is a parameter of the database, and
N is the number of records in the database
E.g. a query q(C) in a DB describing 100 individuals is
permitted only if
100 – 5 = 95  |C|  5
that is if it can’t give statistics on a group smaller than 5
individuals
(Note: If it gives statistics on C for e.g., 96 people, it
gives statistics on not-C for 4 people.)
52
Section 6 – Computer Security and Information Assurance – Spring 2006
cf: Prof. Csilla Farkas
Tracker Attack 1 (simple)
Query q(C) is disallowed
T - Tracker
C1
C = C1 and C2
T = C1 and ~C2
C
C2
Attacker runs instead 2 queries: q(C1) and q(T)
where q(C) = q(C1) – q(T)
=> infers q(C) from q(C1) and q(T)
53
Section 6 – Computer Security and Information Assurance – Spring 2006
cf: Prof. Csilla Farkas
--OPTIONAL--
Tracker Attack 2
(more complex)
Query q(C and D)
is disallowed
C
Tracker
C = C1 and C2
T = C1 and ~C2
C2
C1
C and D
D
Attacker runs instead 2 queries: q(T or C and D) and q(T)
where q(C and D) = q(T or C and D) – q(T)
=> infers q(C and D) from q(T or C and D) and q(T)
54
cf: Prof. Csilla Farkas
--OPTIONAL--
Query overlap attack
Q(John)=q(C1)-q(C2)
C1
C2
Section 6 – Computer Security and Information Assurance – Spring 2006
Kathy
John
Eve
Paul
Max
Fred
Mitch
Protection: need query-overlap control
55
Section 6 – Computer Security and Information Assurance – Spring 2006
cf: Prof. Csilla Farkas
--OPTIONAL--

Observing changes over time
 q1=q(C)
 Insert(i)
 q2=q(C)
 q(i) = q2 „-” q1


Insertion/Deletion Attack
where „-” means compensation for insertion that permist to infer
Protection: insertion/deletion performed as pairs
56
Section 6 – Computer Security and Information Assurance – Spring 2006
cf: Prof. Csilla Farkas
Statistical Inference Theory


Given unlimited number of statistics and correct statistical
answers, all statistical databases can be compromised
[Ullman]
Fortunately:
 Number of statistics can be limited by statistical DB
controls
 Statistical DB can give approximate rather than
‘correct’ statistical answers
57
cf: Prof. Csilla Farkas
Section 6 – Computer Security and Information Assurance – Spring 2006
2) Inferences in General-Purpose
Databases

Inference types:
a) Inference via queries based on sensitive data
b) Inference via DB constraints
c) Inference via updates
58
a) Inference via Queries Based on
Sensitive Data
Section 6 – Computer Security and Information Assurance – Spring 2006
cf: Prof. Csilla Farkas


Sensitive information is used in selection condition but not
returned to the user
Example: Salary: secret, Name: public
NameSalary=$25,000
(- projection,  - selection)
NameSalary=$26,000
•••

NameSalary=$110,000
Sensitive info (salary) used in selection condition, but
not returned to the user



Returns only Name to user
“Infers” (quite mechanically – no intelligence needed) salary for
everybody making between $25,000 and $110,000
Protection: apply query of database views at different
security levels
59
Section 6 – Computer Security and Information Assurance – Spring 2006
cf: Prof. Csilla Farkas
b) Inference via DB Constraints

Database constraints:
b-1) Integrity constraints
b-2) DB dependencies
b-3) Key integrity
60
b-1) Infering via Integrity Constraints


Section 6 – Computer Security and Information Assurance – Spring 2006

C = A+B
A - public, C - public, and B - secret
B can be calculated from A and C
 I.e., secret information can be calculated from public
data
61
Section 6 – Computer Security and Information Assurance – Spring 2006
cf: Prof. Csilla Farkas
b-2) Infering via DB Dependencies
 DB dependencies (metadata):
 Functional dependencies
 Multi-valued dependencies
 Join dependencies
 etc.
62
cf: Prof. Csilla Farkas
Functional Dependencies

Section 6 – Computer Security and Information Assurance – Spring 2006

Functional dependency (FD) for attributes A  B:
For any two tuples in the relation, if they have the same
value for A, they must have the same value for B
Example: Exploiting the FD: Rank  Salary to infer secret
info
Secret information: Name and Salary together
 Query1: Name and Rank
 Query2: Rank and Salary
 Combined answers for Q1 and Q2 reveal Name and
Salary together

Only because we have Rank  Salary
63
cf: Prof. Csilla Farkas
--OPTIONAL--b-3)

Section 6 – Computer Security and Information Assurance – Spring 2006


Infering via Key Integrity
Every tuple in the relation has a unique key
Users at different security levels see different versions of
the database
 User with ‘top secret’ clearance sees more than one
with ‘secret’ clearance
Users might attempt to update data that is not visible for
them
64
Section 6 – Computer Security and Information Assurance – Spring 2006
cf: Prof. Csilla Farkas
--SKIP--Example – Infering via Key Integrity
Secret View
Name (key) Salary
Black P
38,000 P
Red S
42,000 S
Address
Columbia S
Irmo S
Public View
Name (key) Salary
Address
Black P
Null P
38,000 P
65
Section 6 – Computer Security and Information Assurance – Spring 2006
cf: Prof. Csilla Farkas
--SKIP--
Example (ctd) - Updates
Public User:
Name (key) Salary
Black P
38,000 P
Address
Null P
1. Update Black’s address to Orlando
2. Add new tuple: (Red, 22,000, Manassas)
If
Refuse update => covert channel
Allow update =>
• Overwrite high data – may be incorrect
• Create new tuple – which data it correct
(polyinstantiation) – violate key constraints
polyinstantiation – given record instantiated many times,
each time with different security level
66
Section 6 – Computer Security and Information Assurance – Spring 2006
cf: Prof. Csilla Farkas
--SKIP--
Example (ctd) - Updates
Secret user:
Name (key) Salary
Black P
38,000 P
Red S
42,000 S
Address
Columbia S
Irmo S
1. Update Black’s salary to 45,000
If
Refuse update => denial of service
Allow update =>
• Overwrite ‘low’ data – covert channel
• Create new tuple
– which data it corrects
(polyinstantiation)
– violate key constraints
polyinstantiation – given record instantiated many times, each
time with different security level
67
cf: Prof. C. Farkas and B. Endicott-Popovsky
Conclusions on Inference


Section 6 – Computer Security and Information Assurance – Spring 2006



No general technique is available to solve the inference
problems
Need assurance of protection
Hard to incorporate outside knowledge
Optimal plan:
 Suppress obviously sensitive information
 Track what user knows (expensive)
 Disguise data
--OPTIONAL-- Aggregation—additional problem


Inferences from aggregating data
Data mining increases risks
Source: Pfleeger & Pfleeger
68
of: Prof. Barbara Endicott-Popovsky
6.6. Multilevel Databases


Multilevel databases - store data with different
sensitivity levels (e.g.: public, confidential, secret, top_secret)
Problems
 Polyinstantiation – multiple (“poly”) instantiations of a record, each at a
different security level
Section 6 – Computer Security and Information Assurance – Spring 2006



Example:
 [John, Kalamazoo-MI] -- Public level
 [John, 19_Main_Ave-Kalamazoo-MI] -- Confidential level
…
 [John, 19_Main_Ave-Kalamazoo-MI, …, SSN=123-45-6789] -Top_Secret level
-- OPTIONAL below -
Global actions (i.e., backup)

Small items controlled

Cost and performance

Consumer resistance to military model
Granularity

Access control policy

Guarantee values not changed by unauthorized person
Source: Pfleeger & Pfleeger
69
cf: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
6.7. Proposals for Multilevel
Security - Separation Mechanisms
--OPTIONAL--
1) Partitioning
 Redundancy
 Accuracy (multiple field update)
2) Encryption per level
 Cumbersome decrypting with queries
3) Integrity lock
 Data item
 Sensitivity level
 Checksum (above 2)
 Cryptographic checksums
4) Sensitivity lock
 Unique identifier
 Sensitivity level
Source: Pfleeger & Pfleeger
70
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
--OPTIONAL-- Implementations of Separation - 1
1) Integrity lock
 Expands size of element
 Processing time efficiency
 Untrusted DBM subject to Trojan horse
2) Trusted front end
 Guard ~ reference monitor
 One-way filter—filters out reports
 Inefficient—calls, then releases much data
3) Commutative filters
 Interface between user and DB
 Reformats query
 Addresses inefficiencies (above)
Source: Pfleeger & Pfleeger
71
Courtesy of: Prof. Barbara Endicott-Popovsky
Section 6 – Computer Security and Information Assurance – Spring 2006
--OPTIONAL-- Implementations of Separation - 2
4) Distributed DB
 Separate DB’s based on sensitivity
 Front end sends query to right DB
5) Views
 Logical / functional divisions
Source: Pfleeger & Pfleeger 72
Section 6 – Computer Security and Information Assurance – Spring 2006
End of Section 6 –
Database Security
73