Information Security Analytics

Dr. Bhavani Thuraisingham

The University of Texas at Dallas

Multilevel Secure Data Management

September 2013

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