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

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

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

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

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)

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

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

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?

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?

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

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

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

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?

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

RBAC (Sandhu)

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

UCON (Sandhu)

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.

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

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)

Trust Management

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.

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

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

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

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 http://www.credentica.com/technology/overview.pdf Want to know citizenship

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

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

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

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]

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