Database Security

DB Security subsystem

• Authentication - ensures that a user is who he or she claims to be.

• Authorization - allows the user access to various resources based on the user's identity (a.k.a. permission, access right, privilege)

• Privacy - DBMS should provide confidentiality

Database Security

• Different aspects of database security – data encryption– allow retrieval of statistical information – Access control for a whole DBMS

• account numbers and passwords– Access control for portions of a database

• DB security and authorization subsystems secure portions of a DB against unauthorized access (4 approaches)

– Discretionary Access Control (DAC) – Mandatory Access Control (MAC) – Role Based Access Control (RBAC)– Attribute Based Access Control (ABAC)

Discretionary Access Control

DAC – from the beginning of time ...

Discretionary Access Control

• Based on granting and revoking privileges

• 2 levels for assigning privileges – account level (subject)

• independent of the relations • create schema, create table, create view

– relation level (object)

on a particular base relation or view

Access (authorization) matrix model• row - subject • column - object • M(i,j) -> read, write, update • for example M(a,B) = read means that subject a

holds read privilege on object B • Owner of the relation (typically the creator) is

assigned the owner account for that relation and is given all privileges on that relation

Grant/Revoke SQL statement

• Grant {privileges} on {table | view} to {user | public | role}

Grant select, delete on Employee, Department to Smith

• Revoke {privilege} on {table | view} from {user | public | role}

Revoke delete on Department from Smith

Using Views for Security

• Create view EMP as select Fname, Lname, address from Employee where dno=5;

Grant select on EMP to all;

Mandatory Access Control

MAC

Proposed in Mid 1980’s

Mandatory Access Control• Users have security clearances, data has security

classifications

• Need to restrict the access according to security level of user and data

• Useful for environments with hierarchical propagation of information

• Each subject and object are classified into one of the security classifications

• Security classes example:

– TS(Top Secret), S (Secret), C(Classified), U (Unclassified)

TS > S > C > U

Evolution of MLS models

• One way to utilize classification levels:– multilevel relation (MLS) schema– We will look at different MLS models to see

problems with each model and how these were addressed by the next model

Security Levels

• Properties: First must decide who can see which security level(s)?

Bell-LaPadulla properties

• All MLS Models are based on this

• Restrictions on data access –– simple property: No READ UP – star (*) property: No WRITE DOWN (write at

own level)

• Necessary but not sufficient conditions

• Still have problems – for example, covert channel

Designing MLS models

• How would you include different security levels in the data itself?– Add a classification level to PK?– Add a classification level to every attribute?

• Let us assume we have added a level for each column

MLS Relation Example

Vessel(PK) Objective Destination

Micra U Shipping U Moon U

Vision U Spying U Saturn U

Avenger C Spying C Mars C

Logos S Shipping S Venus S

Who sees what?

Vessel(PK) Objective Destination

Micra U Shipping U Moon U

Vision U Spying U Saturn U

Avenger C Spying C Mars C

Logos S Shipping S Venus S

MLS Insert

• What if a U user wants to insert a tuple with vessel = Avenger?

• 2 solutions:1. reject the insert, but?

• Covert channel

Covert Chanel

• Indirect downward flow of information– must be avoided since it allows downward

flow of information– Can occur if reject update– Can be used maliciously (higher level user

can signal lower level user)

MLS Insert

• What if a U user wants to insert a tuple with vessel = Avenger?2. Insert another Avenger

• Will have 2 avengers – problems?• 2 tuples with the same PK - Violates

uniqueness of relational model

MLS Relation

Vessel Objective Destination

Micra U Shipping U Moon U

Vision U Spying U Saturn U

Avenger U Shipping U Mars U

Avenger C Spying C Mars C

Logos S Shipping S Venus S

MLS Insert

• What does it mean to have 2 tuples with the same PK?– Does this mean there are 2 different Avengers– Or 1 Avenger with different info at different

classification levels?

MLS Update• What if the S level wants to update one of the

tuples at the U level? (Vision)

Update Vision so Destination is Venus• U should not see the update• Solutions

–Replicate the tuple – polyinstantiation

1. Put a null for the value at the U level?

2. Keep the old value at the U level?

Solution 1.

Vessel Objective Destination

Micra U Shipping U Moon U

Vision U Spying U Null U

Avenger U Shipping U Moon U

Avenger C Spying C Mars C

Vision U Spying U Venus S

Logos S Shipping S Venus S

Solution 2.

Vessel Objective Destination

Micra U Shipping U Moon U

Vision U Spying U Saturn U

Avenger U Shipping U Moon U

Avenger C Spying C Mars C

Vision U Spying U Venus S

Logos S Shipping S Venus S

MLS - Jajodia-Sandhu Model (JS)

• Jajodia-Sandhu was one of the first MLS models

• multilevel relation (MLS) schema – For each attribute, classification attribute C – Added a tuple classification TC

• Lowest user level that can see tuple

R(A1, C1, A2, C2, ...An, Cn, TC)

JS Relation Example

Vessel(PK) Objective Destination TC

Micra U Shipping U Moon U U

Vision U Spying U Saturn U U

Avenger C Spying C Mars C C

Logos S Shipping S Venus S S

JS Insert

• What if a U user wants to insert a tuple with vessel = Avenger? Insert another Avenger

JS Insert

Vessel Objective Destination TC

Micra U Shipping U Moon U U

Vision U Spying U Saturn U U

Avenger U Shipping U Mars U U

Avenger C Spying C Mars C C

Logos S Shipping S Venus S S

JS Insert

• JS model did not answer the question below:– Does this mean there are two different

Avengers or one Avenger with different info at different classification levels?

JS Update

• What if the S level wants to update Enterprise destination to Rigel?

JS Update

Vessel Objective Destination TCEnterprise U Exploration U Talos U U

S-user updates Enterprise destination to Rigel

Vessel Objective Destination TC

Enterprise U Exploration U null U U

Enterprise U Exploration U Rigel S S

What is view to U-user? S-user?

What does the null mean? Problem!

Covert channel?

JS Update

• U user wants to set Destination = Talos where Starship = ‘Enterprise”

JS UpdateVessel Objective Destination TCEnterprise U Exploration U null U UEnterprise U Exploration U Rigel S S

U user wants to set Destination = Talos where Starship = ‘Enterprise”

U view:Vessel Objective Destination TCEnterprise U Exploration U Talos U U

S View:Vessel Objective Destination TCEnterprise U Exploration U Talos U UEnterprise U Exploration U Rigel S S

JS Update

• Suppose S users want to update objective=spying where starship = ‘Enterprise” and destination =Rigel

JS UpdateU view:Vessel Objective Destination TCEnterprise U Exploration U Talos U U

S View:Vessel Objective Destination TCEnterprise U Exploration U Talos U UEnterprise U Exploration U Rigel S S

Suppose S users want to update objective=spying where starship = ‘Enterprise” and destination =‘Rigel’

S View:Vessel Objective Destination TCEnterprise U Exploration U Talos U UEnterprise U Spying S Rigel S S

JS Update

• Suppose U users want to update objective=spying where starship = ‘Enterprise” – There are 2 Enterprise tuples – both of which

have objective =Exploration at the U level– Should it only update the tuple with TC=U?

JS UpdateU view:Vessel Objective Destination TCEnterprise U Exploration U Talos U U

S View:Vessel Objective Destination TCEnterprise U Exploration U Talos U UEnterprise U Exploration U Rigel S S

U users want to update objective=Spying where starship = ‘Enterprise” S View:Vessel Objective Destination TCEnterprise U Spying U Talos U UEnterprise U Exploration U Rigel S S

JS Update

• Should the other Spying U be updated as well? • Should the Exploration change from U to S?• Not addressed in their early work • What does this mean?• Confusing?

Jajodia Sandhu MLS Model

• Entity integrity– What is the primary key?

• PK is now called the Apparent Key

• CAK is the classification of the PK

AK, CAK, Ci -> Ai

– Implies Primary key in MLS is:• AK U CAK U CR

• AK are data in PK, CAK is class of PK data, CR is data not in AK

JS model Integrity Constraints

• Entity integrity rule – all attributes that are members of the apparent key must not be

null and must have the same security classification within each individual tuple

• Null integrity– Nulls are classified at the level of the key– One tuple does not subsume another (null values subsumed by

non-null values)

• Inter-Instance Integrity– User can only see portion of relation for which is cleared (use

filters)– Data not cleared is set to null– Eliminate subsumed tuples

Examples of Polyinstantiation Integrity – JS model

Legal instance:Vessel Objective Destination TCEnterprise U Exploration U Talos U UVoyager U Exploration U Talos U UVoyager U Spying S Mars S S

Illegal instance: Why?Vessel Objective Destination TCVoyager U Exploration S Talos S SVoyager U Spying S Mars S S

JS Insert

Suppose S wants to insert (Enterprise, Spying, Rigel) into:

Vessel Objective Destination TCEnterprise U Exploration U Talos U U

After Insert

Vessel Objective Destination TCEnterprise U Exploration U Talos U UEnterprise S Spying S Rigel S S

Are these different or the same? Problem!

JS Insert

• But what does it all mean to have tuples at different classification levels?

• In the Jajodia Sandhu early model, this was not made clear

Winslett Smith Belief Model• Addressed some of these problems

– Tuples at user’s level believe info– See info at lower levels– Simplified: only 2 classification level columns

• KC and TC

R(K, KC, A1, A2, ... An, TC)• PK is K, KC and TC 

– Important: Every tuple has a base tuple – level at which first inserted

Winslett Smith Belief ModelCan distinguish between different beliefs

Vessel Objective Destination TCEnterprise U Exploration Talos UEnterprise S Spying Rigel S

U believes and sees:

Enterprise U Exploration Talos U

S sees U’s tuples, but believes the following:

Enterprise S Spying Rigel S

Winslett Smith Belief Model

Can distinguish between different entities, and the same entities•Different entities (different CAK):

Vessel Objective Destination TCEnterprise U Exploration Talos UEnterprise S Spying Rigel S

•The same entities (same CAK):

Vessel Objective Destination TCEnterprise U Exploration Talos UEnterprise U Spying Rigel S

MLR Model Sandhu Chen

• Relational operations still messy in Winslett/Smith– What about joins – if at different levels?

• Try to eliminate semantic ambiguity• Borrowing to indicate belief in lower level

tuples – Does it mean T or F?– Cannot indicate disbelief

Extensions to MLS model

• Belief consistent model (Jukic-Vrbsky)– Can easily see what others believe at lower

levels– Can assert if one level believes lower level

belief is false– Reduces tuple propagation– Useful for: e-Business and Customer

Relationship Modeling (CRM).

Belief consistent model

• Labels are positive or negative, positive means believes the value is true, negative means a false belief

Vessel Objective Destination TCEnterprise US Exploration US Talos U-S U-SEnterprise US Exploration U Rigel S S

• Enterprise US means one Enterprise• -S means destination Talos is not believed by the S level• If a classification level is not listed, it means it has no

belief

S has no belief in the Exploration U

• Too many labels for each column – confusing!

MLS Model

• MLS models never really became popular

• Why??

• However, in Oracle– Oracle Label Security in 10g

• Sensitivity labels and security clearances

Role Based Access Control

RBAC

Mid 1990’s-now

Motivation

• Many organizations:– Base access control in role of individual users– Want to centrally control and maintain access

rights– Access control needs are unique

• commercially available products lack flexibility

Motivation

• Roles define individuals and extent of resource access• Combination of users and permissions can change

– E.g. user membership in roles

• Permissions associated with roles stable• Administration of roles rather than permissions• Role permission predefined

– Easier to add/remove users membership than create new roles/permissions

• Roles part of SQL3 • Supported by many software products

– Roles used in Windows NT, XP (system admin)

Roles

• Role-based access control (RBAC)• Sandhu, R., Coyne, Feinstein, Youman: “Role-Based Access Contro

l Models”

– Semantic construct – System administrator creates roles according to job

functions

• Role – Specific task competency, duty assignments– Embody authority and responsibility

• Grant permissions to roles and users– Permissions & Roles, Roles & Users

Role hierarchies

• More powerful roles at top, less powerful on bottom

• Inherits up– Inheritance transitive– Multiple inheritance– Partial order - reflexive, transitive,

antisymmetric– Can create private roles not inherited

Constraints

• Mutually exclusive roles– User at most 1 role in ME set– Combinations of roles and permissions can be

prohibited

• Cardinality– Maximum number of members in a role– Minimum cardinality difficult to implement

• Prerequisite role– User assigned to role B, only if assigned to A– Permission p assigned to role only if role has

permission q

In Oracle

• Rather than grant privileges to individual users, can grant them to groups using roles

Create role role_name [identified by pw] Grant {privilege} [on {table}] to role_name

Grant role_name to user

The user must enable the role if a pw is specified with the command: Set role role_name identified by pw

DAC, MAC vs. RBAC

• DAC vs. MAC emerged from defense security research

• RBAC independent of access control

• RBAC can be used to implement DAC, MAC

Attribute Based Access Control

ABAC

Mid 2000’s

Why ABAC? – Web sharing

• No longer have stove-piped info systems • Instead: collaboration and info sharing• Must balance accessibility with protection• Currently

– Firewall, intrusion detection (HTTP) – can have potential attacks not detectable

– Need set of known users – may not be feasible– Simple, static, coarse grained (roles) – doesn’t take

into account current threat level, community of interest

ABAC

• Attribute Based Access Control– Motivation – web based services technologies

and service oriented architectures• Dynamic and adhoc

– Based on subject, object and environment attributes

• Supports MAC and DAC needs

– Slides based on: “Attribute Based Access Control ABAC for Web Services,” E. Yuan, J. Tong, ICWS’05.

ABAC

• Access granted based on attributes of user not rights of subject associated with user

• User must prove claims about his attributes

Standards

• Industry Standards– Security Assertions Markup Language (SAML)– Authentication/authorization represented as XML assertions– XML Access Control Markup Language (XACML) defined

architecture and policy language for access control– Web Services Security (WSS) foundation for Simple Object

Access Protocol (SOAP)• Security tokens, XML digital signature, XML encryption

• Standards focused on defining wire format not service-level semantics, different parties interface with each other, need end-to-end security

Definition of ABAC

• ABAC

– Policy model – defines ABAC policies

– Architecture model – applies policies

• Attributes

– Subject – entity (user, application, process) that acts on a resource

• Attributes: subject’s ID, name, organization, job title

– Resource – entity acted upon by subject

• Title, subject, date, author, ownership (extracted from metadata)

– Environment – operational, technical, situational• Current date/time, virus/hacker activities, network security

level– Not associated with a particular subject or resource

• Evaluation of policy rules – first order logic, forward chaining

Attributes

• ATTR(s) SA1 X SA2 X … X SAk

• ATTR(r) RA1 X RA2 X … X RAk

• ATTR(s) EA1 X EA2 X … X Eak

– Subjects have a Role, User ID and can be Customer with an address and credit rating or a Manager with a store and ssn)

– Resources have Owners and have names such as Previous purchases, NewPurchase, ApprovePurchase)

• Assign attributes to s, r, e– Role(s) = “Service Consumer”– ServiceOwner(r) = “XYZ, Inc.”– CurrentDate(e) = “01-23-2005”

Rules

• Rule : can_access (s, r, e) ← f(ATTR(s), ATTR(r), ATTR(e))

• Policy rules– Rule1: can_access(s, r, e) ← (Role(s)=‘Manager’) ^

(Name(r)=‘ApprovePurchase’) // RBAC– Rule2: can_access(s, r, e) ← (UserID(s) = ResourceOwner(r))

// resource can only be accessed by owner

ABAC vs RBAC:

• Example

RBAC– 3 roles: adult, juvenile, child– 3 permissions: can view R-rated movies, PG-

13 movies, G-rated movies– Adult all 3 permissions, juvenile 2, child 1

Example

ABAC

•Age is s attribute, rating r attribute

•Eliminates definition/management of static roles

Expand example

• Suppose expand to include new, old release

Changes to RBAC Changes to ABAC

Authorization Architecture• Attribute Authorities AA

– creating, managing attributes for s, r, e

– Binding attributes to entity of interest

• Policy Enforcement Point PEP

– requesting and enforcing authorization

decisions

– Point of presence for access control, cannot be bypassed

• Policy Decision Point PDP

– Evaluating policies and making authorization decisions

– When policy references s, r, or e, contacts AA to retrieve attribute values

• Policy Authority PA

– Create/manages access control policies

Securing Web Services

Implementation

• JAX-RPC message handlers to intercept SOAP request messages

• Policy decision services implemented using Apache Axis

• Policy stored and retrieved in XACML

Advantages of ABAC

• Intuitive to model• More flexible and powerful• Management of security can be distributed over

network (AA, PA)• ABAC can be used to implement DAC, MAC,

RBAC