View
212
Download
0
Category
Preview:
Citation preview
1
Database Security
Simone Fischer-Hübner
Applied Security, DAVC17
Overview
Semantic Integrity ControlsAccess Control RulesMultilevel Secure DatabasesRBAC in Commercial DBMSStatistical Database Security
Relational Database Basics
A Relational Database is perceived as a collection of tables/relations
SecretaryDept-2Rita HanksIT Security specialistDept-2Mary DoeProgrammerDept-2John SmithProfessionDepartmentEmployee name
A primary key is a unique and minimal identifier for the tuples within a relation (e.g., employee name)
Entity Integrity Rule: No component of the primary key may
accept a null value (no entry).
Semantic Integrity Controls
Monitor:Unit of DBMS that checks value being entered to ensure consistency with
rest of the databasecharacteristics of the particular field
Semantic Integrity Controls (II)Forms of Monitor checks:
Range comparison: check that values are within acceptable rangedays in January: 1 –31salary of employees < 50000
State constraints: describe conditions for entire databaseall employees have different employee numbersonly one employee is “president”
Transition constraints: conditions necessary before changes to be appliedemployee who is “married” cannot become “single”
Access Control Rules-Name dependent access
Name dependent: based on object name/id (e.g. name of relations/tables, attributes)Can be enforced by underlying OS
Example:
R-Bob
RR,WAlice
Course TableEmployee Table
2
Content dependent AccessContent-dependent:
based on object content Implementation: content-based views, query modification
Example: Content-based View
DEFINE VIEW X (Employee-no, salary) ASSELECT Employee-no, salaryFrom EmployeeWHERE SALARY < 30.000.
Content-dependent Access (II)
Example: Query Modification
DENY (Name, SALARY) WHERE SALARY > 30.000
FIND Salary WHERE Name = Smith
-> (is modified to)
FIND Salary WHERE Name = Smith AND NOT Salary > 30.000
Context-dependent Access
Context-dependent: based on system variables such as data, time, query sourcecontext-based views
Example:”Salary information can only be updated at
the end of the year”
Multilevel Secure Databases
Implement Bell LaPadula´s Mandatory (“Multi-Level”) Security policy in a relational databaseFirst prototype in the Seaview (Secure data VIEW) project (1988)Major database vendors have DBMS versions with multi-level database security support (e.g. Trusted Oracle)
Multilevel Secure Databases –Structure
Labeling Objects:R: multi-level relation with n attributes
A tuple in R is of the form (v1, c1, …, vn, cn, tc) where
vi: ith attribute valueci: security level of the ith field (not visible to users)tc: security level of the tuple (not visible)
Multilevel Secure Databases –Example
UUSecretaryUDept-2URita Hanks
SSIT Security specialist
SDept-2UMary Doe
TSTSVirus programmer
SDept-1SJohn Bob
tcCprofProfessionCDeptDepartmentCnameEmployee name
Example:
U: unclassifiedS: SecretTS: Top Secret(For simplicity, we only consider the security classification parts of the security level in this and in the following examples)
3
Multilevel Secure Databases-Instances
C-Instance of a relation: Information in relation accessible by users at classification C.Values not accessible are replaced by null values (no entry).
Examples:S-Instance:
SecretaryDept-2Rita HanksIT Security specialistDept-2Mary Doe
-Dept-1John Bob
ProfessionDepartmentEmployee name
Multilevel Secure Databses –Instances (II)
U-Instance:
SecretaryDept-2Rita Hanks--Mary Doe
ProfessionDepartmentEmployee name
Consistent AddressingIn order to address a data item, you have to specify
a database Da relation R within Da primary key for a tuple r within Dthe attribute i, identifying element ri within r
To get through to element ri , the following must hold:fO(D) ≤ fO(R) ≤ fO (ri) (fO: object security level)
Since a user who has access to a tuple r has also access to all its elements fO(ri) ≤ fO (r) is required
Multilevel Entity Integrity
No tuples in an instance of R have null values for any of the primary key attributesAll components of a primary key of a relation R have the same security level, which is dominated by the security levels of all non-key attributes
Polyinstantiation
Polyinstantiation: Several tuples might exist for the same primary key
Polyinstantiated elements:Elements of an attribute which have different security levels, but are associated with the same primary key and key security level
Problem: Tradeoff between confidentiality (covert channel protection) and integrity
Polyinstantiation (II)How do polyinstantiated elements arise ?
A subject updates what appears a null element in a tuple,but which actually hides data with a higher(or incomparable) security level
Problem:Subject cannot be informed about existence of higher security level data (-> covert channel)Overwriting the old value allows “low” users to unwittingly destroy “high” data
Insertion must be accepted
4
Polyinstantiation – Example
Primary key: Employee Name
Unclassified Subject requests the following operation:Update employeeSET profession = “Programmer”WHERE name = “Mary Doe”
SecretaryDept-2Rita Hanks--Mary Doe
ProfessionDepartmentEmployee name
U-Instance of our Example Database:
Polyinstantiation- Example (cont.)
UUSecretaryUDept-2URita Hanks
SSIT Security specialist
SDept-2UMary Doe
TSTSVirus Programmer
SDept-1SJohn BobtcCprofProfessionCDeptDepartmentCnameEmployee name
UUSecretaryUDept-2URita HanksSUProgrammerSDept-2UMary Doe
SSIT Security specialist
SDept-2UMary Doe
TSTSVirus Programmer
SDept-1SJohn BobtcCprofProfessionCDeptDepartmentCnameEmployee name
Unique Identification
Extended primary key:Primary key + security levels of all fields in a tuple needed for a unique identification of tuples
RBAC Features in Commercial DBMS
YESYESYESGRANT DBMS Object Privileges to a roleYESYESNOGrant DBMS System Privileges to a role
NONONOSpecify maximum or minimum cardinality for role membership
NOYES(YES)Specify dynamic separation of duty constraints on roles
NOYESNOSpecify static separation of duty constraints on rolesYESYESYESBuild a role hierarchyYESYESNOSpecify a default active role set for a user sessionYESYESNOMultiple active roles for a user session
YESNOYESAbility for a role grantee to grant that role to other users
OracleSybaseInformixFeature
Statistical Database Security
Statistical Database:Information is retrieved by means of statistical queries on an attribute (column) of a tableAttributes directly identifying persons (e.g., names, personal numbers) are usually not allowed for statistical queries
Statistical Database - Example
2CS18m Sveniek102CS 19mCohn94CS21mSilver81Math 20fKnuth72Math21mFisher61Math 20fBob52Math21m Hall43Math 21fSneyer34CS18fSmith22CS20mMayer1
GPMajorAgeSexNameRecord No.
Name: identity data (identifying the persons)Sex, Age, Major: demographic data (generally known to many people)GP(student grades): analysis data (not publicly known, of interest for attackers)
5
Statistical Queries
Statistical query: q(C,U) (or simply: q(C))q: statistical functionC: characteristic formula, logical formula over the values of
attributes using the operators OR, AND, NOTU: subset of attributesExample:COUNT (( SEX = MALE ) AND ( MAJOR = CS ))SUM(( SEX = MALE ) AND ( MAJOR = CS ), GP)
query set (C) = set of records whose values match a characteristic formula C
ALL = formula whose query set is the entire database
Simple Attacks
Small Query Set Attacks:Attacker knows that Smith is a female CS student:
COUNT (( SEX = FEMALE ) AND ( MAJOR = CS )) =1
=>Smith is the only female CS student.
SUM(( SEX = FEMALE ) AND ( MAJOR = CS ), GP) = Smith’s GP = 4
Simple Attacks (II)
Large Query Set Attacks:It is not sufficient to suppress only small query sets ! The same statistics can be calculated by:
COUNT(ALL) – COUNT(NOT ((SEX = FEMALE) AND (MAJOR = CS))) =1
SUM(ALL, GP) – SUM(NOT((SEX = FEMALE) AND (MAJOR = CS)),GP) = 4
Query Set Size ControlA statistic q(C) is permitted only if
n ≤ |query set (C)| ≤ N-n for parameter n ≥ 2, N: size (No. of tuples) of database
q(ALL) can be computed from:q (All) = q (C) + q (NOT C)
for C with n ≤ | query set (C) | ≤ N-n
However: Tracker attacks can still compromise security !
Individual Tracker Attack
Individual Tracker: Suppose: q (C) is rejected, because |query set (C)| = 1C = C1 AND C2, n ≤ | query set (C1) |≤ N - n
n ≤ | query set (C1 AND NOT C2) | ≤ N – n
Individual Tracker: { C1, C1 AND NOT C2}
Individual Tracker Attack: (for q : SUM or COUNT))
q(C) = q(C1 AND C2) = q(C1) - q (C1 AND NOT C2)
Individual Tracker Attack (II)
Venn Diagram:
xz y
C1
C= C1 AND C2
C2
q(C1) = x + z = q(C1 AND NOT C2) + q(C)
=> q(C) = q(C1 AND C2) = q(C1) - q (C1 AND NOT C2)
6
Individual Tracker - ExampleExample: n = 2, Individual Tracker = { (Major = CS), (Major = CS) AND NOT (SEX = f))}
SUM((Major = CS) AND (Sex = f),GP) =SUM (Major = CS, GP) - SUM ((Major = CS) AND NOT (Sex = f), GP)= 14 – 10 = 4
A new Individual Tracker has to be found for each person !
General Tracker Attack
General Tracker:Characteristic Formula T such that2*n ≤ |query set (T)| ≤ N – 2*n , n ≤ N/4
General Tracker Attack:q(ALL) = q(T) + q(not T)
If |query set (C)| < n: q(C) = q(C or T) + q(C or not T) - q(ALL)
General Tracker Attack (II)
Venn-Diagram:
zynot CxwC
not TT
q(All) = w + x + y + z = q(T) + q(not T)
q(C or T) + q(C or not T) = (w+x+y) + (w+x+z)
= (w+x) + (w+x+y+z) = q(C) + q(All)
=> q(C) = q(C or T) + q(C or not T) - q(ALL)
General Tracker Attack -Example
Example: n = 2, T = (Sex= Male)
SUM ((SEX = FEMALE) AND (MAJOR = CS), GP) =SUM((SEX = FEMALE) AND (MAJOR = CS)) OR (SEX = MALE),GP) + SUM (((SEX = FEMALE) AND (MAJOR = CS)) OR (NOT (SEX = MALE)), GP) -SUM (ALL, GP) = 18 + 9 - 23= 4
SUM (ALL, GP) = SUM (SEX = MALE, GP) + SUM (NOT (SEX =
MALE), GP)
Inference Controls
Security Controls for Statistical Databases:Data Pertubation (slightly modifies data values in database)Output Controls
Output Modification (modifies statistics, adds small relative errors to outputs, e.g, rounding, adding random numbers)Output Selection (rejects ”sensitive” statistics, e.g. query set size control, maximum order control)
Exercise
Find a General Tracker Individual Tracker
to compromise Mayer’s GP(see example DB above)
Recommended