Transcript Lecture 6 - The University of Texas at Dallas

Data and Applications Security
Developments and Directions
Dr. Bhavani Thuraisingham
The University of Texas at Dallas
Lecture #4
Multilevel Secure Data Management
January 28, 2008
Outline
 What is an MLS/DBMS?
 Summary of Developments
 Challenges
 MLS/DBMS Designs and Prototypes
 Data Models and Functions
 Directions
What is an MLS/DBMS?
 Users are cleared at different security levels
 Data in the database is assigned different sensitivity levels--
multilevel database
 Users share the multilevel database
 MLS/DBMS is the software that ensures that users only
obtain information at or below their level
 In general, a user reads at or below his level and writes at his
level
Why MLS/DBMS?
 Operating systems control access to files; coarser grain of
granularity
 Database stores relationships between data
 Content, Context, and Dynamic access control
 Traditional operating systems access control to files is not
sufficient
 Need multilevel access control for DBMSs
Summary of Developments
 Early Efforts 1975 – 1982; example: Hinke-Shafer approach
 Air Force Summer Study, 1982
 Research Prototypes (Integrity Lock, SeaView, LDV, etc.);
1984 - Present
 Trusted Database Interpretation; published 1991
 Commercial Products; 1988 - Present
Air Force Summer Study
 Air Force convened a summer study to investigate
MLS/DBMS designs
 Then study was divided into three groups focusing on
different aspects
 Group 1 investigated the Integrity Lock approach; Trusted
subject approach and Distributed approach
 Group 2 investigated security for military messaging
systems
 Group 3 focused on longer-term issues such as inference
and aggregation
Outcome of the Air Force Summer Study
 Report published in 1983
 MITRE designed and developed systems based on Integrity
Lock and Trust subject architectures 1984 - 1986
 Rome Air Development Center (RADC, now Air Force
Research Lab) funded efforts to examine long-term
approaches; example: SeaView and LDV both intended to be
A1 systems
 RADC also funded efforts to examine the distributed
approach
 Several prototypes and products followed
TDI
 Trusted Database Interpretation is the Interpretation of the
Trusted Computer Systems Evaluation criteria to evaluate
commercial products
 Classes C1, C2, B1, B2, B3, A1 and Beyond
 TCB (Trusted Computing Base Subsetting) for MAC, DAC,
etc. (mandatory access control, discretionary access
control)
 Companion documents for Inference and Aggregation,
Auditing, etc.
Taxonomy for MLS/DBMSs
 Integrity Lock Architecture: Trusted Filter; Untrusted Back-end, Untrusted
Front-end. Checksum is computed by the filter based on data content and
security level. Checksum recomputed when data is retrieved.
 Operating Systems Providing Access Control/ Single Kernel: Multilevel data
is partitioned into single level files. Operating system controls access to the
filed
 Extended Kernel: Kernel extensions for functions such as inference and
aggregation and constraint processing
 Trusted Subject: DBMS provides access control to its own data such as
relations, tuples and attributes
 Distributed: Data is partitioned according to security levels; In the partitioned
approach, data is not replicated and there is one DBMS per level. In the
replicated approach lower level data is replicated at the higher level
databases
Integrity Lock
Trusted Agent
to compute
checksums
Sensor
Untrusted
Compute Checksum
Based on stream data value
and Security level;
Store data value,
Security level and Checksum
Data Manager
Database
Compute Checksum
Based on data value
and Security level retrieved
from the stored database
Operating System Providing Mandatory
Access Control
Unclassified
device
Secret
device
TopSecret
device
Multilevel
Data Manager
Unclassified
Data
Secret
Data
TopSecret
Data
Extended Kernel
Kernel Extensions
To enforce additional
security policies enforced on data
e.g., security constraints, privacy constraints, etc.
Multilevel
Data Manager
Multilevel
Data
Trusted Subject
Unclassified
device
Secret
device
Multilevel
Data Manager
Trusted
Component
Multilevel
Data
TopSecret
device
Distributed Approach - I
Trusted Agent
to manage
Aggregated Data
Unclassified
Secret
Data Manager
Data Manager
Unclassified
Data
Secret
Data
TopSecret
Data Manager
TopSecret
Data
Distributed Approach II
Trusted Agent
to manage
Aggregated Data
Unclassified
Secret
Data Manager
Data Manager
Unclassified
Data
Secret + Unclassified
Data
TopSecret
Data Manager
TopSecret
Secret +
Unclassified
Data
Overview of MLS/DBMS Designs
 Hinke-Schaefer (SDC Corporation) Introduced operating system
providing mandatory access control
 Integrity Lock Prototypes: Two Prototypes developed at MITRE using
Ingres and Mistress relational database systems
 SeaView: Funded by Rome Air Development Center (RADC) (now Air
Force Rome Laboratory) and used operating system providing
mandatory access control and introduced polyinstation
 Lock Data Views (LDV) : Extended kernel approach developed by
Honeywell and funded by RADC and investigated inference and
aggregation
Overview of MLS/DBMS Designs (Concluded)
 ASD, ASD-Views: Developed by TRW based on the Trusted
subject approach. ASD Views provided access control on views
 SDDBMS: Effort by Unisys funded by RADC and investigated the
distributed approach
 SINTRA: Developed by Naval Research Laboratory based on the
replicated distributed approach
 SWORD: Designed at the Defense Research Agency in the UK
and there goal was not to have polyinstantiation
Some MLS/DBMS Commercial Products Developed
(late 1980s, early 1990s)
 Oracle (Trusted ORACLE7 and beyond): Hinke-Schafer and Trusted Subject
based architectures
 Sybase (Secure SQL Server): Trusted subject
 ARC Professional Services Group (TRUDATA/SQLSentry): Integrity Lock
 Informix (Informix-On-LineSecure): Trusted Subject
 Digital Equipment Corporation (SERdb) (this group is now part of Oracle
Corp): Trusted Subject
 InfoSystems Technology Inc. (Trusted RUBIX): Trusted Subject
 Teradata (DBC/1012): Secure Database Machine
 Ingres (Ingres Intelligent Database): Trusted Subject
Some Challenges: Inference Problem
 Inference is the process of forming conclusions from premises
 If the conclusions are unauthorized, it becomes a problem
 Inference problem in a multilevel environment
 Aggregation problem is a special case of the inference
problem - collections of data elements is Secret but the
individual elements are Unclassified
 Association problem: attributes A and B taken together is
Secret - individually they are Unclassified
Some Challenges: Polyinstantiation
 Mechanism to avoid certain signaling channels
 Also supports cover stories
 Example: John and James have different salaries at
different levels
EMP
SS#
Name
1
2
3
1
4
3
John
Paul
James
John
Mary
James
Salary
20
30
40
70
80
60
Level
U
U
U
S
S
S
Some Challenges: Covert Channel
 Database transactions manipulate data locks and covertly
pass information
 Two transactions T1 and T2; T1 operates at Secret level and T2
operates at Unclassified level
 Relation R is classified at Unclassified level
 T1 obtains read lock on R and T2 obtains write lock on R
 T1 and T2 can manipulate when they request locks and signal
one bit information for each attempt and over time T1 could
covertly send sensitive information to T1
Overview of MLS/DBMS Designs
 Hinke-Schaefer (SDC Corporation) Introduced operating system
providing mandatory access control
 Integrity Lock Prototypes: Two Prototypes developed at MITRE using
Ingres and Mistress relational database systems
 SeaView: Funded by Rome Air Development Center (RADC) (now Air
Force Rome Laboratory) and used operating system providing
mandatory access control and introduced polyinstation
 Lock Data Views (LDV) : Extended kernel approach developed by
Honeywell and funded by RADC and investigated inference and
aggregation
Overview of MLS/DBMS Designs (Concluded)
 ASD, ASD-Views: Developed by TRW based on the Trusted
subject approach. ASD Views provided access control on views
 SDDBMS: Effort by Unisys funded by RADC and investigated the
distributed approach
 SINTRA: Developed by Naval Research Laboratory based on the
replicated distributed approach
 SWORD: Designed at the Defense Research Agency in the UK
and there goal was not to have polyinstantiation
Some MLS/DBMS Commercial Products Developed
(late 1980s, early 1990s)
 Oracle (Trusted ORACLE7 and beyond): Hinke-Schafer and Trusted Subject
based architectures
 Sybase (Secure SQL Server): Trusted subject
 ARC Professional Services Group (TRUDATA/SQLSentry): Integrity Lock
 Informix (Informix-On-LineSecure): Trusted Subject
 Digital Equipment Corporation (SERdb) (this group is now part of Oracle
Corp): Trusted Subject
 InfoSystems Technology Inc. (Trusted RUBIX): Trusted Subject
 Teradata (DBC/1012): Secure Database Machine
 Ingres (Ingres Intelligent Database): Trusted Subject
Some Challenges: Inference Problem
 Inference is the process of forming conclusions from premises
 If the conclusions are unauthorized, it becomes a problem
 Inference problem in a multilevel environment
 Aggregation problem is a special case of the inference
problem - collections of data elements is Secret but the
individual elements are Unclassified
 Association problem: attributes A and B taken together is
Secret - individually they are Unclassified
Some Challenges: Polyinstantiation
 Mechanism to avoid certain signaling channels
 Also supports cover stories
 Example: John and James have different salaries at
different levels
EMP
SS#
Name
1
2
3
1
4
3
John
Paul
James
John
Mary
James
Salary
20
30
40
70
80
60
Level
U
U
U
S
S
S
Some Challenges: Covert Channel
 Database transactions manipulate data locks and covertly
pass information
 Two transactions T1 and T2; T1 operates at Secret level and T2
operates at Unclassified level
 Relation R is classified at Unclassified level
 T1 obtains read lock on R and T2 obtains write lock on R
 T1 and T2 can manipulate when they request locks and signal
one bit information for each attempt and over time T1 could
covertly send sensitive information to T1
Multilevel Secure Data Model:
Classifying Databases
DATABASE D: Level = Secret
EMP
SS# Ename
DEPT
Salary
D#
D#
Dname
Mgr
1
John
20K
10
10
Math
Smith
2
Paul
30K
20
20
Physics
Jones
3
Mary
40K
20
Multilevel Secure Data Model:
Classifying Relations
EMP: Level = Secret
SS# Ename
DEPT: Level = Unclassified
Salary
D#
D#
Dname
Mgr
1
John
20K
10
10
Math
Smith
2
Paul
30K
20
20
Physics
Jones
3
Mary
40K
20
Multilevel Secure Data Model:
Classifying Attributes/Columns
EMP
SS#: S Ename: U
DEPT
Salary: S D#: U
D#: U
Dname: U
Mgr: S
1
John
20K
10
10
Math
Smith
2
Paul
30K
20
20
Physics
Jones
3
Mary
40K
20
U = Unclassified
S = Secret
Multilevel Secure Data Model:
Classifying Tuples/Rows
EMP
SS# Ename
DEPT
Salary
D#
Level
D#
Dname
Mgr
Level
1
John
20K
10
U
10
Math
Smith
U
2
Paul
30K
20
S
20
Physics
Jones
C
3
Mary
40K
20
TS
U = Unclassified
C = Confidential
S = Secret
TS = TopSecret
Multilevel Secure Data Model:
Classifying Elements
EMP
SS#:
DEPT
Ename:
Salary
D#:
1, S
John, U
20K, C
10, U
2, S
Paul, U
30K, S
3, S
Mary, U
40K, S
D#: U
Dname: U
Mgr: S
10, U
Math, U
Smith, C
20, U
20, U
Physics, U
Jones, S
20, U
U = Unclassified
C = Confidential
S = Secret
Multilevel Secure Data Model:
Classifying Views
SECRET VIEW EMP (D# = 20)
SS#
EMP
SS#
Ename
Salary
D#
1
John
20K
10
2
Paul
30K
20
3
Mary
40K
20
4
Jane
20K
20
Ename
Salary
2
Paul
30K
3
Mary
40K
4
Jane
20K
1
Michelle
30K
UNCLASSIFIED VIEW EMP (D# = 10)
5
Bill
20K
10
6
Larry
20K
10
1
Michelle
30K
20
SS#
Ename
1
John
Salary
20K
5
Bill
20K
6
Larry
20K
Multilevel Secure Data Model:
Classifying Metadata
Relation REL
Relation
EMP
EMP
EMP
EMP
DEPT
DEPT
DEPT
Attribute
SS#
Ename
Salary
D#
D#
Dname
Mgr
Level
Secret
Unclassified
Confidential
Unclassified
Unclassified
Unclassified
Confidential
MLS/DBMS Functions
Overview
Multilevel Secure Database Functions:
Query Processing: Enforce mandatory access control rules during
query processing; inference control; consider security
constraints for query optimization
Transaction management: Check whether security constraints
are satisfied during transaction execution; Concurrency control
algorithms that prevent covert challenges; Ensure actions of higher
level processes do not affect those of lower level processes
Metadata management: Classify metadata in such a way that
information is not leaked to lower levels
Storage management: Ensure that security levels are assigned to
storage structures so that information is not leaked to lower levels
Integrity management: Example: payload problem. Ensure that
integrity constraints enforced at lower level do not take into
consideration high level data
MLS/DBMS Functions
Secure Query Processing
Secure User
Interface
Manager
Query
Modifier
Secure Query
Transformer
Secure
Database
Response
Manager
Secure Query
Optimizer
Secure Storage
Manager
MLS/DBMS Functions
Secure Transaction Management
O is updated to
O’’
Unclassified
Object O
Unclassified Process
reads from and writes
into the object O’
O* is a copy of
O”. Essentially O’ is
updated to O* at the
Secret level
Copy O’ of
Object O
At the Secret level
Secret Process reads from
The object O’
MLS/DBMS Functions
Secure Integrity Management
Integrity Management:
TopSecret Constraint: Maximum weight of an aircraft is 1000 lbs
Unclassified level: Weights are added but the TopSecret constraint
is not visible;
Unclassified level there is no constraint
Problem: If TopSecret constraint is checked at the Unclassified level
it is a security violation; if not it could cause serious integrity
Problems
Challenge: Enforce constraints in such a away that high level
constraints do not affect lower level operations
Polyinstantiaon also introduces integrity problems
Status and Directions
 MLS/DBMSs have been designed and developed for various
kinds of database systems including object systems,
deductive systems and distributed systems
 Provides an approach to host secure applications
 Can use the principles to design privacy preserving database
systems
 Challenge is to host emerging secure applications including e-
commerce and biometrics systems