POLIPO: Policies & OntoLogies for Interoperability, Portability, and autOnomy Daniel Trivellato

Outline Problem Definition Approach POLIPO Language requirements Policy language syntax Reputation system Credential Chain Discovery Algorithm

Example Scenario NATO surveillance mission Goals USA GBR CANADA ITA read if Senior Officer Senior Officer??? NATO Definitions Senior Officer is an Officer with at least 10 years of service Aaahhhhhh!!!!

Problem Definition (1/2) Goal: Situational awareness in a System of Systems independent, heterogeneous components  DISTRIBUTED AUTHORITY MUTUAL UNDERSTANDING dynamic (re-)configurations (join and leave)  AVAILABILITY ACCOUNTABILITY

Problem Definition (2/2) Security goals: protection of sensitive data from unauthorized disclosure, using content- and context-aware security policies secure interaction between (possibly untrusted) parties of dynamic coalitions interoperability between heterogeneous systems and policy models, tuning local policies to ensure global security

Proposed Solutions Access Control to specify the permissions of subjects on objects Trust Management to establish trust between unknown parties Ontologies to enable mutual- understanding

Ontologies (1/2) Formally represent domain knowledge Define concepts, instances and (binary) relationships in a domain Constraints allow to infer information not explicitly stated Each ontology can refer to concepts defined in another ontology (reusability) MO:Officer PSD:Junior Officer MO:worksFor NATO:Allied Country JackJohn NL PSD:Senior Officer

Ontologies (2/2) Ontologies can be used to give semantics to predicates in rules Ontologies can also be used to align AC models However, in a distributed system … two entities may refer to the same object with different names two entities may use the same name to refer to different objects

The POLIPO Framework

Application Domains Semantic Web Data protection on the web Business Processes for Web Services Virtual organizations Maritime Safety and Security (MSS) Healthcare Business to Business (B2B)

Language Requirements Requirement 1: INTEROPERABILITY Requirement 2: AUTONOMY Requirement 3: PORTABILITY

Parties shall be able to interact with each other unambiguously Ontologies denote the semantics of concepts and relationships in the domain R1 - Interoperability

R2 - Autonomy Every party shall be able to design and express its policy autonomously A party must be able to specify its policy independently from the actions and definitions of other parties

Global ontology Officer JuniorSenior Officer Temporary Party 1 DISJOINT Example  Local extensions to the global ontology  Mappings from local to global concepts WHO DOES THE MAPPINGS? HOW DO WE GUARANTEE THEIR CORRECTNESS? Officer Temporary Party 2

R3 - Portability Remote evaluation of policies shall preserve the interpretation of the policy owner Remote policy evaluations should not grant any permission that would not be granted by a local evaluation Use credentials to preserve interpretation of the policy owner

Language Syntax Atoms Atoms are used to build rules Sets of rules make policies

Ontology atoms: queries to the knowledge base, represented by an ontology e.g., psd:SeniorOfficer(‘John’) psd:worksFor(‘John’,’BS’) Credential atoms e.g., cred (‘BS’,’psd:SeniorOfficer’,’John’, [(‘psd:validUntil’,’31/12/2009’]) Authorization atoms e.g., perm (‘psd:read’, ‘John’, ‘File’) Constraints: built-ins or user-defined predicates e.g., X = Y + 3, aboutSuveillance(‘File’) Syntax: Basic Constructs

Horn clauses of the form h  b 1,…,b n h (head) is an atom b 1,…,b n (body) are literals (i.e. positive or negative atoms) Negation is treated as negation as failure Safety condition: each variable in h, in a negative literal, or in a built-in also occurs in a positive body literal Syntax: Rules

The head is a credential atom The body can contain positive credential and ontology atoms, and constraints Example: cred (‘BS’,‘psd:SeniorOfficer’,X,[])  psd:SeniorOfficer(X) Credential Release Rules

Authorization Rules The head is an authorization atom The body can contain positive credential, authorization and ontology atoms, constraints, and negative ontology and constraints Example: perm (‘psd:read’,X,Y)  aboutSurveillance(Y), cred(‘BS’,‘psd:SeniorOfficer’,X,[])

Constraint Definition Rules The head is a user-defined predicate The body can contain positive ontology atoms and constraints Example: aboutSurveillance(X)  bs:aboutMission(X,‘Surveillance’), bs:sensitivityLevel(X,Y), Y<3

Credential Release Policy: set of credential release rules Authorization Policy: set of authorization rules Policies

Local models may not match the global ontology model Global terms might be too coarse-grained to describe a specific domain Policies need precise definitions to guarantee security within a domain A complete and precise vocabulary alignment is costly Not feasible in short- and mid-term cooperation Problems…

GBR ITA Officer OF-3 OF-4 OF-2 OF-1

…and Solution Local terms to provide fine-grained definitions Flexible mapping of local to global terms local to local terms  MORE AUTONOMY  INTEROPERABILITY  AVOID CONFLICTING DEFINITIONS

Ontology Alignment (1/2) GBR ITA Officer Admiral Lieutenant Captain Commodore Ufficiale Generale Maggiore Tenente Colonnello Capitano Goals read if OF-3

Mapping local to global concepts is necessary for mutual-understanding Mapping local to local concepts is also a possibility However, mappings can be imprecise no 100% equivalent concepts entities have different mapping capabilities Who performs the mapping? How? How do we know if we can trust it? Ontology Alignment (2/2)

Extend ontology-based TM with a reputation system every peer can define a mapping between two concepts the trustworthiness (reputation) of a peer depends on the affinity of its opinions with those of the other peers the final mapping is obtained by combining subjective opinions of peers based on their reputation TM + Reputation System

Expressed by similarity credentials e.g., sim(GBR,’Captain’,’SeniorOfficer’, [(degree,0.7),(timeStamp,2009/09/09)]) Reflects inequality between concepts Signed  non-repudiation Similarity Credentials Repository Exchanged through gossip protocols More entities can express the similarity about the same concepts contrasting opinions which one should be considered? Mapping two Concepts

Combine all the opinions the average similarity degree is the “correct” one Not all peers are equally trustworthy Similarity statements discriminated according to peer’s reputation Naïve approach

Reflects the accuracy of the similarity statements of a peer Based on agreement with other peers The agreement between two peers is proportional to the affinity of their similarity statements Steps to compute reputation 1.For each pair of comparable similarity statements, compute their affinity 2.For each pair of peers, compute their agreement 3.Compute the reputation of all peers Reputation

Measures the level of correspondence between non-contradicting statements st is a local similarity threshold that establishes when two statements are contradictory Affinity

Low values of st increase the number of statements considered High values of st lead to a more accurate identification of trustworthy peers Local Similarity Threshold

Agreement values represented as a matrix Updated when new credentials are acquired Agreement

The reputation of a peer is a value in [0,1] It is based on its agreement with the other peers, weighted by their reputation The formula converges after t iterations α is used to bias the computation on the initial reputation and guarantees convergence More details in the paper… Computing Reputation

for st = 0.6 Order of navies: WS, BS, GC, GS Initial reputation: 1, 0, 0, 0 Final reputation values: 0.81, 0.70, 0.89, 0.14 Example

Computes similarity of attributes based on similarity statements Weighted by the reputation of the issuer Excluding opinions of untrustworthy peers rt is a reputation threshold. Similarity credentials of peers with reputation lower than rt are discarded Reputation-based Similarity

Similarity can be exploited in rules Peers may accept credentials about any attributes similar to a given attribute perm(read,X,File1)  cred(GBR,Ally,Y), cred(Y,Z,X), similar(0.5,Z,Captain) ≥ 0.6 A peer can express policies just with known vocabulary  AUTONOMY Peers are able interpret unknown terms by similarity  INTEROPERABILITY TM + Reputation System

Credentials must be derived on request To derive a credential c a peer needs to collect all the credentials on which c depends Where do we find them? Who performs all the computations? We need an algorithm to define a storage schema and a retrieval method Credential Chain Discovery

3 algorithms: Backward search: top-down Forward search: bottom-up Bi-directional search Designed to answer different query types Work if some requirements about credential storage location are satisfied The RT algorithms

3 possible query types 1.Type 1: cred(TU/e,student,Alice)? 2.Type 2: cred(TU/e,student,X)? 3.Type 3: cred(X,Y,Alice)? Where do we start searching? Query Types

Query: Is Bart employee of an accredited university? All credentials stored by the issuer Ask for all accredited universities Ask to each university if Bart is a student All credentials stored by the subject Ask Bart all credentials Ask to all issuers for entailed credentials… Bart has 1000 credentials, 900 confidential… Combine the two… Credential Storage

Consider 1.cred(TU/e,student,X)  cred(PD,student,X) 2.cred(PD,stud,Bart) Query: Is Bart a TU/e student? Now, what happens if both credentials are stored by the PD? We cannot answer the query as we do not know where to start from But…

We need to regulate where credentials can be stored Credential and credential rules must be well-typed Only if credentials are well-typed all the solutions can be retrieved More details in the paper… Well-typed Credentials

Top-down Credentials stored by the issuer! Build a graph in which nodes are labeled by roles Each node gets a “list of participants” Advantages Goal-directed Decentralized Backward Search Algorithm

cred(DSA,student,X)  cred(DG,accredited,Y), cred(Y,student,X) cred(DG,accredited,TU/e) cred(DG,accredited,UT) cred(DG,accredited,UvA) cred(DG,educationalInstitution,TU/e) cred(WUA,qualityInstitution,TU/e) cred(TU/e,student,X)  cred(PD,student,X) cred(PD,student,Alice) cred(PD,student,Bart) cred(PD,student,Charlie) cred(ABN,client,Bart) cred(VISA,ccard,Bart) Example

DSA student Query: cred(DSA,student,Bart)? DG Accredited TU/e UT UvA TU/e student UT student UvA student ……… PD student Alice Bart Charlie Alice Bart Charlie Alice Bart Charlie

Bottom-up Credentials stored by the subject! Build a graph in which nodes are labeled by roles or principals Each node gets a “list of roles it participates to or it is a subset of” Disadvantages: privacy issues! Forward Search Algorithm

Example cred(DSA,student,X)  cred(DG,accredited,Y), cred(Y,student,X) cred(DG,accredited,TU/e) cred(DG,accredited,UT) cred(DG,accredited,UvA) cred(DG,educationalInstitution,TU/e) cred(WUA,qualityInstitution,TU/e) cred(TU/e,student,X)  cred(PD,student,X) cred(PD,student,Alice) cred(PD,student,Bart) cred(PD,student,Charlie) cred(ABN,client,Bart) cred(VISA,ccard,Bart)

Example Query: cred(DSA,student,Bart)? Bart PD student ABN client VISA ccard ABN client PD student PD TU/e student TUE student ABN VISA TU/e DG accredited DG educationalInst WUA qualityInst DG accredited DG educationalInst WUA qualityInst DSA student

Backward search needs credentials stored by issuers Forward search needs credentials stored by subjects We want to be able to store credentials –sometimes by issuers –sometimes by subjects –sometimes by both Combine of forward + backward search Faster, if all credentials can be found… Bi-Directional Search

POLIPO: a security framework for interoperability, portability, and autonomy in the MSS domain –Combines AC, TM, and ontologies –Local ontologies alignment through a reputation system –Works with several existing credential discovery algorithms (e.g., RT) In the next presentation: architecture Summary