CS 5950/6030 – Computer Security and Information Assurance Section 6: Database Security Dr. Leszek...

CS 5950/6030 –Computer Security and Information Assurance

Section 6: Database Security

Dr. Leszek LilienDepartment 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. LilienRequests to use original slides for non-profit purposes will be gladly granted upon a written request.

2Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

6. Database Security – Outline - 16.1. Introduction - a DB refresher –

6.2. Security Requirementsa. Physical database integrity requirementsb. Logical database integrity requirementsc. Element integrity requirementsd. Auditability requirementse. Access control requirementsf. User authentication requirementsg. Availability requirements

6.3. Reliability and Integrity

6.4. Sensitive Data

3Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

6. Database Security – Outline -2

6.5. Inference (Inference Problems)Direct attacks / Indirect attacksInferences 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 Databases6.7. Proposals for Multilevel Security

4Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

6.1. Introduction – DB „Refresher”- STUDY 6.1 ON YOUR OWN IF

NEEDED - Terms you know from database courses:

a) Databaseb) Database management system (front end)c) Recordsd) Fields (elements)e) Schema (logical design)f) Subschema (user view)g) Entityh) Attributesi) Relation j) Queries (results in subschema)

5Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Management Challenges Traditional data file environment

Creating database environment

Challenges exisiting structure — requires restructure

Large initial costs, delayed benefits

Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

Source: Laudon & Laudonr

6Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

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

Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y


7Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

File Organization FILE:

Collection of similar RECORDS

DATABASE: Organization’s Electronic Library of FILES Organized to serve business applications

Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y


8Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

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

Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y


9Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Key Field

Field in Each Record Uniquely Identifies THIS Record For RETRIEVAL

UPDATINGSORTING


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

10Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Data redundancy Program / data dependency Lack of flexibility Poor security Lack of data sharing & availability

Problems With Traditional File Environment

Flat FileFlat File


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

11Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Sequential Vs. Direct File Organization

SEQUENTIAL: Tape-oriented; One file follows another--physical sequence

DIRECT: Disk-oriented; Accessible without regard to physical

sequence


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

12Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

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)


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

13Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Direct File Access Method Each record has key field

Key field fed into transformation algorithm

Algorithm generates physical storage location of record (record address)


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

14Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Database Management System (DBMS)

Software to create & maintain data

Enables business apps to extract data

Independent of specific computer programs

DBMSSource: Laudon & Laudonr

Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

15Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

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


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

16Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Structured Query Language (SQL)

Emerging standard Data manipulation language For relational databases


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

17Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

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:

SELECT (name, phone)FROM employees_tableWHERE employer = ‘MWU’ and city =

‘Kalamazoo’

DBMS

Source: Laudon & Laudon

Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

18Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

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


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

19Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Storage Hierarchy

BIT

BYTE

FIELD

RECORD

FILE

DATABASE


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

20Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Relational Data Model

Data in table format RELATION: Table TUPLE: Row (record) in table FIELD: Column (attribute) in table

HOURS RATE TOTALABLE 40.50$ 10.35$ 419.18$

BAXTER 38.00$ 8.75$ 332.50$ CHEN 42.70$ 9.25$ 394.98$

DENVER 35.90$ 9.50$ 341.05$ Source: Laudon & Laudonr

Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

21Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Types Of Relations

ONE-TO-ONE: ONE-TO-ONE: STUDENT ID

ONE-TO-MANY:ONE-TO-MANY:CLASS

STUDENTA

STUDENTB

STUDENTC

MANY-TO-MANY:MANY-TO-MANY:

STUDENTA

STUDENTB

STUDENTC

CLASS1

CLASS2


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

22Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

ROOT

1stChild

2nd Child

RatingsRatings SalarySalary

CompensationCompensation JobJobAssignmentsAssignments

PensionPension InsurInsuranceance HealthHealth

BenefitsBenefits

EmployerEmployer

Hierarchical Data Model


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

23Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Network Data Model

Variation of hierarchical model Best suited for many-to-many relationships

NETWORKA

NETWORKB

NETWORKC

NETWORK1

NETWORK2

Source: Laudon & Laudon

cf:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

24Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Other Systems

LEGACY SYSTEM: older system

OBJECT - ORIENTED DBMS: stores data & procedures as objects

OBJECT - RELATIONAL DBMS: hybrid


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

25Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Creating a Database

Conceptual Design

Physical Design


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

26Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Creating a Database — Conceptual Design

Abstract model, business perspective

How will data be grouped?

Relationships among elements

Establish end-user needs


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

27Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Detailed model by database specialists

Entity-relationship diagram

Normalization

Hardware / software specific

Creating a Database — Physical Design


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

28Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Elements Of Database Environment

DATABASE MANAGEMENT

SYSTEM

DATA

ADMINISTRATION DATABASE

TECHNOLOGY & MANAGEMENT

USERS

DATA PLANNING & MODELING

METHODOLOGY


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

29Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Entity- Relationship Diagram

1

1

M

1

ORDER

CAN HAVE

PART

SUPPLIER

CAN HAVE

ORDER: #, DATE, PART #, QUANTITY

PART: #, DESCRIPTION, UNIT PRICE, SUPPLIER #

SUPPLIER: #, NAME, ADDRESS Source: Laudon & Laudonr

Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

30Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Normalization

= Process of creating small data structures from complex groups of data

EXAMPLES: Accounts Receivable Personnel Records Payroll


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

31Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

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


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

32Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

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


cf:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

33Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Database Trends - 1 Multidimensional Data Analysis:

3D (or higher dimension) groupings to store complex data

Hypermedia: Nodes contain text, graphics, sound, video,

programs Organizes data as nodes


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

34Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

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


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

35Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Components of Data Warehouse

INFORMATIONDIRECTORY

INTERNALDATASOURCES

EXTERNALDATASOURCES

OPERATIONAL,HISTORICAL DATA

DATA WAREHOUSE

EXTRACT,TRANSFORM

DATAACCESS &ANALYSIS

QUERIES &REPORTS

OLAP

DATA MINING


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

36Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Database Trends -3

DATA MART: Small data warehouse for special function

E.g., focused marketing based on customer info

DATA MINING: Tools for finding hidden patterns, relationships, for predicting trends, etc.


cf:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

37Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Database Trends - 4

Linking Databases to The Web: Web user connects to vendor database

Special software converts users query ‘in’ html to SQL

SQL finds data, server converts result to HTML


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

38Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

6.2. Security Requirements Security requirements for databases and DBMSs:

a. Physical database integrity requirements DB immune to physical problems (e.g., power failure, flood)

b. Logical database integrity requirements DB structure preserved (e.g., update of a field doen’t affect

another)

c. Element integrity requirements Accuracy of values of elements

d. Auditability requirements Able to track who accessed (read, wrote) what

e. Access control requirements Restricts DB access (read, write) to legitinmate users

f. User authentication requirements Only authorized users can access DB

g. Availability requirements DB info available to all authorized users 24/7

cf:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

Source: Pfleeger &

Pfleeger

39Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

--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

Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

Source: Pfleeger & Pfleeger

40Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

66.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 DBMSa) File back upsb) Access controlsc) Integrity checks

DBMS needs more CIA controlsa) E.g. two-phase commit protocols for updatesb) Redundancy/internal consistency controlsc) DB recoveryd) Concurrency/consistency controle) Monitors to enforce DB constraints

Range, state, transition constraints Control structural DB integrity

Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y


41Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

--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 phaseSource: Pfleeger & Pfleeger

Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

42Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

--SKIP-- b)-e) Detecting Inconsistenciesb) Redundancy/internal consistency controls

Error detection / error correction Hamming codes Parity bits Cyclic redundancy check

Shadow fieldsc) DB recovery

Uses DBMS access logd) Concurrency control

Checks/enforcemente) Monitors for DB constraints

Range comparisons State constraints Transition constraints

More sophisticated


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

43Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

--OPTIONAL-- 6.4. Sensitive Data Managing access

Hiding existence

Sharing vs. confidentiality

Security vs. precision Perfect confidentiality Maximum precision


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

44Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

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 inferSource: Pfleeger & Pfleeger

cf:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

45Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Indirect Information Flow Channels

Indirect Information Flow Channels1) Covert channels

Discussed earlier –in the general context of program security

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

cf:

Pro

f. C

silla

Fa

rkas

46Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Inference Controls - Outline1) 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)


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

47Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Database Inference Problem & Types DB inference problem:

where meta-data: Working knowledge about the attributes Supplementary knowledge (not stored in database)

DB inference types:1) Statistical database inferences2) General-purpose database inferences

+ Meta-data Sensitive information

Non-sensitive

information =cf:

Pro

f. C

silla

Fa

rkas

48Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

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

cf:

Pro

f. C

silla

Fa

rkas

49Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

--OPTIONAL-- Types of Statistics

Macro-statistics: collections of related statistics presented in 2-dimensional tables

Micro-statistics: Individual data records used for statistics after identifying information is removed

Sex\Year 1997 1998 Sum

Female 4 1 5

Male 6 13 19

Sum 10 14 24

Sex Course GPA Year

F CSCE 590 3.5 2000

M CSCE 590 3.0 2000

F CSCE 790 4.0 2001

cf:

Pro

f. C

silla

Fa

rkas

50Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

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)

cf:

Pro

f. C

silla

Fa

rkas

51Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Methods of Attacks and Protection

Small/Large Query Set Attack C: characteristic formula that identifies groups of

individualsIf 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

cf:

Pro

f. C

silla

Fa

rkas

52Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Prevention 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, andN 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| 5that 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.)

cf:

Pro

f. C

silla

Fa

rkas

53Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Tracker Attack 1 (simple)

T - Tracker C

C1C2

C = C1 and C2T = C1 and ~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)

Query q(C) is disallowed

cf:

Pro

f. C

silla

Fa

rkas

54Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6--OPTIONAL-- Tracker Attack 2 (more complex)

C = C1 and C2T = C1 and ~C2

TrackerC

C1C2

D

C and D

Query q(C and D)is disallowed

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)

cf:

Pro

f. C

silla

Fa

rkas

55Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

--OPTIONAL-- Query overlap attack

C1 C2

JohnKathy

Max

Fred

EvePaul

Mitch

Q(John)=q(C1)-q(C2)

Protection: need query-overlap control

cf:

Pro

f. C

silla

Fa

rkas

56Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

--OPTIONAL-- Insertion/Deletion Attack

Observing changes over time q1=q(C) Insert(i) q2=q(C) q(i) = q2 „-” q1

where „-” means compensation for insertion that permist to infer

Protection: insertion/deletion performed as pairs

cf:

Pro

f. C

silla

Fa

rkas

57Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

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

cf:

Pro

f. C

silla

Fa

rkas

58Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

2) Inferences in General-Purpose Databases

Inference types:a) Inference via queries based on sensitive datab) Inference via DB constraintsc) Inference via updates

cf:

Pro

f. C

silla

Fa

rkas

59Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6a) Inference via Queries Based

on Sensitive Data Sensitive information is used in selection condition

but not returned to the user

Example: Salary: secret, Name: publicNameSalary=$25,000 (- projection, -

selection)NameSalary=$26,000

• • •

NameSalary=$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

cf:

Pro

f. C

silla

Fa

rkas

60Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

b) Inference via DB Constraints

Database constraints:b-1) Integrity constraintsb-2) DB dependenciesb-3) Key integrity

cf:

Pro

f. C

silla

Fa

rkas

61Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

b-1) Infering via Integrity Constraints

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

62Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

b-2) Infering via DB Dependencies

DB dependencies (metadata): Functional dependencies Multi-valued dependencies Join dependencies etc.

cf:

Pro

f. C

silla

Fa

rkas

63Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Functional Dependencies 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 infoSecret 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

cf:

Pro

f. C

silla

Fa

rkas

64Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

--OPTIONAL--b-3) 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

cf:

Pro

f. C

silla

Fa

rkas

65Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

--SKIP--Example – Infering via Key Integrity

Name (key)

Salary Address

Black P 38,000 P Columbia S

Red S 42,000 S Irmo S

Secret View

Name (key)

Salary Address

Black P 38,000 P Null P

Public View

cf:

Pro

f. C

silla

Fa

rkas

66Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

--SKIP-- Example (ctd) - Updates

Public User:

Name (key)

Salary Address

Black P 38,000 P Null P 1. Update Black’s address to Orlando2. Add new tuple: (Red, 22,000, Manassas)IfRefuse update => covert channelAllow update =>• Overwrite high data – may be incorrect• Create new tuple – which data it correct

(polyinstantiation) – violate key constraintspolyinstantiation – given record instantiated many times, each time with different security level

cf:

Pro

f. C

silla

Fa

rkas

67Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

--SKIP-- Example (ctd) - Updates

Name (key)

Salary Address

Black P 38,000 P Columbia S

Red S 42,000 S Irmo S

Secret user:

1. Update Black’s salary to 45,000IfRefuse update => denial of serviceAllow update =>• Overwrite ‘low’ data – covert channel• Create new tuple – which data it corrects

(polyinstantiation) – violate key constraintspolyinstantiation – given record instantiated many times, each time with different security level

cf:

Pro

f. C

silla

Fa

rkas

68Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

Conclusions on Inference

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


cf:

Pro

f. C

. Fa

rkas

an

d B

. En

dic

ott

-Pop

ovsk

y

69Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

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 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


of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

70Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

--OPTIONAL-- 6.7. Proposals for Multilevel Security - Separation Mechanisms1) 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


cf:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

71Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

--OPTIONAL-- Implementations of Separation - 11) 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)


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

72Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

--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


Cou

rtesy

of:

Pro

f. B

arb

ara

En

dic

ott

-Pop

ovsk

y

73Sect

ion

6 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

– S

pri

ng

2

00

6

End of Section 6 –Database Security

CS 5950/6030 – Computer Security and Information Assurance Section 6: Database Security Dr. Leszek...

Documents

Transcript of CS 5950/6030 – Computer Security and Information Assurance Section 6: Database Security Dr. Leszek...