current trends in data security n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Current Trends in Data Security PowerPoint Presentation
Download Presentation
Current Trends in Data Security

Loading in 2 Seconds...

play fullscreen
1 / 48

Current Trends in Data Security - PowerPoint PPT Presentation


  • 428 Views
  • Uploaded on

Current Trends in Data Security. Dan Suciu Joint work with Gerome Miklau. Data Security. Dorothy Denning, 1982: Data Security is the science and study of methods of protecting data (...) from unauthorized disclosure and modification Data Security = Confidentiality + Integrity.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Current Trends in Data Security' - adamdaniel


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
current trends in data security

Current Trends in Data Security

Dan Suciu

Joint work with Gerome Miklau

data security
Data Security

Dorothy Denning, 1982:

  • Data Security is the science and study of methods of protecting data (...) from unauthorized disclosure and modification
  • Data Security = Confidentiality + Integrity
data security1
Data Security
  • Distinct from systems and network security
    • Assumes these are already secure
  • Tools:
    • Cryptography, information theory, statistics, …
  • Applications:
    • An enabling technology
outline
Outline
  • Traditional data security
  • Two attacks
  • Data security research today
  • Conclusions
traditional data security
Traditional Data Security
  • Security in SQL = Access control + Views
  • Security in statistical databases = Theory
access control in sql

[Griffith&Wade'76, Fagin'78]

Access Control in SQL

GRANT privileges ON object TO users [WITH GRANT OPTIONS]

privileges = SELECT | INSERT | DELETE | . . .

object = table | attribute

REVOKE privileges ON object FROM users [CASCADE ]

views in sql
Views in SQL

A SQL View = (almost) any SQL query

  • Typically used as:

CREATE VIEW pmpStudents AS SELECT * FROM Students WHERE…

GRANT SELECT ON pmpStudents TO DavidRispoli

summary of sql security
Limitations:

No row level access control

Table creator owns the data: that’s unfair !

… or spectacular failure:

Only 30% assign privileges to users/roles

And then to protect entire tables, not columns

Summary of SQL Security

Access control = great success story of the DB community...

summary cont
Summary (cont)
  • Most policies in middleware: slow, error prone:
    • SAP has 10**4 tables
    • GTE over 10**5 attributes
    • A brokerage house has 80,000 applications
    • A US government entity thinks that it has 350K
  • Today the database is not at the center of the policy administration universe

[Rosenthal&Winslett’2004]

security in statistical dbs

Not OK

SELECT name

FROM Patient

WHERE age=42

and sex=‘M’

and diagnostic=‘schizophrenia’

SELECT count(*)

FROM Patients

WHERE age=42

and sex=‘M’

and diagnostic=‘schizophrenia’

OK

[Adam&Wortmann’89]

Security in Statistical DBs

Goal:

  • Allow arbitrary aggregate SQL queries
  • Hide confidential data
security in statistical dbs1

[Adam&Wortmann’89]

Security in Statistical DBs

What has been tried:

  • Query restriction
    • Query-size control, query-set overlap control, query monitoring
    • None is practical
  • Data perturbation
    • Most popular: cell combination, cell suppression
    • Other methods, for continuous attributes: may introduce bias
  • Output perturbation
    • For continuous attributes only
summary on security in statistical db
Summary on Security in Statistical DB
  • Original goal seems impossible to achieve
  • Cell combination/suppression are popular, but do not allow arbitrary queries
outline1
Outline
  • Traditional data security
  • Two attacks
  • Data security research today
  • Conclusions
sql injection

User:

Password:

fred

********

Search claims by:

[Chris Anley, Advanced SQL Injection In SQL]

SQL Injection

Your health insurance company lets you see the claims online:

First login:

Now search through the claims :

Dr. Lee

SELECT…FROM…WHERE doctor=‘Dr. Lee’ and patientID=‘fred’

sql injection1

Better:

Search claims by:

Dr. Lee’ OR 1 = 1; --

SQL Injection

Now try this:

Search claims by:

Dr. Lee’ OR patientID = ‘suciu’; --

…..WHERE doctor=‘Dr. Lee’ OR patientID=‘suciu’; --’ and patientID=‘fred’

sql injection2
SQL Injection

When you’re done, do this:

Search claims by:

Dr. Lee’; DROP TABLE Patients; --

sql injection3
SQL Injection
  • The DBMS works perfectly. So why is SQL injection possible so often ?
  • Quick answer:
    • Poor programming: use stored procedures !
  • Deeper answer:
    • Move policy implementation from apps to DB
latanya sweeney s finding
Latanya Sweeney’s Finding
  • In Massachusetts, the Group Insurance Commission (GIC) is responsible for purchasing health insurance for state employees
  • GIC has to publish the data:

GIC(zip, dob, sex, diagnosis, procedure, ...)

latanya sweeney s finding1
Latanya Sweeney’s Finding
  • Sweeney paid $20 and bought the voter registration list for Cambridge Massachusetts:

GIC(zip, dob, sex, diagnosis, procedure, ...)

VOTER(name, party, ..., zip, dob, sex)

latanya sweeney s finding2
Latanya Sweeney’s Finding
  • William Weld (former governor) lives in Cambridge, hence is in VOTER
  • 6 people in VOTER share his dob
  • only 3 of them were man (same sex)
  • Weld was the only one in that zip
  • Sweeney learned Weld’s medical records !

zip, dob, sex

latanya sweeney s finding3
Latanya Sweeney’s Finding
  • All systems worked as specified, yet an important data has leaked
  • How do we protect against that ?

Some of today’s research in data security address breachesthat happen even if all systems work correctly

summary on attacks
Summary on Attacks

SQL injection:

  • A correctness problem:
    • Security policy implemented poorly in the application

Sweeney’s finding:

  • Beyond correctness:
    • Leakage occurred when all systems work as specified
outline2
Outline
  • Traditional data security
  • Two attacks
  • Data security research today
  • Conclusions
research topics in data security
Research Topics in Data Security

Rest of the talk:

  • Information Leakage
  • Privacy
  • Fine-grained access control
  • Data encryption
  • Secure shared computation
information leakage k anonymity

[Samarati&Sweeney’98, Meyerson&Williams’04]

Information Leakage:k-Anonymity

Definition: each tuple is equal to at least k-1 others

Anonymizing: through suppression and generalization

Hard: NP-complete for supression only

Approximations exists

information leakage query view security

[Miklau&S’04, Miklau&Dalvi&S’05,Yang&Li’04]

Information Leakage:Query-view Security

Have data:

TABLE Employee(name, dept, phone)

total

big

tiny

none

summary on information disclosure
Summary on Information Disclosure
  • The theoretical research:
    • Exciting new connections between databases and information theory, probability theory, cryptography
  • The applications:
    • many years away

[Abadi&Warinschi’05]

privacy
Privacy
  • “Is the right of individuals to determine for themselves when, how and to what extent information about them is communicated to others”
  • More complex than confidentiality

[Agrawal’03]

privacy1

alice@a.b.com

Privacy policy: P3P

Privacy

Example: Alice gives her email to a web service

Involves:

  • Data
  • Owner
  • Requester
  • Purpose
  • Consent
hippocratic databases

alice@a.b.com

Privacy policy: P3P

Hippocratic Databases

DB support for implementing privacy policies.

  • Purpose specification
  • Consent
  • Limited use
  • Limited retention

Hippocratic DB

  • Protection against:
  • Sloppy organizations
  • Malicious organizations

[Agrawal’03, LeFevrey’04]

privacy for paranoids

lice27@agenthost.com

foreign keys ?

Privacy for Paranoids
  • Idea: rely on trusted agents

aly1@agenthost.com

alice@a.b.com

Agent

  • Protection against:
  • Sloppy organizations
  • Malicious attackers

[Aggarwal’04]

summary on privacy
Summary on Privacy
  • Major concern in industry
    • Legislation
    • Consumer demand
  • Challenge:
    • How to enforce an organization’s stated policies
fine grained access control
Fine-grained Access Control

Control access at the tuple level.

  • Policy specification languages
  • Implementation
policy specification language
Policy Specification Language

No standard, but usually based on parameterized views.

CREATE AUTHORIZATION VIEW PatientsForDoctors AS

SELECT Patient.*

FROM Patient, Doctor WHERE Patient.doctorID = Doctor.ID

and Doctor.login = %currentUser

Contextparameters

implementation
Implementation

SELECT Patient.name, Patient.age

FROM Patient

WHERE Patient.disease = ‘flu’

SELECT Patient.name, Patient.age

FROM Patient, Doctor

WHERE Patient.disease = ‘flu’

and Patient.doctorID = Doctor.ID

and Patient.login = %currentUser

e.g. Oracle

two semantics
Two Semantics
  • The Truman Model = filter semantics
    • transform reality
    • ACCEPT all queries
    • REWRITE queries
    • Sometimes misleading results
  • The non-Truman model = deny semantics
    • reject queries
    • ACCEPT or REJECT queries
    • Execute query UNCHANGED
    • May define multiple security views for a user

SELECT count(*)FROM PatientsWHERE disease=‘flu’

[Rizvi’04]

summary of fine grained access control
Summary of Fine Grained Access Control
  • Trend in industry: label-based security
  • Killer app: application hosting
    • Independent franchises share a single table at headquarters (e.g., Holiday Inn)
    • Application runs under requester’s label, cannot see other labels
    • Headquarters runs Read queries over them
  • Oracle’s Virtual Private Database

[Rosenthal&Winslett’2004]

data encryption for publishing
Data Encryption for Publishing

Scientist wants to publish medical research data on the Web

  • Users and their keys:
  • Complex Policies:

All authorized users: Kuser

Patient: Kpat

Doctor: Kdr

Nurse: Knu

Administrator : Kadmin

Doctor researchers may access trials

Nurses may access diagnostic

Etc…

What is the encryption granularity ?

data encryption for publishing1
An XML tree protection:

Kuser

Kdr

Kpat (KnuKadm)

Knu  Kdr

Kpat

Kmaster

Kmaster

[Miklau&S.’03]

Data Encryption for Publishing

Doctor: Kuser, Kdr

Nurse: Kuser, Knu

Nurse+admin: Kuser, Knu, Kadm

<patient>

<privateData>

<diagnostic>

<trial>

flu

<name>

<age>

<address>

<drug>

<placebo>

28

Seattle

Tylenol

Candy

JoeDoe

summary on data encryption
Summary on Data Encryption
  • Industry:
    • Supported by all vendors: Oracle, DB2, SQL-Server
    • Efficiency issues still largely unresolved
  • Research:
    • Hard theoretical security analysis

[Abadi&Warinschi’05]

secure shared processing
Secure Shared Processing
  • Alice has a database DBA
  • Bob has a database DBB
  • How can they compute Q(DBA, DBB), without revealing their data ?
  • Long history in cryptography
  • Some database queries are easier than general case
secure shared processing1

Compute one-way hash

h(a) h(b) h(c) h(d)

h(c) h(d) h(e)

Exchange

h(c) h(d) h(e)

h(a) h(b) h(c) h(d)

[Agrawal’03]

Secure Shared Processing

Alice

Bob

Task: find intersectionwithout revealing the rest

a b c d

c d e

What’s wrong ?

secure shared processing2

EA

EB

EB(c) EB(d) EB(e)

EA(a) EA(b) EA(c) EA(d)

EB(c) EB(d) EB(e)

EA(a) EA(b) EA(c) EA(d)

EA

EB

h(c) h(d) h(e)

h(a) h(b) h(c) h(d)

h(a) h(b) h(c) h(d)

h(c) h(d) h(e)

[Agrawal’03]

Secure Shared Processing

Alice

commutative encryption:h(x) = EA(EB(x)) = EB(EA(x))

Bob

c d e

a b c d

summary on secure shared processing
Summary on Secure Shared Processing
  • Secure intersection, joins, data mining
  • But are there other examples ?
outline3
Outline
  • Traditional data security
  • Two attacks
  • Data security research today
  • Conclusions
conclusions
Conclusions
  • Traditional data security confined to one server
    • Security in SQL
    • Security in statistical databases
  • Attacks possible due to:
    • Poor implementation of security policies: SQL injection
    • Unintended information leakage in published data
conclusions1
Conclusions
  • State of the industry:
    • Data security policies: scattered throughout applications
    • Database no longer center of the security universe
    • Needed: automatic means to translate complex policies into physical implementations
  • State of research: data security in global data sharing
    • Information leakage, privacy, secure computations, etc.
    • Database research community has an increased appetite for cryptographic techniques