1. Access Control in Data Management Systems
Dr. Bhavani Thuraisingham
The University of Texas at Dallas
Access Control and Policies in
Data Management Systems
June 2012

2. Outline Discretionary Access Control in Relational Databases
Mandatory Access Control in Relational Databases
Security Constraints
Types of Access Control
Inference problem, Role-based, Temporal, Usage
Access Control in Other Databases
Objects, Federated
Current Trends in Access Control
Date Warehousing, Semantic Web, Privacy Control
Next Steps in Access Control

3. Access Control in Relational Databases: 1975 - Present
Access Control policies were developed initially for file systems
E.g., Read/write policies for files
Access control in databases started with the work in System R and Ingres Projects
Access Control rules were defined for databases, relations, tuples, attributes and elements
SQL and QUEL languages were extended
GRANT and REVOKE Statements
Read access on EMP to User group A Where EMP.Salary < 30K and EMP.Dept <> Security
Query Modification:
Modify the query according to the access control rules
Retrieve all employee information where salary < 30K and Dept is not Security

4. Query Modification Algorithm
Inputs: Query, Access Control Rules
Output: Modified Query
Algorithm:
Given a query Q, examine all the access control rules relevant to the query
Introduce a Where Clause to the query that negates access to the relevant attributes in the access control rules
Example: rules are John does not have access to Salary in EMP and Budget in DEPT
Query is to join the EMP and DEPT relations on Dept #
Modify the query to Join EMP and DEPT on Dept # and project on all attributes except Salary and Budget
Output is the resulting query

5. Mandatory Access Control (MAC) in Databases: 1982- Present
Bell and LaPadula Policy adapted for databases
Read at or above your level and Write at your level; Granularity of classification: Databases, Relations, Tuples, Attributes, Elements
Security Architectures
Operating system providing mandatory access control and DBMS is untrusted with respect to MAC (e.g., SRI’s SeaView)
Trusted Subject Architecture where DBMS is trusted with respect to MAC (e.g., TRW’s ASD and ASD Views)
Integrity Lock where Trusted front-end computes checksums (e.g., MITRE’s MISTRESS Prototype)
Distributed Architecture where data is distributed according to security levels and access through trusted front-end (e.g., NRL’s SINTRA) Extended Kernel for Security Policy Enforcement such as constraints (e.g., Honeywell’s Lock Data Views)

6. Security Policies / Access Control Rules
Simple Constraint: John cannot access the attribute Salary of relation EMP
Content-based constraint: If relation MISS contains information about missions in the Middle East, then John cannot access MISS
Association-based Constraint: Ship’s location and mission taken together cannot be accessed by John; individually each attribute can be accessed by John
Release constraint: After X is released Y cannot be accessed by John
Aggregate Constraints: Ten or more tuples taken together cannot be accessed by John
Dynamic Constraints: After the Mission, information about the mission can be accessed by John

7. Enforcement of Security Policies/Constraints
User Interface Manager
Security Constraints
Constraint
Manager
Database Design Tool
Constraints during database design operation
Update Processor:
Constraints during update operation
Query Processor:
Constraints during query and release operations
Relational DBMS
Database

8. Other Developments in Access Control
Inference Problem and Access Control
Inference problem occurs when users pose queries and deduce unauthorized information from the legitimate responses
Security constraint processing for controlling inferences
More recently there is work on controlling release information instead of controlling access to information
Temporal Access Control Models
Incorporates time parameter into the access control models
Role-based access control
Controlling access based on roles of people and the activities they carry out; Implemented in commercial systems
Positive and Negative Authorizations
Should negative authorizations be explicitly specified? How can conflicts be resolved?

9. Some Examples Temporal Access Control
After 1/1/05, only doctors have access to medical records
Role-based Access Control
Manager has access to salary information
Project leader has access to project budgets, but he does not have access to salary information
What happens is the manager is also the project leader?
Positive and Negative Authorizations
John has write access to EMP
John does not have read access to DEPT
John does not have write access to Salary attribute in EMP
How are conflicts resolved?

10. Access Control in Other Types of Databases
Object Databases
Controlling access to classes, object instances, instance variables, method execution etc.
E.g., MCC’s ORION model both for discretionary security and mandatory security
Distributed Databases
Extend access control for relational databases to a distributed environment across the nodes
Federated Databases
Integrate security policies exported by the component database systems and form a federated policy
Deductive Databases
Logic for secure data and knowledge base systems – e.g., NTML Non-monotonic Typed Multilevel Logic

11. Access Control in Databases: Current Trends (1996 – Present)
Data Warehousing
Controlling access to aggregate information in the Warehouse
Multimedia Database Systems
Geospatial Information Systems
Web Databases
E-Commerce and Knowledge Management, Collaboration/Workflow
Semantic Web
XML, RDF, Information Integration
Dependable Databases
Real-time/Embedded Database Systems
Sensor/Stream Database Systems

12. Policies Need to Know to Need to Share RBAC UCON Dissemination
Risk based access control
Trust Management/Credential/Disclosure
Directions
Major conferences for Policy and Access Control:
IEEE Policy Workshop
ACM SACMAT

13. Need to Know to Need to Share
Need to know policies during the cold war; even if the user has access, does the user have a need to know?
Pose 9/11 the emphasis is on need to share
User may not have access, but needs the data
Do we give the data to the user and then analyze the consequences
Do we analyze the consequences and then determine the actions to take
Do we simply not give the data to the user
What are risks involved?

14. RBAC
Access to information sources including structured and unstructured data both within the organization and external to the organization
Access based on roles
Hierarchy of roles: handling conflicts
Controlled dissemination and sharing of the data

15. RBAC (Sandhu)

16. UCON
RBAC model is incorporated into UCON and useful for various applications
Authorization component
Obligations
Obligations are actions required to be performed before an access is permitted
Obligations can be used to determine whether an expensive knowledge search is required
Attribute Mutability
Used to control the scope of the knowledge search
Condition
Can be used for resource usage policies to be relaxed or tightened

17. UCON (Sandhu)

18. Dissemination Policies
Release policies will determine to whom to release the data
What is the connection to access control
Is access control sufficient
Once the data is retrieved from the information source (e.g., database) should it be released to the user
Once the data is released, dissemination policies will determine who the data can be given to
Electronic music, etc.

19. Risk Based Data Sharing/Access Control
What are the risks involved in releasing/disseminating the data
Risk modeling should be integrated with the access control model
Simple method: assign risk values
Higher the risk, lower the sharing
What is the cost of releasing the data?
Cost/Risk/Security closely related

20. Trust Management Trust Services
Identify services, authorization services, reputation services
Trust negotiation (TN)
Digital credentials, Disclosure policies
TN Requirements
Language requirements
Semantics, constraints, policies
System requirements
Credential ownership, validity, alternative negotiation strategies, privacy
Example TN systems
KeyNote and Trust-X (U of Milan), TrustBuilder (UIUC)

21. Trust Management

22. The problem: establishing trust in open systems
Interactions between strangers
- In conventional systems user identity is known in advance
and can be used for performing access control
- In open systems partecipants may have no pre-existing
relationship and may not share a common security domain ?
Mutual authentication
- Assumption on the counterpart honesty no longer holds
- Both participants need to authenticate each other
The Internet, being a standard way to communicate, has become a standard way to exchange information or perform electronic transactions from anywhere in the world. Purchasing products and services online is becoming a way of life for millions of people and businesses. The information exchanged between parties on the Internet in most cases is sensitive and must be protected.
The communicating parties most often are strangers because they do not share the same security domain and will not have a local login. Traditional security approaches require a stranger to pre-register in order to establish trust, but the traditional way is not good enough. The client usually has no proof of the server’s identity, and the server cannot really trust that you are who you said you were on the registration form, so the paradox between strangers continues.

23. Trust Negotiation model
A promising approach for open systems where most of the interactions occur between strangers
The goal: establish trust between parties in order to exchange sensitive information and services
The approach: establish trust by verifying properties of the other party
costituisce un nuovo approccio alla realizzazione di sistemi di autorizzazione tra soggetti sconosciuti

24. Trust negotiation: the approach
Interactions between strangers in open systems
are different from traditional access control models
Policies and mechanisms developed in conventional systems need to be revised
ACCESS CONTROL POLICIES
VS.
DISCLOSURE POLICIES
USER ID’s
VS.
SUBJECT PROPERTIES

25. Subject properties: digital credentials
Assertion about the credential owner issued and certified by a Certification Authority.
Each entity has an associated set of credentials,
describing properties and attributes of the owner. CA CA CA

26. Use of Credentials Digital Credentials Credential Issuer Alice Check
Julie
3 kids
Married
American
Alice
Check
Check
-Julie
- Married
-Julie
- American
Company B
Want to know marital status
Company A
Referenced from
Want to know citizenship

27. Credentials
Credentials can be expressed through the Security Assertion Mark-up Language (SAML)
SAML allows a party to express security statements about a given subject
Authentication statements
Attribute statements
Authorization decision statements

28. Disclosure policies Disclosure policies Disclosure policies govern:
Access to protected resources
Access to sensitive information
Disclosure of sensitive credentials
Disclosure policies express trust requirements by means of credential combinations that must be disclosed to obtain authorization
Access control policies work well in closed systems with a known set of subjects and static objects.
The targeting of our research is an open environment where subjects are characterized by their role or other attributes.
Policies must express trust requirements by means of credentials proving properties of the counterpart

29. Disclosure policies - Example
Suppose NBG Bank offers loans to students
To check the eligibility of the requester, the Bank asks the student to present the following credentials
The student card
The ID card
Social Security Card
Financial information – either a copy of the Federal Income Tax Return or a bank statement

30. Disclosure policies - Example
p1= ({}, Student_Loan  Student_Card());
p2= ({p1}), Student_Loan  Social_Security_Card());
p3= ({p2}, Student_Loan  Federal_Income_Tax_Return());
p4= ({p2}, Student_Loan  Bank_Statement());
P5=({p3,p4}, Student_Loan  DELIV);
These policies result in two distinct “policy chains” that lead to disclosure
[p1, p2, p3, p5] [p1, p2, p4, p5]

31. Directions
Policies are of much interest to many organizations and applications
Financial, Medical, Retail, Manufacturing etc
Roles and responsibilities
Flexible policies
RBAC, UCON, RBUC, Trust Negotiation, Dissemination Policies
Need to Know to Need to Share
IEEE POLICY and ACM SACMAT