Dr. Bhavani Thuraisingham The University of Texas at Dallas (UTD) June 2013
Secure Data Architectures Dr. Bhavani Thuraisingham The University of Texas at Dallas June 2015.
-
Upload
agnes-peters -
Category
Documents
-
view
216 -
download
0
Transcript of Secure Data Architectures Dr. Bhavani Thuraisingham The University of Texas at Dallas June 2015.
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
TDITrusted 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
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
Extended Kernel: Kernel extensions for functions such as inference and aggregation and constraint processing
Integrity Lock
Database
Trusted Agentto computechecksums
Sensor
Data Manager
Untrusted
Data ManagerCompute ChecksumBased on stream data valueand Security level;Store data value, Security level and Checksum
Compute ChecksumBased on data valueand Security level retrievedfrom the stored database
Operating System Providing Mandatory Access Control
Unclassifieddevice
Secretdevice
TopSecretdevice
Multilevel
Data Manager
UnclassifiedData
SecretData
TopSecretData
Operating system has the TCB; Data manager is untrusted
An instance of the data manager is created at each level (e.g., U, S, TS); note: only one data manager (e.g., Oracle) but multiple instances (processes)
Secret user/device enters data and the Secret instance will write the data to the Secret operating system file
Operating system will control the write operation to the operating system file
Secret user/device queries for data
Secret instance will open both Secret and Unclassified operating system files and read from them, recombine the data and give the data to the Secret user
Operating system will control the read operation to the operating system files
Trusted Subject
Unclassifieddevice
Secretdevice
TopSecretdevice
Multilevel
Data Manager
Multilevel
Data
TrustedComponent
All the data is in the multilevel database and stored at the highest level (labels are attached to the data)
When a user queries or writes, the trusted component (the database TCB) will read and write from/into the multilevel database according to the policy
Read at or below your level and write at your level
Distributed Approach – I: Partition
Unclassified
Data Manager
TopSecret
Data Manager
UnclassifiedData
SecretData
TopSecretData
Trusted Agentto manage Aggregated Data
Secret
Data Manager
Unclassified
Data Manager
TopSecret
Data Manager
UnclassifiedData
SecretData
TopSecretData
Trusted Agentto manage Aggregated Data
Secret
Data Manager
Secret user update (write) will go to Secret data manager via the trusted agent
Secret user query will go to the Secret data manager and the Unclassified data manager via the trusted agent
Problem: When a Secret user data (e.g., query) is sent to the Unclassified data manager it is a WRITE-DOWN
Distributed Approach II: Replication
Unclassified
Data Manager
TopSecret
Data Manager
UnclassifiedData Secret + Unclassified
Data
TopSecretSecret + Unclassified
Data
Trusted Agentto manage Aggregated Data
Secret
Data Manager
Extended Kernel
MultilevelData
Kernel ExtensionsTo enforce additional security policies enforced on datae.g., security constraints, privacy constraints, etc.
Multilevel
Data Manager
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: PolyinstantiationMechanism to avoid certain signaling channels
Also supports cover stories
Example: John and James have different salaries at different levels
EMP
SS# Name Salary
1 John 20 2 Paul 303 James 401 John 70 4 Mary 803 James 60
Level
UUUSSS
Some Challenges: Covert ChannelDatabase 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 T2
Multilevel Secure Data Model: Classifying Databases
EMP
SS# Ename Salary D#
1 John 20K 10
2 Paul 30K 20
3 Mary 40K 20
DEPT
D# Dname Mgr
10 Math Smith
20 Physics Jones
DATABASE D: Level = Secret
Multilevel Secure Data Model: Classifying Relations
EMP: Level = Secret
SS# Ename Salary D#
1 John 20K 10
2 Paul 30K 20
3 Mary 40K 20
DEPT: Level = Unclassified
D# Dname Mgr
10 Math Smith
20 Physics Jones
Multilevel Secure Data Model: Classifying Attributes/Columns
EMP
SS#: S Ename: U Salary: S D#: U
1 John 20K 10
2 Paul 30K 20
3 Mary 40K 20
DEPT
D#: U Dname: U Mgr: S
10 Math Smith
20 Physics Jones
U = UnclassifiedS = Secret
Multilevel Secure Data Model: Classifying Tuples/Rows
EMP
SS# Ename Salary D#
1 John 20K 10 U
2 Paul 30K 20 S
3 Mary 40K 20 TS
DEPT
D# Dname Mgr
10 Math Smith U
20 Physics Jones C
Level Level
U = UnclassifiedC = ConfidentialS = SecretTS = TopSecret
Multilevel Secure Data Model: Classifying Elements
EMP
SS#: Ename: Salary D#:
1, S John, U 20K, C 10, U
2, S Paul, U 30K, S 20, U
3, S Mary, U 40K, S 20, U
DEPT
D#: U Dname: U Mgr: S
10, U Math, U Smith, C
20, U Physics, U Jones, S
U = UnclassifiedC = ConfidentialS = Secret
Multilevel Secure Data Model: Classifying Views
EMP
SS# Ename Salary D#
1 John 20K 10
2 Paul 30K 20
3 Mary 40K 20
4 Jane 20K 20
5 Bill 20K 10
6 Larry 20K 10
1 Michelle 30K 20
SECRET VIEW EMP (D# = 20)
SS# Ename Salary
2 Paul 30K
3 Mary 40K
4 Jane 20K
1 Michelle 30K
UNCLASSIFIED VIEW EMP (D# = 10)
SS# Ename Salary
1 John 20K
5 Bill 20K
6 Larry 20K
EMP
SS# Ename Salary D#
1 John 20K 10
2 Paul 30K 20
3 Mary 40K 20
4 Jane 20K 20
5 Bill 20K 10
6 Larry 20K 10
1 Michelle 30K 20
EMP
SS# Ename Salary D#
1 John 20K 10
2 Paul 30K 20
3 Mary 40K 20
4 Jane 20K 20
5 Bill 20K 10
6 Larry 20K 10
1 Michelle 30K 20
SECRET VIEW EMP (D# = 20)
SS# Ename Salary
2 Paul 30K
3 Mary 40K
4 Jane 20K
1 Michelle 30K
UNCLASSIFIED VIEW EMP (D# = 10)
SS# Ename Salary
1 John 20K
5 Bill 20K
6 Larry 20K
Multilevel Secure Data Model: Classifying Metadata
Relation REL
Relation Attribute Level
EMP SS# SecretEMP Ename UnclassifiedEMP Salary ConfidentialEMP D# UnclassifiedDEPT D# UnclassifiedDEPT Dname Unclassified DEPT Mgr Confidential
MLS/DBMS FunctionsOverview
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 FunctionsSecure Query Processing
Secure UserInterfaceManager
Secure QueryTransformer
Secure StorageManager
SecureDatabase
ResponseManager
QueryModifier
Secure QueryOptimizer
Secure UserInterfaceManager
Secure QueryTransformer
Secure StorageManager
SecureDatabase
ResponseManager
QueryModifier
Secure QueryOptimizer
MLS/DBMS FunctionsSecure Transaction Management
Secret Process reads fromThe object O’
UnclassifiedObject O
Copy O’ ofObject OAt the Secret level
Unclassified Process reads from and writes into the object O’
O is updated toO’’
O* is a copy ofO”. Essentially O’ is updated to O* at the
Secret level
MLS/DBMS FunctionsSecure 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