database security - farkas 1 database security and privacy

Database Security - Farkas 1

Database SecurityDatabase Securityand Privacyand Privacy

2Database Security - Farkas

Security ObjectivesSecurity Objectives

Secrecy

Prevent/detect/deter improperDisclosure of information

Availability

Prevent/detect/deter improperDenial of access to services

Integrity

Prevent/detect/deter Improper modificationof information


PolicyPolicyOrganizational policyOrganizational policy

Information systems policyInformation systems policy

DatabasesDatabases

Collection of Collection of interrelated data andinterrelated data and set of programs to access the data set of programs to access the data

ConvenientConvenient and and efficientefficient processing processing of dataof data

Database Application SoftwareDatabase Application Software


Database SecurityDatabase Security Protect Sensitive Data fromProtect Sensitive Data from

Unauthorized disclosureUnauthorized disclosure Unauthorized modificationUnauthorized modification Denial of service attacksDenial of service attacks

Security ControlsSecurity Controls Security PolicySecurity Policy Access control modelsAccess control models Integrity protectionIntegrity protection Privacy problemsPrivacy problems Fault tolerance and recoveryFault tolerance and recovery Auditing Auditing and intrusion detectionand intrusion detection



Protection of Data Confidentiality

Access control Access control – which data users can access

Information flow control Information flow control – what users can do with the accessed data

Data MiningData Mining


Access Control

Ensures that all direct accesses direct accesses to object are authorized

Protects against accidental and malicious threats by regulating the read, write and read, write and execution execution of data and programs


Access ControlAccess Control

Requires:Requires:

- Proper - Proper user identificationuser identification

- Information specifying the - Information specifying the access rights access rights is protected is protected form modificationform modification


Access control components:- Access control policyAccess control policy: specifies the authorized accesses of a system- Access control mechanismAccess control mechanism: implements and enforces the policy

Access Control

HOW TO SPECIFY ACCESS HOW TO SPECIFY ACCESS CONTROL?CONTROL?



Access ControlAccess Control

SubjectSubject:: active entity that requests access to an active entity that requests access to an object object - e.g., user or program- e.g., user or program

Object: Object: passive entity accessed by a subjectpassive entity accessed by a subject- e.g., record, relation, file- e.g., record, relation, file

Access right Access right (privileges): how a subject is (privileges): how a subject is allowed to access an objectallowed to access an object- e.g., subject - e.g., subject ss can read object can read object oo


Protection ObjectProtection Object

DatabaseDatabase RelationRelation RecordRecord AttributeAttribute Element Element

Advantages vs. disadvantages of supporting

different granularity levels


Relation-Level Relation-Level GranularityGranularity

Person-Person-namename

Company-Company-namename

SalarySalary

SmithSmith BB&CBB&C $43,982$43,982

DellDell BellBell $97,900$97,900

Black Black BB&CBB&C $35,652$35,652

Confidential relation


Tuple-level GranularityTuple-level Granularity

Person-namePerson-name Company-Company-namename

Salary Salary

SmithSmith BB&CBB&C $43,982 Public$43,982 Public

DellDell BellBell $97,900 Conf.$97,900 Conf.

Black Black BB&CBB&C $35,652 Public$35,652 Public

Works


Attribute-Level Attribute-Level GranularityGranularity

Person- Person- name name Publ.

Company-Company-name Publ.name Publ.

SalarySalary

Conf.Conf.

SmithSmith BB&CBB&C $43,982$43,982

DellDell BellBell $97,900$97,900

Black Black BB&CBB&C $35,652$35,652

Works


Cell-Level GranularityCell-Level Granularity

Person-Person-namename

Company-Company-namename

SalarySalary

Smith PSmith P BB&C PBB&C P $43,982 C$43,982 C

Dell CDell C Bell CBell C $97,900 C$97,900 C

Black PBlack P BB&C CBB&C C $35,652 C$35,652 C

Works


Access Control Policies

Discretionary Access Control (DACDAC) Mandatory Access Control (MACMAC) Role-Based Access Control (RBACRBAC)


Discretionary Access Control (DAC)

For each subject each subject access right to the objects are defined (subject, object, +/- access mode) (Black, Employee-relation, read)

User based Grant and RevokeGrant and Revoke Problems:

- Propagation of access rights- Revocation of propagated access rights


DAC by Grant and RevokeDAC by Grant and Revoke

Brown (owner)

Black Red

White

GRANT SELECT ON EmployeeTO Red

GRANT SELECT ON EmployeeTO BlackWITH GRANT OPTION ?

Brown revokes grantgiven to Black

?Brown does not want Red to access the Employee relation

GRANT UPDATE(Salary) ON Employee TO White


ImplementationImplementationAccess Control List (column)

File 1 File 2Joe:Read Joe:ReadJoe:Write Sam:ReadJoe:Own Sam:Write

Sam:OwnCapability List (row)Joe: File 1/Read, File 1/Write, File 1/Own, File 2/ReadSam: File 2/Read, File 2/Write, File 2/Own

Access Control TriplesSubject Access ObjectJoe Read File 1Joe Write File 1Joe Own File 1Joe Read File 2Sam Read File 2Sam Write File 2Sam Own File 2

(ACL)


Access Control MechanismsAccess Control Mechanisms

Security through ViewsSecurity through Views Stored ProceduresStored Procedures Grant and RevokeGrant and Revoke Query modificationQuery modification


Security Through Views

Assign rights to access predefined viewsCREATE VIEW Outstanding-Student AS SELECT NAME, COURSE, GRADEFROM StudentWHERE GRADE > B

Problem:

Difficult to maintain updates.


Stored ProceduresStored Procedures Assign rights to execute compiled programsAssign rights to execute compiled programs GRANT RUN ON <program> TO <user>GRANT RUN ON <program> TO <user>

Problem:Problem:

Programs may access resources for which the user Programs may access resources for which the user who runs the program does not have permission. who runs the program does not have permission.


Grant and RevokeGrant and RevokeGRANT <privilege> ON <relation>GRANT <privilege> ON <relation>To <user>To <user>[WITH GRANT OPTION][WITH GRANT OPTION]------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

GRANT SELECT * ON GRANT SELECT * ON StudentStudent TO Matthews TO Matthews GRANT SELECT *, UPDATE(GRADE) ON GRANT SELECT *, UPDATE(GRADE) ON StudentStudent

TO FARKASTO FARKAS GRANT SELECT(NAME) ON GRANT SELECT(NAME) ON StudentStudent TO Brown TO Brown

GRANT command applies to base relations as well GRANT command applies to base relations as well as viewsas views


Grant and RevokeGrant and RevokeREVOKE <privileges> [ON REVOKE <privileges> [ON

<relation>]<relation>]

FROM <user>FROM <user>--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

REVOKE SELECT* ON REVOKE SELECT* ON StudentStudent FROM Blue FROM Blue REVOKE UPDATE ON REVOKE UPDATE ON StudentStudent FROM Black FROM Black REVOKE SELECT(NAME) ON REVOKE SELECT(NAME) ON StudentStudent FROM FROM

BrownBrown


Non-cascading RevokeNon-cascading Revoke

A

B

C

D

E

F

A

B

C

A revokes D’s privileges

E

F


Cascading RevokeCascading Revoke

A

B

C

D

E

F

A

B

C

A revokes D’s privileges


Positive and Negative Positive and Negative AuthorizationAuthorization

Problem:Contradictory authorizations• GRANT <privilege> ON X TO <user>• DENY <privilege> ON X TO <user>

A

B

C

E

D

+

-

+

-


Negative AuthorizationNegative Authorization

A

B

C

E

D

+

-

+

-

-

F

+

What should happen with the privilege given by DTo F?


Query ModificationQuery Modification GRANT SELECT(NAME) ON GRANT SELECT(NAME) ON StudentStudent TO Blue TO Blue

WHERE COURSE=“CSCEWHERE COURSE=“CSCE 590” 590”

Blue’s query:Blue’s query:SELECT * SELECT * FROM FROM StudentStudent

Modified query:Modified query:SELECT NAMESELECT NAMEFROM FROM StudentStudentWHERE COURSE=“CSCE 590”WHERE COURSE=“CSCE 590”


DAC OverviewDAC Overview Advantages:Advantages:

IntuitiveIntuitive Easy to implementEasy to implement

Disadvantages:Disadvantages: Inherent vulnerability (look TH Inherent vulnerability (look TH

example)example) Maintenance of ACL or Capability listsMaintenance of ACL or Capability lists Maintenance of Grant/RevokeMaintenance of Grant/Revoke Limited power of negative authorizationLimited power of negative authorization


Mandatory Access Control (MAC)

Security labelSecurity label- Top-Secret, Secret, Public

ObjectsObjects: security classification - File 1 is Secret, File 2 is Public

SubjectsSubjects: security clearances- Brown is cleared to Secret, Black is cleared to Public

DominanceDominance ()- Top-Secret Secret Public


MAC

Access rightsAccess rights: defined by comparing the security classification of the requested objects with the security clearance of the subject

If access control rules access control rules are satisfied, access is permitted

Otherwise access is rejected GranularityGranularity of access rights!


MAC – Bell-LaPadula (BLP) ModelMAC – Bell-LaPadula (BLP) Model

Single security propertySingle security property: a subject S is allowed a : a subject S is allowed a read access to an object O only if label(S) read access to an object O only if label(S) dominates label(O)dominates label(O)

Star-property:Star-property: a subject S is allowed a write access a subject S is allowed a write access to an object O only if label(O) dominates label(S) to an object O only if label(O) dominates label(S)

No direct flow of information from high security objects to low security objects!

Multilevel Security Multilevel Security

Multilevel security Multilevel security users at users at different security level, see different different security level, see different versions of the databaseversions of the database

ProblemProblem: : different versionsdifferent versions need to need to be kept consistent and coherent be kept consistent and coherent without downward signaling channelwithout downward signaling channel (covert channel)(covert channel)


Multilevel RelationMultilevel Relation

Schema R(ASchema R(A11,C,C11,…,A,…,Ann,C,Cnn,T,Tcc)) R: relation nameR: relation name AAii: attribute name: attribute name CCii: security classes: security classes TTcc: Tuple security classes: Tuple security classes

Instantiation of relation: sets of tuples of Instantiation of relation: sets of tuples of the form <athe form <a11,c,c11,…,a,…,ann,c,cnn,t,tcc>> aaii: attribute value: attribute value ccii: attribute classification label: attribute classification label ttcc: tuple classification label: tuple classification label


37Database Security - FarkasCSCE 790 - Farkas37

Multilevel Relation Multilevel Relation ExampleExample

SSN (SSN) Course (Course) Grade (Grade)

111-22-3333 S CSCE 786 S A TS

444-55-6666 S CSCE 567 S C TS

Top-secret user sees all dataSecret user sees Secret-ViewSecret-View:


111-22-3333 S CSCE 786 S null S

444-55-6666 S CSCE 567 S null S


PolyinstantiationSecret user sees Secret-View:


111-22-3333 S CSCE 786 S null S

444-55-6666 S CSCE 567 S null S

•SSN is primary key•Secret user wants to update Grade for 111-22-3333 from null (i.e., missing value) to F

•Allow update: inconsistent database, at TS level two different tuples exist with the same primary key (see next slide)

•Not allow update: downward signaling channel, update isbecause of the existence of a TS value


Polyinstantiation


111-22-3333 S CSCE 786 S A TS

111-22-3333 S CSCE 786 S F S

444-55-6666 S CSCE 567 S C TS

Top-Secret View:

database security - farkas 1 database security and privacy

Documents

policy access control

access rights

file access

privacy slide

data users

sensitive data

interrelated data

execution of data