0167-4048/01$20.00 © 2001 Elsevier Science Ltd 479

Computers & Security, 20 (2001) 479-484

Introduction

IT security is all about identifying and managing riskin the IT environment.This being the case, many riskmanagement techniques have been developed to helpIT security managers and other professionals who areinvolved with assessing and dealing with IT relatedrisk.These techniques range from the comprehensive,but relatively slow formal approaches (such as MAR-ION and MELISA) to simple table driven techniques,which are capable of yielding a ‘bare bones’ risk anal-ysis within hours.

This article is concerned with modelling trust rela-tionships. Trust relationships have always beenimportant in the IT security domain (consider forexample the importance of the trusted host andtrusted account mechanisms in determining the levelof security associated with distributed Unix sys-tems). However, this has not led to the widespreadadoption of techniques for analysing such relation-ships within commercial environments. With therecent explosion of interest in public key infrastruc-ture (PKI), the importance of correctly modellingand managing trust relationships is being pushedinto the limelight.

A simple, practical, graphical approach to modellingtrust is presented.This model is not sophisticated butshould allow security practitioners to rapidly developa first-cut analysis of existing trust relationships andto analyse the effects of implementing new relation-

ships. Such a model can be used to help decisionmaking in many trust-related areas (such as outsourc-ing), and will provide a deeper insight into existingrisk analysis data.

Risk and TrustRisk and trust are intimately related. For every trustrelationship, there exists a risk associated with a breachof the trust extended. Similarly, in managing a givenrisk, we extend trust to whatever mechanism wedeploy to handle it. This relationship is often quitecomplex, and any modelling exercise could quicklybecome too involved to be of any use within a com-mercial environment.

For example, in deploying a commercial Firewall toimplement a perimeter defence policy, there are sev-eral elements of trust involved:

• We trust the designers of the software to producecode, which behaves according to specifications;

• We trust the network security expert to configurethis software correctly;

• We trust the administrator to react to securityalerts or known problems by modifying the configuration of the device as necessary.

Although the model discussed in this paper is capableof modelling such complex relationships, it is to beexpected that the tool will be of more use to modelsimple relationships. In the above case, we may choose

A Simple Graphical Tool For Modelling TrustSteve PurserSenior Manager IT Security, Clearstream Services, 5 Rue Hoehenhof, Senningerberg, L-2963 LuxembourgFounder Member of ‘Club de Sécurité des Systèmes Informatiques au Luxembourg (CLUSSIL)’

A Simple Graphical Tool For Modelling Trust/Steve Purser

480

to model the trust we have on the Firewall infrastruc-ture (which includes all technical components, relatedprocedures and associated staff) to implement ouraccess control policy.

Elements of the ModelWe can describe simple trust relationships using thefollowing notions.

We model trust between entities. An entity cantrust or be trusted by another entity. As entities can be complex (for example, Company X), weallow for the possibility of ‘drilling down’ into anentity to provide a more accurate model for the trust

relationship under consideration. An entity is mod-elled by a circle containing its name.

A trust is always unidirectional and connects two entities. A trust is modelled by an arrow from the trusting entity to the trusted entity. A trust always has a context, an associated confi-dence level, an associated risk, and a transitivityvalue.

The context defines the scope of the trust. Forexample, I trust my doctor in all medical matters,(context is medical).

The associated confidence level is the degree of confidence I have that the trusted entity will not breach the trust. We model this as ‘high’,‘medium’ or ‘low’. In the case of my doctor, this is‘high’.

The associated risk is the worst case risk, which willmaterialize if the trust is breached.We model this as‘high’,‘medium’or ‘low’. In the case of my doctor, thisis ‘high’ (i.e. if my doctor makes a bad decision, I coulddie).

The transitivity value indicates whether this trustcan be passed on to a third party or not. In thismodel, trust can only be transitive or intransitive ina specific context. In the case of the example (per-haps surprisingly in retrospect,) I trust the surgeonmy doctor recommends to operate on me, the trustis therefore transitive.

When modelling trust according to this model, thefollowing rules apply:

• A trust is only considered to be fully defined if allthe associated values have been defined;

• Mutual trust is not allowed. Such a trust is mod-elled by two unidirectional trusts;

• A trust always has an associated context (uncondi-tional trust is disallowed);

• A trust is only transitive or intransitive within aspecific context.

Illustrative Examples

The following diagram models the trust I have in my doctor in the area of wine (it so happens that my doctor is a connoisseur). In this case, the associ-ated confidence level drops to ‘medium’ (this is nothis specialized field) and the associated risk is ‘low’as the worst thing that could happen is that I investin a batch of bad wine. Here the trust is definitelynot transitive.

Computers & Security, Vol. 20, No. 6

A more appropriate example is provided by the following trust diagram, which illustrates the trust

I have in a new member of my team. Here the context is security administration on a low risk system (this is someone I do not know that well at present, he/she may well make the occasionalsmall, but expensive, error). The level of confi-dence I have in the trust is ‘medium’ as I have performed interviews, sought references and satisfied myself that this is an honest and con-scientious individual. The associated risk is ‘low’because I have limited the scope of admini-stration to a low-risk system. This is obviously not a transitive trust.

Finally, here is a diagram modelling the trust I have in a new colleague working in a different depart-ment. Here I will be working with this new colleaguewithin the context of Project X (development of anew application). In reality, I do not know this personat all, so why should I trust them? This may be con-sidered more correctly as a transitive trust, perhapsmodelled as follows:

The trust I have in my new colleague, although it is adirect trust (I do not use the personnel department as

a mediator when dealing with this colleague), isinferred. In reality, I trust the personnel department tocarry out the necessary due diligence to enable me totrust all new colleagues.

Modelling IT Related Problems

OutsourcingIt is very tempting to give definitive answers to ques-tions related to trust. As an example, we can considerthe subject of outsourcing security:“Should IT securi-ty be outsourced?”.Tempting as it is to give a definitiveanswer to this question, the reality is that this is depen-dent on the way we perceive and choose to extendtrust.There is no definitive answer to this question.

A trust model may help analyse this problem.Company X has already established the followingtrust relationships:

481

A Simple Graphical Tool For Modelling Trust/Steve Purser

482

Although the first trust relationship would appear to be self-evident, the following comments are ofinterest:

• In examining this trust, Company X discoveredthat it had not actually asked for references formany of its existing staff during the recruitmentprocess;

• Company X has no special procedures for vettingsecurity administrators;

• Company X allows newly hired security adminis-trators to administer critical systems as from dayone of their contract.

For these reasons the associated confidence level wasset as ‘medium’ instead of ‘high’.

In addition, Company X trusts an external companyto protect the buildings when no staff are present.Thelevel of confidence in this company is ‘high’(Company X has been working with this securityfirm for a number of years and has carried out auditsof their procedures) and the associated risk is ‘high’.

Given the existence of these trust relationships andthe fact that physical security is an essential precursorfor the security of most of our systems, it would belogical to allow the outsourcing of IT security as longas we can have an equivalent level of trust (‘high’) ina company specialising in IT Security.That is, we seekto establish the following trust relationship:

The Unix Trusted Host MechanismThe Unix trusted host mechanism provides a way ofextending trust from one Unix system to another for

the purposes of authentication (context is authentica-tion). It is important to understand this mechanism asit has been at the root of many security incidents.Wewill consider a simple implementation of the trustedhost concept.

A remote host can be defined to the local system as atrusted host by entering it’s name into a file (the file/etc/hosts.equiv) of the local Unix machine.When auser on the remote machine tries to access the localmachine remotely (using one of the Berkeley ‘r’ com-mands : rlogin, rsh, rcp...,) the local host will:

• Check that the name of the remote host is in the/etc/hosts.equiv file;

• Check that the local/etc/passwd file contains anentry with the same username.

If these two conditions are fulfilled, no password isrequired. In conclusion, if a host is defined as trustedby an entry in the local/etc/hosts.equiv file, anyaccount name which is defined on the remote hostand local host will be able to login remotely withouta password.

From this description, we note that trust is beingextended to remote users based on two pieces ofinformation: the name of the remote system and thename of the user (which must be the same on bothsystems). As Unix systems prefer to handle numericquantities such as IP addresses and user ids, this leavesa lot of room for conducting attacks against the sys-tem (for an old, but interesting discussion, see [1]). Forthe purposes of this example, we assign an associatedconfidence level of ‘medium’ to all trusts of this typeas the systems concerned are within the networkperimeter of the enterprise.

A well known technique for penetrating Unix sys-tems is to obtain a normal user account and to use thisas a base for gaining privileges, typically by exploitingdetailed configuration problems. For this reason, theassociated risk is assessed as being ‘high’.

This trust relationship is not genuinely transitive,because A trusts B and B trusts C does not imply thatA trusts C directly. However, this state of affairs does

Computers & Security, Vol. 20, No. 6

imply that A trusts C via B (see following diagram).Achain of trust has been established.

Notice that if host B were to become unavailable, itwould not be possible for a user on host A to log ontohost C via the trusted host mechanism.This is a con-sequence of the fact that the trust mechanism is nottransitive. In the event that an attack were discoveredagainst one of the host machines in a chain of trust,the corresponding trust diagram would be extremelyuseful in estimating the likely impact. Similarly, thetrust diagram would help the IT security managerdecide where it would be most appropriate to breakthe existing chain.

PKI and TrustPublic Key Infrastructures (PKI) are built to enableusers of a public key based cryptography system tohave confidence in the binding of a public key to anentity (usually an individual). Modelling PKI usingtrust diagrams can help focus on those elements ofimportance (context, associated confidence level, asso-ciated risk and transitivity).

In considering the context of the trust, it is impor-tant to realise that this is very specific for a PKI sys-tem and is limited to the binding of the key to anentity. The way this entity is described varies fromPKI to PKI, but will typically take the form of anX.500 distinguished name, an e-mail address or somesimilar device. Note that the context is strictly lim-ited to this binding and does not include any guar-antees regarding the character, behaviour or anyother properties, which we can associate with this

entity. It is interesting to note that this does not nec-essarily imply that the user possesses the correspond-ing private key, although it is to be expected thatmost certificate authorities will incorporate proce-dures to validate proof of possession (POP) of theprivate key. The Exploder ActiveX control incident[2] demonstrated clearly that the possession of acode-signing certificate does not necessarily implythat the signed code is safe.

The level of confidence, which we can associate withthe binding is determined by a number of factors,most of which should be discernable from the certifi-cate practice statement (CPS) of the certificateauthority and the certificate policies governing theuse of different types of certificate. In practice, trust isdetermined as much by soft factors, such as reputationand market uptake as by hard ones (registration pro-cedures, revocation model and so on).

The associated risk is interesting in that it may be pos-sible to transfer some of the risk to a third party (suchas an insurance agency) by associating a liability withthe certificate. Here, it is important to realise that cer-tain types of risk are not transferable in this way. Inparticular, risks which have an impact on the compa-ny’s image are not transferable.

Finally, the trust is transitive if we have more than onecertificate authority involved in validating certificates.In the commercial world, we often trust organisationssuch as VeriSign and GlobalSign to allow interoper-ability of certificates. If the trust is transitive, the levelof confidence we can have in a particular certificate isdependent on the practices and policies of all the cer-tificate authorities involved. For example, a poor revo-cation model could allow a certificate chain to beincorrectly validated.

This brief analysis demonstrates that modelling trust within PKI-enabled systems is a complex activi-ty.The graphical approach suggested in this documentis designed to simplify this process by emphasisingthose aspects of the trust deemed to be of greatestimportance.

483

A Simple Graphical Tool For Modelling Trust/Steve Purser

484

ConclusionsTrust models are valuable for similar reasons that riskanalysis models are valuable. Constructing such amodel forces us to concentrate on one aspect of acomplex set of interactions (in this case the trustaspect) thus essentially rendering a complex situationunderstandable. In the case of this particular model,we must define the context and provide semi-quanti-tative values for the level of confidence and the asso-ciated risk of any trust relationship in additional tolooking at the transitivity. Finally, the model ensures

that we do not fall into the trap of making global‘black and white’ statements about a complex issue, byrequiring these values to be assessed for each andevery trust relationship.

References[1] “Improving the Security of Your Site by Breaking Into it”, DanFarmer and Wietse Venema (http://www.rootshell.com/docs/improve_by_breakin.txt)

[2] Web Security & Commerce, pp. 76-77, Simson Garfinkel andGene Spafford, O’Reilly & Associates inc, 1977.