Overview Database Security Semantic Integrity Controls Access - PDF document

Overview Database Security � Semantic Integrity Controls � Access Control Rules � Multilevel Secure Databases � RBAC in Commercial DBMS � Statistical Database Security Simone Fischer-Hübner Applied Security, DAVC17 Relational Database Basics Semantic Integrity Controls A Relational Database is perceived as a collection of tables/relations Monitor: Employee name Department Profession Unit of DBMS that checks value being John Smith Dept-2 Programmer Mary Doe Dept-2 IT Security specialist entered to ensure consistency with Rita Hanks Dept-2 Secretary rest of the database � characteristics of the particular field A primary key is a unique and minimal identifier for the tuples � within a relation (e.g., employee name) Entity I ntegrity Rule: No component of the primary key may accept a null value (no entry). Access Control Rules- Semantic Integrity Controls (II) Name dependent access Forms of Monitor checks: � Name dependent: � based on object name/id (e.g. name of Range comparison: check that values are within acceptable range relations/tables, attributes) days in January: 1 –31 � � Can be enforced by underlying OS salary of employees < 50000 � State constraints: describe conditions for entire database Example: all employees have different employee numbers � only one employee is “president” � Employee Table Course Table Transition constraints: conditions necessary before changes to be Alice R,W R applied employee who is “married” cannot become “single” � Bob - R 1

Content dependent Access Content-dependent Access (II) � Content-dependent: Example: Query Modification � based on object content � Implementation: content-based views, query DENY (Name, SALARY) WHERE SALARY > 30.000 modification Example: Content-based View FIND Salary WHERE Name = Smith -> (is modified to) DEFINE VIEW X (Employee-no, salary) AS SELECT Employee-no, salary From Employee FIND Salary WHERE Name = Smith AND NOT WHERE SALARY < 30.000. Salary > 30.000 Multilevel Secure Databases Context-dependent Access � Context-dependent: � Implement Bell LaPadula´ s Mandatory (“Multi-Level”) Security policy in a � based on system variables such as data, time, relational database query source � context-based views � First prototype in the Seaview (Secure data VIEW) project (1988) Example: � Major database vendors have DBMS versions with multi-level database security ”Salary information can only be updated at support (e.g. Trusted Oracle) the end of the year” Multilevel Secure Databases – Multilevel Secure Databases – Structure Example Example: Labeling Objects: Employee name C name Department C Dept Profession C prof tc R: multi-level relation with n attributes John Bob S Dept-1 S Virus TS TS programmer Mary Doe U Dept-2 S IT Security S S A tuple in R is of the form (v 1 , c 1 , …, v n , c n , t c ) specialist where Rita Hanks U Dept-2 U Secretary U U v i : ith attribute value U: unclassified S: Secret c i : security level of the ith field (not TS: Top Secret visible to users) (For simplicity, we only consider the security classification parts of the t c : security level of the tuple (not visible) security level in this and in the following examples) 2

Multilevel Secure Databases- Multilevel Secure Databses – Instances Instances (II) C-I nstance of a relation: U-Instance: Information in relation accessible by users at classification C. Values not accessible are replaced by null values (no entry). Employee name Department Profession Mary Doe - - Examples: Rita Hanks Dept-2 Secretary S-Instance: Employee name Department Profession John Bob Dept-1 - Mary Doe Dept-2 IT Security specialist Rita Hanks Dept-2 Secretary Consistent Addressing Multilevel Entity Integrity In order to address a data item, you have to specify � No tuples in an instance of R have null � a database D values for any of the primary key attributes � a relation R within D � a primary key for a tuple r within D � All components of a primary key of a � the attribute i, identifying element r i within r relation R have the same security level, which is dominated by the security levels of � To get through to element r i , the following must hold: f O (D) ≤ f O (R) ≤ f O (r i ) (f O : object security level) all non-key attributes Since a user who has access to a tuple r has also access to all its elements � f O (r i ) ≤ f O (r) is required Polyinstantiation Polyinstantiation (II) How do polyinstantiated elements arise ? Polyinstantiation: A subject updates what appears a null element in a tuple, Several tuples might exist for the same primary key but which actually hides data with a higher Polyinstantiated elements: (or incomparable) security level Elements of an attribute which have different Problem: security levels, but are associated with the same � Subject cannot be informed about existence of higher primary key and key security level security level data (-> covert channel) � Overwriting the old value allows “low” users to Problem: unwittingly destroy “high” data Tradeoff between confidentiality (covert channel � Insertion must be accepted protection) and integrity 3

Polyinstantiation- Example Polyinstantiation – Example (cont.) Employee name C name Department C Dept Profession C prof tc U-I nstance of our Example Database: John Bob S Dept-1 S Virus TS TS Programmer Employee name Department Profession Mary Doe U Dept-2 S IT Security S S specialist Mary Doe - - Rita Hanks U Dept-2 U Secretary U U Rita Hanks Dept-2 Secretary Primary key: Employee Name Employee name C name Department C Dept Profession C prof tc John Bob S Dept-1 S Virus TS TS Unclassified Subject requests the following operation: Programmer Update employee Mary Doe U Dept-2 S IT Security S S SET profession = “Programmer” specialist Mary Doe U Dept-2 S Programmer U S WHERE name = “Mary Doe” Rita Hanks U Dept-2 U Secretary U U RBAC Features in Commercial Unique Identification DBMS Feature Informix Sybase Oracle Extended primary key: Ability for a role grantee to grant that role to other YES NO YES � Primary key + security levels of all users fields in a tuple Multiple active roles for a user session NO YES YES Specify a default active role set for a user session NO YES YES � needed for a unique identification of Build a role hierarchy YES YES YES tuples Specify static separation of duty constraints on roles NO YES NO Specify dynamic separation of duty constraints on (YES) YES NO roles Specify maximum or minimum cardinality for role NO NO NO membership Grant DBMS System Privileges to a role NO YES YES GRANT DBMS Object Privileges to a role YES YES YES Statistical Database Security Statistical Database - Example Record No. Name Sex Age Major GP Statistical Database: 1 Mayer m 20 CS 2 � Information is retrieved by means of 2 Smith f 18 CS 4 3 Sneyer f 21 Math 3 statistical queries on an attribute 4 Hall m 21 Math 2 (column) of a table 5 Bob f 20 Math 1 6 Fisher m 21 Math 2 � Attributes directly identifying persons 7 Knuth f 20 Math 1 (e.g., names, personal numbers) are 8 Silver m 21 CS 4 usually not allowed for statistical 9 Cohn m 19 CS 2 10 Sveniek m 18 CS 2 queries 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) 4

Statistical Queries Simple Attacks Statistical query: q(C,U) (or simply: q(C)) Small Query Set Attacks: q: statistical function Attacker knows that Smith is a female CS student: C: characteristic formula, logical formula over the values of attributes using the operators OR, AND, NOT COUNT (( SEX = FEMALE ) AND ( MAJOR = CS )) = 1 U: subset of attributes Example: = > COUNT (( SEX = MALE ) AND ( MAJOR = CS )) Smith is the only female CS student. SUM(( SEX = MALE ) AND ( MAJOR = CS ), GP) SUM(( SEX = FEMALE ) AND ( MAJOR = CS ), GP) = query set (C) = set of records whose values match a characteristic formula C Smith’s GP = 4 ALL = formula whose query set is the entire database Simple Attacks (II) Query Set Size Control A statistic q(C) is permitted only if Large Query Set Attacks: n ≤ |query set (C)| ≤ N-n for parameter n ≥ 2, It is not sufficient to suppress only small query sets ! N: size (No. of tuples) of database The same statistics can be calculated by: q(ALL) can be computed from: q (All) = q (C) + q (NOT C) COUNT(ALL) – COUNT(NOT ((SEX = FEMALE) AND for C with n ≤ | query set (C) | ≤ N-n (MAJOR = CS))) = 1 However: Tracker attacks can still compromise security ! SUM(ALL, GP) – SUM(NOT((SEX = FEMALE) AND (MAJOR = CS)),GP) = 4 Individual Tracker Attack Individual Tracker Attack (II) Venn Diagram: I ndividual Tracker: Suppose: q (C) is rejected, because |query set (C)| = 1 C1 C2 C = C1 AND C2, n ≤ | query set (C1) | ≤ N - n n ≤ | query set (C1 AND NOT C2) | ≤ N – n x y z Individual Tracker: { C1, C1 AND NOT C2 } C= C1 AND C2 I ndividual Tracker Attack: (for q : SUM or COUNT)) q(C) = q(C1 AND C2) = q(C1) - q (C1 AND NOT 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) 5