Database Security DB Security subsystem Authentication ensures that

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 > 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-La. Padulla 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(A 1, C 1, A 2, C 2, . . . 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 Enterprise U Exploration U Destination TC 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 Update Vessel Enterprise U Objective Exploration U Destination TC null U Rigel S U S U user wants to set Destination = Talos where Starship = ‘Enterprise” U view: Vessel Enterprise U Objective Exploration U Destination TC Talos U U S View: Vessel Enterprise U Objective Exploration U Destination TC Talos U U Rigel S S

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

JS Update U view: Vessel Enterprise U Objective Destination TC Exploration U Talos U U S View: Vessel Enterprise U Objective Destination TC Exploration U Talos 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 TC Enterprise U Exploration U Talos U U Enterprise 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 Update U view: Vessel Enterprise U Objective Destination TC Exploration U Talos U U S View: Vessel Enterprise U Objective Destination TC Exploration U Talos U Exploration U Rigel S S U users want to update objective=Spying where starship = ‘Enterprise” S View: Vessel Objective Destination TC Enterprise U Spying U Talos U U Enterprise 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, Ci -> Ai – Implies Primary key in MLS is: • AK 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 Enterprise U Exploration U Voyager U Spying S Destination TC Talos U U Talos U U Mars S S Illegal instance: Why? Vessel Objective Voyager U Exploration S Voyager U Spying S Destination TC Talos S S Mars S S

JS Insert Suppose S wants to insert (Enterprise, Spying, Rigel) into: Vessel Enterprise U Objective Exploration U Destination TC Talos U U Objective Exploration U Spying S Destination TC Talos U U Rigel S S After Insert Vessel Enterprise U Enterprise 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, A 1, A 2, . . . An, TC) • PK is K, KC and TC – Important: Every tuple has a base tuple – level at which first inserted

Winslett Smith Belief Model Can distinguish between different beliefs Vessel Objective Destination TC Enterprise U Exploration Talos U Enterprise 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 TC Enterprise U Exploration Talos U Enterprise S Spying Rigel S • The same entities (same CAK): Vessel Objective Destination TC Enterprise U Exploration Talos U Enterprise 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 Enterprise US Objective Exploration US Exploration U Destination TC Talos U-S Rigel 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 10 g • 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 SQL 3 • 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 Control 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_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_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-toend 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) SA 1 X SA 2 X … X SAk • ATTR(r) RA 1 X RA 2 X … X RAk • ATTR(s) EA 1 X EA 2 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, New. Purchase, Approve. Purchase) • Assign attributes to s, r, e – Role(s) = “Service Consumer” – Service. Owner(r) = “XYZ, Inc. ” – Current. Date(e) = “ 01 -23 -2005”

Rules • Rule : can_access (s, r, e) ← f(ATTR(s), ATTR(r), ATTR(e)) • Policy rules – Rule 1: can_access(s, r, e) ← (Role(s)=‘Manager’) ^ (Name(r)=‘Approve. Purchase’) // RBAC – Rule 2: can_access(s, r, e) ← (User. ID(s) = Resource. Owner(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