1. Database Security

2. 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

3. 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)

4. Discretionary Access Control
DAC – from the beginning of time ...

5. 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

6. 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

7. 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

8. Using Views for Security
Create view EMP as select Fname, Lname, address from Employee where dno=5;
Grant select on EMP to all;

9. Mandatory Access Control
MAC
Proposed in Mid 1980’s

10. 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

11. 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

12. Security Levels
Properties: First must decide who can see which security level(s)?

13. 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

14. 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

15. 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

16. 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

17. MLS Insert
What if a U user wants to insert a tuple with vessel = Avenger?
2 solutions:
reject the insert, but?
Covert channel

18. 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)

19. 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

20. 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

21. 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?

22. 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
Put a null for the value at the U level?
Keep the old value at the U level?

23. 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

24. 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

25. 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)

26. 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

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

28. 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

29. 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?

30. JS Update
What if the S level wants to update Enterprise destination to Rigel?

31. JS Update Vessel Objective Destination TC
Enterprise 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?

32. JS Update
U user wants to set Destination = Talos where Starship = ‘Enterprise”

33. JS Update Vessel Objective Destination TC
Enterprise U Exploration U null U U
Enterprise U Exploration U Rigel S S
U user wants to set Destination = Talos where Starship = ‘Enterprise”
U view:
Enterprise U Exploration U Talos U U
S View:
Enterprise U Exploration U Rigel S S

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

35. JS Update U view: Vessel Objective Destination TC
Enterprise U Exploration U Talos U U
S View:
Enterprise U Exploration U Rigel S S
Suppose S users want to update objective=spying where starship = ‘Enterprise” and destination =‘Rigel’
Vessel Objective Destination TC
Enterprise U Exploration U Talos U U
Enterprise U Spying S Rigel S S

36. 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?

37. JS Update U view: Vessel Objective Destination TC
Enterprise U Exploration U Talos U U
S View:
Enterprise U Exploration U Rigel S S
U users want to update objective=Spying where starship = ‘Enterprise”
Vessel Objective Destination TC
Enterprise U Spying U Talos U U
Enterprise U Exploration U Rigel S S

38. 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?

39. 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

40. 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

41. Examples of Polyinstantiation Integrity – JS model
Legal instance:
Vessel Objective Destination TC
Enterprise U Exploration U Talos U U
Voyager U Exploration U Talos U U
Voyager U Spying S Mars S S
Illegal instance: Why?
Voyager U Exploration S Talos S S

42. JS Insert Suppose S wants to insert (Enterprise, Spying, Rigel) into:
Vessel Objective Destination TC
Enterprise U Exploration U Talos U U
After Insert
Vessel Objective Destination TC
Enterprise S Spying S Rigel S S
Are these different or the same? Problem!

43. 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

44. 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

45. 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:
S sees U’s tuples, but believes the following:

46. 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):
Enterprise U Spying Rigel S

47. 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

48. 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).

49. Belief consistent model
Labels are positive or negative, positive means believes the value is true, negative means a false belief
Vessel Objective Destination TC
Enterprise US Exploration US Talos U-S U-S
Enterprise 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!

50. MLS Model MLS models never really became popular Why??
However, in Oracle
Oracle Label Security in 10g
Sensitivity labels and security clearances

51. Role Based Access Control
RBAC
Mid 1990’s-now

52. 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

53. 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)

54. Roles Role-based access control (RBAC) Role
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

55. 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

57. Constraints Mutually exclusive roles Cardinality Prerequisite role
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

58. 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

59. 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

60. Attribute Based Access Control
ABAC
Mid 2000’s

61. 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

62. 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.

63. ABAC
Access granted based on attributes of user not rights of subject associated with user
User must prove claims about his attributes

64. 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

65. Definition of ABAC Environment – operational, technical, situational
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

66. 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) = “ ”

67. 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

68. 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

69. Example ABAC Age is s attribute, rating r attribute
Eliminates definition/management of static roles

70. Expand example Suppose expand to include new, old release
Changes to RBAC Changes to ABAC

71. 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

72. Securing Web Services

73. Implementation
JAX-RPC message handlers to intercept SOAP request messages
Policy decision services implemented using Apache Axis
Policy stored and retrieved in XACML

74. 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