Frequently Asked Questions (FAQs) for SULTAN Framework

SULTAN (Simple Universal Logic-oriented Trust Analysis Notation) is an abstract, logic-oriented framework designed to facilitate the specification, analysis and management of trust relationships. The initial primary focus is on specification and analysis.

What does logic-oriented mean?

Logic-oriented means that logical evaluations are the foundation of the SULTAN framework, i.e. constraints evaluate to true or false. Logic-oriented does not mean logical or logic-based.

Where should SULTAN be used? and by whom?

SULTAN is tailored for use at the management level. It is to be used by a system administrator with a global view of the system resources and needs. SULTAN offers a way to create organization-specific solutions to the problem of trust in an interconnected society.

What is Trust?

Trust is “the quantified belief by a trustor with respect to the competence, honesty, security and dependability of a trustee within a specified context”. Quantification reflects that a trustor can have various degrees of trust (distrust), which could be expressed as a numerical range or as a simple classification such as low, medium or high. A competent entity is capable of performing the functions expected of it or the services it is meant to provide correctly and within reasonable timescales. A secure entity ensures the confidentiality of its valuable assets and prevents unauthorised access to them. Dependability is the measure in which reliance can justifiably be placed on the service delivered by a system. Thus by definition, we see that a dependable entity is also a reliable one. Timeliness is an implicit component of dependability, particularly with respect to real-time systems.

What is Distrust?

Distrust is defined as “the quantified belief by a trustor that a trustee is incompetent, dishonest, not secure or not dependable within a specified context”. Distrust is a useful concept to specify as a means of revoking previously agreed trust or for environments when entities are trusted, by default, and it is necessary to identify some entities which are not trusted.

Why are trust and access control different?

To state that you trust someone to do something in a given situation and to say that you are allow someone to do something in a given situation are two different things. Trust is a statement of belief. Access control is a statement of what is permitted (or not permitted).

What are the axioms of trust?

There are none. However, for a given environment or application domain, there are properties that the trust relationship may exhibit, for example, trust transitivity or transferability (whichever you prefer).

What are you able to specify in SULTAN?

Trust relationships (which include trust assertions and trust rules) and recommendations (assertions and rules as well).

What does a trust statement look like?

A SULTAN trust statement looks like:

TrustPolicyName : trust ( Tr, Te, As, L ) ← Cs;

Tr trusts/distrusts Te to perform As at trust/distrust level L if constraint(s) Cs is true.

where

TrustPolicyName – The unique name for the assertion.

Tr – The trustor. The entity that is trusting.

Te – The trustee. The entity is trusted.

As - The action set. A colon-delimited list of actions (function names) or action prohibitions. The first parameter in an action name specifies where the entity the action is performed on.

L – The level of trust/distrust. L can be an integer or a label. Labels are converted to integers for analysis and management. For integer values of L, –100 <= L < 0 represents distrust assertions and 0 < L <= 100 represents trust assertions.

Cs – The constraint set. A set of delimited constraints that must be satisfied for the trust relationship to be established. The delimiters are the logical and (&) and logical or (|). Cs must evaluate to true or false.

What is so special about the first parameter in an action?

The first parameter in an action indicates whether the action is performed on the trustor, the trustee or their resources.

What is a trust level?

The trust level is a measure of one’s belief in another entity and thus by our definition, it is a measure of one’s belief in the honesty, competence and dependability of this entity (It is not a measure of the actual competence, honesty, security or dependability of a trustee).

What is a recommendation?

A recommendation is a statement that stipulates that you recommend someone to perform a particular task (or set of tasks). Your recommendation is normally used in making trust decisions.

What does a recommendation look like?

A recommendation has the following format:

RecPolicyName : recommend ( Rr, Re, As, L ) ← Cs;

Rr recommends/does not recommend Re at recommendation level L to perform As if constraint(s) Cs is true.

where

RecPolicyName – The unique name of the rule being defined.

Rr – The recommendor. The name of the entity making the recommendation.

Re – The recommendee. The name of the entity that the recommendation is about.

L – The recommendation level. L can either be a label or an integer. All labels are translated to integers for analysis and management. L is >= –100 and < 0 for negative recommendations and L is > 0 and <= 100 for positive recommendations.

As – The recommended action set. A colon delimited set of actions or action prohibitions that Rr recommends Re be trusted/distrusted to perform. Each action name stipulates the entity on which the action is performed.

Cs – The constraint set. A delimited set of constraints that must be satisfied for the recommendation to be valid. Delimiters include the logical and (&) and logical or (|).

One should be aware that:

The recommendation level and trust level are assumed to be independent of each other, unless otherwise specified.

A recommendation may result in a trust specification (i.e. a recommendation may be the basis for one’s trust specification). However, the trust level need not correspond to the recommendation level.

What is a recommendation level?

The level of confidence in the recommendation being issued by recommendor.

Are trust and recommend statements related?

Yes, they are. It is possible to have a trust rule that is based on some recommendation and to have a recommendation based on a trust assertion.

Are risk and experience considered in specification?

Yes, they are. There is an auxiliary specification library that contains functions that can be used in SULTAN specifications. Currently, there are two functions in this library: the risk function and the experience function.

The risk function

The risk function is defined in anticipation of the need to incorporate risk management in the trust management framework. Presently, the risk construct is a placeholder, as the evaluation of risk requires a lot more work. The format of the risk function is:

risk(B, C, A)

The risk entity B undertakes when entity C performs A.

The risk value is the probability (expressed as an integer percentage) for the failure of an activity A performed between trustor B and trustee C. The risk value is an integer between 0 and 100 (inclusive), where 0 represents no risk and 100 is the highest risk possible. The calculation of risk is a function of the SULTAN system and is discussed further in section 8 . For any constraint containing this method to evaluate to a Boolean value, it should always be used in an expression.

Example:

Contract: recommend(College, Sun, access_internal_web(College), -50 )

← risk(College, Sun, access_internal_web(College)) >= 3;

Interpretation: College recommends Sun at recommendation level –50 to perform access_internal_web(College), if the College’s risk in allowing Sun to perform access_internal_web(College) is greater than or equal to 3.

The experience function

The experience function allows one to define constraints based on the experience of entities. We must also emphasise that this construct is a placeholder, as work on the evaluation and use of experience requires a lot more work. The experience function has the following format:

experience(B, C, A)

B’s estimate of the experience it had with C with respect to action set A.

This function must be used in an expression. The experience value is an integer between -100 and 100 (inclusive, 0 excluded). Negative integers (< 0) represent a negative (or bad) experience and positive integers (> 0) a positive (or good) experience.

Examples:

Justice: trust(EGovernment, _AnyCountry, implement_legislature(_AnyCountry), 35 )

← experience(EGovernment, _AnyCountry, implement_legislature(_AnyCountry)) >= 10;

Interpretation: EGovernment trusts any entity, _AnyCountry, to perform implement_legislature(_AnyCountry) at trust level 35, if the EGovernment’s estimate of the experience it has had with _AnyCountry with respect to implement_legislature(_AnyCountry) is greater than or equal to 10.

What is Trust Analysis?

Trust analysis involves examining trust relationships to identify situations of interest. There are a wide variety of situations that may be of concern to the system administrator and our view is that conflicts and redundancies/ambiguities are normally of utmost concern. A conflict is defined as the scenario that arises as a result of two assertions of different polarities (positive and negative), the same action set and referring to the same trustor and trustee. A redundancy or ambiguity is defined as the state in which two assertions, of the same type (trust or recommendation), have the same trustor, trustee and action sets and levels are of the same polarity, but different values.

Our viewpoint on trust analysis is purposefully general, in order to allow different organizations the diversity and flexibility that they require in defining their analysis requirements. In our model, there is a distinction made between source analysis and analysis of actual scenarios.

What is Source Analysis?

Source analysis involves reasoning about one’s specification (essentially program reasoning). For this reasoning, one is concerned with the head of the specifications and the constraints are incidental.

What is Actual Scenario Analysis?

An actual scenario of interest refers to reasoning about the state of the system. This takes into account the satisfaction (or non-satisfaction) of constraints. When doing actual scenario analysis, there is the possibility of cycles being present in the specification. The SULTAN analysis model has rules that handle cycle detection and resolution.

What does trust management mean?

Trust management as “the activity of collecting, codifying, analysing and presenting evidence relating to competence, honesty, security or dependability with the purpose of making assessments and decisions regarding trust relationships for Internet applications”.

What are the components of the SULTAN Trust Management Framework?

SULTAN’s Trust Management consists of five components, namely:

Trust establishment defines the protocols by which parties wishing to form a trust relationship can negotiate and exchange evidence and credentials, which can be provided to an evaluation service.

Trust evaluation service gathers and evaluates the evidence for defining a trust relationship. This could be based on a risk analysis of the context for the relationship, experience from past interactions with the trustee or recommendations from other entities, such as colleagues, who have experience of interacting with the entity within a similar context. In addition, a trusted third party evaluation service such as a consumer organisation, which evaluates goods or services, can be used for recommendations.

Trust specification defines trust relationships in terms of the parties involved, and the context of the interaction. We permit multiple trustors or trustees to be involved in a relationship and a trustor/trustee can be involved in multiple different relationships. The context is defined as a set of actions with a trust level applying to all the actions, and a set of constraints, which must be evaluated for the trust relationship to apply. Most of the current trust specification techniques are aimed at authentication or access control, whereas we are aiming at higher level, more abstract form of trust specification which can then be analysed and evaluated, although it may be used to generate access control and authentication policies.

Trust monitoring is needed to update experience and risk information. This allows for the re-evaluation of the trust specifications that based on this evidence (that is, experience from interactions, new risk evaluation methods or changes in an entity’s credit ratings).

Trust analysis is the process of examining a set of trust relationship specifications to identify unwanted implicit relationships and possible conflicts of relationships. An organisation will be involved in many different trust relationships with a large number of customers and suppliers of goods and services. A service provider may be dependent on other service providers. For example, a videoconference service provider may purchase bandwidth from a number of different telecommunications service providers with which it has its own trust relationship.   There are thus implicit trust relationships between a customer of the videoconference service and the telecommunications service providers, which the customer may wish to be aware of.

What is the link between SULTAN and Ponder?

Ponder is a language for specifying security and management policies, while SULTAN is a language for specifying and analysing trust relationships. The two frameworks can be connected either by using SULTAN in Ponder policies, or by using Ponder as the target for the refinement of SULTAN rules.