Security in Databases

2 Srini & Nandita (CSE2500)DB Security Outline review of databases reliability & integrity protection of sensitive data protection against inference multi-level security CSE2500 System Security & Privacy

3 Srini & Nandita (CSE2500)DB Security Database DBMS DB Administrator users

4 Srini & Nandita (CSE2500)DB Security Database concepts database –data + rules components of data –records: composed of fields / elements logical structure  schema attribute  name of a column relation  a set of columns

5 Srini & Nandita (CSE2500)DB Security A sample database

6 Srini & Nandita (CSE2500)DB Security DB should deliver (advantages) shared access minimal redundancy data consistency data integrity controlled access

7 Srini & Nandita (CSE2500)DB Security Security requirements physical DB integrity logical DB integrity element (field) integrity auditability access control user authentication availability –(integrity, confidentiality & availability)

8 Srini & Nandita (CSE2500)DB Security Reliability & integrity three dimensions: –database integrity –element integrity –element accuracy various techniques –2-phase update –introducing redundancy –recovery –concurrency/consistency control –using monitors

9 Srini & Nandita (CSE2500)DB Security 2-phase update phase-1: Intent –gathering info & resources –no harm in the case of failure –writing of a commit flag to data base phase-2: Commit –set commit flag in the database –causing permanent changes –may be repairable in the case of failure

10 Srini & Nandita (CSE2500)DB Security 2-Phase Update (Example) Suppose DB query asks to add 1 to fields X and Y. Phase 1 (Intent): –Compute updated values in temporary “Shadow” variables Xnew and Ynew: >Xnew := X + 1, Ynew := Y + 1 Phase 2 (Commit): –Set “Commit” flag (i.e. DB changes started, do not repeat Intent phase!) –Copy shadow values into DB: >X := Xnew, Y := Ynew –Write “Update Complete”, Clear Commit flag.

11 Srini & Nandita (CSE2500)DB Security Redundancy/internal consistency using error detection / correction codes –entire database –records –fields / elements shadow fields –duplication of attributes / records

12 Srini & Nandita (CSE2500)DB Security Recovery one way to achieve this is to have a log file for all recent changes (since last backup)

13 Srini & Nandita (CSE2500)DB Security Concurrency/Consistency In a multi-user/process/client environment, concurrency and consistency control is vitally important. Basic techniques –using “atomic operation” >Read-then-(if OK)Write: A Write query to a field is conditioned on its current contents being as specified (in case it was modified recently by someone else) –using “locking” mechanisms >Read queries to a record are blocked while a write is performed to the record by someone else

14 Srini & Nandita (CSE2500)DB Security Monitors checking the structural consistency of data entered or modified –range comparison -- field specific –state constraints >describe of the condition of entire DB >(Properties which should be satisfied by DB contents at all times) –transition constraints >describe the conditions necessary before a change can be made (Properties which should be satisfied by DB contents so that a change to DB is valid) Collectively called Integrity Constraints

15 Srini & Nandita (CSE2500)DB Security On sensitive data factors that make data sensitive –inherently sensitive –from a sensitive source –declared sensitive –of a sensitive attribute or a sensitive record –sensitive in relation to previously disclosed information sensitivity of data in a DB may vary !

16 Srini & Nandita (CSE2500)DB Security A sample database

17 Srini & Nandita (CSE2500)DB Security Access decisions on sensitive data factors to be considered when permitting “user x to access data y” –availability of data >Record is blocked from read while it is modified –acceptability of access >No disclosure (even ‘partial’) of sensitive values to unauthorized users –assurance of authenticity of user >Limit access based on other considerations (time of access, previous accesses,…)

18 Srini & Nandita (CSE2500)DB Security Types of disclosure of sensitive data exact data (field = x) Bounds – x < field < y negative result –field is not equal to x Existence –an Attribute of a field exists in DB probable value –reducing the number of possible values for a field, Improving knowledge of their relative likelihoods.

19 Srini & Nandita (CSE2500)DB Security Inference Problem definition: –infer or derive sensitive data from non- sensitive or (seemingly) un-related data “inference” is a subtle vulnerability in database security

20 Srini & Nandita (CSE2500)DB Security A sample database

21 Srini & Nandita (CSE2500)DB Security Direct attack list NAME where SEX = M & DRUGS = 1 list NAME where (SEX = M & DRUGS = 1) | (SEX != M & SEX != F) | (DORM != East)

22 Srini & Nandita (CSE2500)DB Security Indirect attack (statistical inference) Sum sum of financial aid by dorm & sex Holmes Grey West Total M F Total

23 Srini & Nandita (CSE2500)DB Security Indirect attack (cont.) Count –count of students by dorm & sex Holmes Grey West Total M F Total –can be used in combination with “sum”

24 Srini & Nandita (CSE2500)DB Security Indirect attack (cont.) Median highest value for attribute 1 lowest value for attribute 1 lowest value for attribute 2 highest value for attribute 2 median for attribute 1 & median for attribute 2

25 Srini & Nandita (CSE2500)DB Security revealing Earhart’s drug Earhart is the only person who has the median of AID and DRUGS, so if data on AID is known, the following query reveals Earhart’s DRUGS: p = median (DRUGS where AID=2000)

26 Srini & Nandita (CSE2500)DB Security Indirect attack (cont.) Linear system attack –by solving a set of equations e.g. q1 = c1 + c2 + c3 q2 = c2 + c3 q3 = c1 + c3

27 Srini & Nandita (CSE2500)DB Security Controls for statistical inference 2 types of control –applied to queries --- very hard ! –applied to data items --- relatively easy >suppression --- sensitive data are not provided >concealing --- precise data are not provided

28 Srini & Nandita (CSE2500)DB Security Summary of inference no perfect solution to inference problem 3 common approaches –suppress obviously sensitive data  fairly easy –track what the user knows  costly –disguise data  may result in incorrect or wrong responses to legitimate queries

29 Srini & Nandita (CSE2500)DB Security Multi-level security The 2 level security model, sensitive or non- sensitive, is inadequate in many practical applications: –The security of a data element may be different from that of other elements in the same row or column. –In practice many grades of security may be needed. –The security of an aggregate may be different from that of the individual elements

30 Srini & Nandita (CSE2500)DB Security Realising Multi-level Security Partitioning –each sub-database corresponds to a security level Encryption –each record (or field) can be encrypted using a different key Integrity lock Trusted Front End Commutative Filter Window/View