Data and Applications Security Developments and Directions

1. Data and Applications Security Developments and Directions Dr. Bhavani Thuraisingham The University of Texas at Dallas Lecture #5 Policies January 28, 2011

2. Outline of the Unit • Need to Know to Need to Share • Access Control (DAC, MAC) • RBAC • UCON • ABAC • Release and Dissemination • Risk based access control • Trust Management/Credential/Disclosure • Directions • Major conferences for Policy and Access Control: • IEEE Policy Workshop • ACM SACMAT

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

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

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

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

7. Security Constraints / 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

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

9. RBAC (Sandhu)

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

11. UCON (Sandhu)

12. ABAC • In attribute-based access control (ABAC), access is granted not based on the rights of the subject associated with a user after authentication, but based on attributes of the user. • The user has to prove so called claims about his attributes to the access control engine. • An attribute-based access control policy specifies which claims need to be satisfied in order to grant access to an object. For instance the claim could be "older than 18" . • Any user that can prove this claim is granted access.

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

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

15. Confidentiality, Privacy and Trust CPT • Trust • Trust is established between say a web site and a user based on credentials or reputations. • Privacy • When a user logs into a website to make say a purchase, the web site will specify that its privacy policies are. The user will then determine whether he/she wants to enter personal information. • That is, if the web site will give out say the user’s address to a third party, then the user can decide whether to enter this information. • However before the user enters the information, the user has to decide whether he trusts the web site. • This can be based on the credential and reputation. • if the user trusts the web site, then the user can enter his private information if he is satisfied with the policies. If not, he can choose not to enter the information. • Confidentiality • Here the user is requesting information from the web site; • the web site checks its confidentiality policies and decides what information to release to the user. • The web set can also check the trust it has on the user and decide whether to give the information to the user.

16. Policy Engine Interface to the System Technology By UTDallas Inference Engine/ Rules Processor e.g., Pellet Policies Ontologies Rules Data/Information Manager Documents

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

18. Trust Management

19. The problem: establishing trust in open systems • Mutual authentication - Assumption on the counterpart honesty no longer holds - Both participants need to authenticate each other • 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 ?

20. Trust Negotiationmodel • 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

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

22. CA CA CA 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 propertiesand attributes of the owner. CA

23. Use of Credentials Digital Credentials Credential Issuer • 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

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

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

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

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

28. Trust Negotiation - definition The gradual disclosure of credentials and requests for credentials between two strangers, with the goal of establishing sufficient trust so that the parties can exchange sensitive information and/or resources

29. Trust-X system: Joint Research with University of Milan • A comprehensive XML based framework for trust negotiations: • Trust negotiation language (X-TNL) • System architecture • Algorithms and strategies to carry out the negotiation process

30. Trust-X language: X-TNL • Able to handle mutliple and heterogeneus certificate specifications: • Credentials • Declarations • Able to help the user in customizing the management of his/her own certificates • X-Profile • Data Set • Able to define a wide range of protection requirements by means of disclosure policies

31. X-TNL: Credential type system X-TNL simplifies the task of credential specification by using a set of templates called credential types Uniqueness is ensured by use of XML Namespaces Credential types are defined by using Document Type Definition <!DOCTYPE library_badge[ <!ELEMENT library_badge (name, address, phone_number*, email?, release_date, profession,Issuer)> <!ELEMENT name (fname, lname)> <!ELEMENT address (#PCDATA)> <!ELEMENT phone_number (#PCDATA)> <!ELEMENT email (#PCDATA)> <!ELEMENT release_date (#PCDATA)> <!ELEMENT profession (#PCDATA)> <!ELEMENT fname (#PCDATA)> <!ELEMENT lname (#PCDATA)> <!ELEMENT Issuer ANY> <!ATTLIST Issuer XML:LINK CDATA #FIXED “SIMPLE” HREF CDATA #REQUIRED TITLE CDATA #IMPLIED> <!ATTLIST library_badge CredID ID #REQUIRED> <!ATTLIST library_badge SENS CDATA #REQUIRED> ]>

32. Policy Management for Assured Information Sharing • Daniel Wolfe (formerly of the NSA) defined assured information sharing (AIS) as a framework that “provides the ability to dynamically and securely share information at multiple classification levels among U.S., allied and coalition forces.” • The DoD’s vision for AIS is to “deliver the power of information to ensure mission success through an agile enterprise with freedom of maneuverability across the information environment” • 9/11 Commission report has stated that we need to migrate from a need-to-know to a need-to-share paradigm • Our objective is to help achieve this vision by defining an AIS lifecycle and developing a framework to realize it.

33. Architecture Data/Policy for Coalition Export Export Data/Policy Data/Policy Export Data/Policy Component Component Data/Policy for Data/Policy for Agency A Agency C Component Data/Policy for Agency B

34. Policy Enforcement PrototypeDeveloped at UTD Coalition

35. Architectural Elements of the Prototype • Policy Enforcement Point (PEP): • Enforces policies on requests sent by the Web Service. • Translates this request into an XACML request; sends it to the PDP. • Policy Decision Point (PDP): • Makes decisions regarding the request made by the web service. • Conveys the XACML request to the PEP. Policy Files: • Policy Files are written in XACML policy language. Policy Files specify rules for “Targets”. Each target is composed of 3 components: Subject, Resource and Action; each target is identified uniquely by its components taken together. The XACML request generated by the PEP contains the target. The PDP’s decision making capability lies in matching the target in the request file with the target in the policy file. These policy files are supplied by the owner of the databases (Entities in the coalition). Databases: • The entities participating in the coalition provide access to their databases.

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