Risk, Cost, and Information Resource Ownership

CISOs need to speak Managementish in order to be understood. If we cannot translate Risk into Dollars we’re out.

For every practical reason, when we argue we must assume that Risk = present value of future Damage. This implies a thought model: Max(Information Security) = Min(%+$), where % = Risk and $ = Mitigation (=present value of risk mitigating investments incl. operating costs). That's what our work is all about. What if a little extra Security gives huge payback? Well, that happens, because Security is built through Investment. As I just wrote.

Who decides about the road to Max(Information Security)? Not the CISO. The Information Resource Owner does. So go persuade him/her! But who is it in your organization? Is there such a box in the org-chart? No, not often.

There is a "lowest organizational level" for Information Resource Ownership where Accountability is found, and that is just as far from Management that you still have the Ability to manage both the Risk and the relevant Mitigation connected with specific information resources. On and above that level, too little Risk Awareness hurts your wallet severely. Funny enough, this does not count for the CISO – his/her wallet is too small to really get hurt…

The CISO needs open channels to the real Information Resource Owners. This is required, but not sufficient, to enable achievement of your Information Security Objectives.

Sidospår: Kulturrevolutionen - kommunikationsexplosionen

Detta inlägg har inspiererats av @kommunchef, som i sin blogg http://kommunchef.com/2011/12/kulturrevolutionen/ 2011-12-05 skrev "...den kulturrevolution som ett öppet, personligt och medskapande förhållningssätt som integrerar sociala medier kan innebära...".

Någon sa "Jag är inte beroende av Facebook, jag är beroende av mina vänner". Det känns som en revolution att jag kan umgås så okomplicerat med mina vänner över hela världen nu för tiden. Att jag dessutom fått nya vänner som jag aldrig annars skulle ha mött är en bonus med oanade konsekvenser på gott och ont - mest på gott, tror jag.

I den pseudovärld som en organisation är sker liknande förändringar när sociala medier blir en del av kanalvalet. E-post och intranät öppnade dammluckan på glänt. Diverse chattar, Yammer och liknande verktyg spränger dammarna och börjar skapa samma slags flöden internt i organisationer som bloggar, Twitter, Facebook m fl gjort i det offentliga rummet, dvs. öppnar kommunikationsmöjligheter som brev, telefon och möten aldrig kan åstadkomma, på gott och ont - mest på gott, tror jag.

Men sociala media ersätter inte brev, telefon och möten, åtminstone inte på kort sikt. De är nya valbara kanaler för samma gamla kommunikation. Men de kan sänka tröskeln, så att mer kommunikation blir resultatet. Och så verkar det ha blivit, på gott och ont - mest på gott, tror jag.

Självklart kan alla kanaler missbrukas. Glapptrutarna får mer utrymme, och diverse konstigheter dyker upp. Det som borde hållits inom en snäv grupp blir offentligt. Men samtidigt ökar det totala kommunikationsutrymmet så att fler röster får plats vid sidan av de professionella, och fler får del av information som gör att man förstår sammanhang som aldrig förr. Å andra sidan ska de som tar emot flödet ha kapacitet att hantera det och dessutom få andra viktiga uppgifter gjorda. Det finns en inbyggd konflikt mellan ökade kommunikationsmöjligheter och mottagarnas hanteringsförmåga. Förhoppningsvis leder det till att vi lär oss prioritera mellan kommunikation med olika viktigt innehåll, både som avsändare och mottagare, inte mellan kanaler. Då blir resultatet av den pågående kommunikationsutvecklingen mest på gott, tror jag.

Alexander Bard, som vid sidan av sin mera kända musikverksamhet är en analytisk sociolog av rang, sa för något år sedan att informationssamhället tar över, inte genom evolution eller revolution utan genom explosion. Det inser vi inte nu, vi som befinner oss mitt i explosionen, men framtidens historiker kommer att förundras. De kommer att se när vi bytte både fokus och perspektiv från industrialismens syn på utveckling (stenålder – bronsålder – järnålder – industri, eller samla – odla – tillverka – distribuera) till kommunikationssamhällets utvecklingsträd (tal – skrift – tryck – telegraf/telefon –  radio/tv  – digitalteknik, eller närkommunikation (t ex tal) –  meddelandesystem (t ex brev) – massmedia (t ex tidning) – nätverk). Och det vet jag är på gott.

Operational Risk Assessment and Mitigation

Risk is defined in ISO 31000 as “the effect of uncertainty on objectives”. Risk is usually measured as “likelihood times consequences”. Operational Risk is all Risk besides Business Risk. Operational Risk Assessments aim at identifying all risks and proposing proper Mitigation. Easy, right? Well, no. It is challenging and time consuming. But it is worth it, because it is profitable.

I have this rather operational view on Operational Risk Assessment and Mitigation:

• Threats "use" one or more Vulnerabilities to create one or more Damages on your people, assets, information, processes, or reputation. Every such Threat-Vulnerability pair is more or less likely, i.e. is connected to a Likelihood value. Multiply with the value of the related Damages, and you have a Risk value. To be useful for analysis and mitigation, Risk should be quantified in measurable & verifiable units (when possible), i.e. do not use those low-to-high relative scales.

• You need to do these calculations from three different points of view. I recommend you to calculate the Risk connected which each individual identified Threat, Vulnerability and type of Damage. Just don’t sum up all the Risks so calculated – they are not independent. In fact, you look at the same Total Risk from three perspectives, so adding Risk over any individual of the three dimensions – Threats, Vulnerabilities or Damage types – should give the same resulting Total Risk.

• Now you will have a brilliant base for the real security work – first select the Threat, Vulnerability or Damage type giving the highest Risk value and work on with Risk Mitigation proposals down the list, Risk by Risk: 
• How much may Risk be reduced by any Risk mitigating activity, e.g.: 
• Eliminating or reducing Threats? 
• Reducing Vulnerabilities? 
• Planning for Reducing Damage (preparedness)? 
• Which costs and other effects are associated with each Risk mitigating activity (investment & ongoing)? 
• How profitable is each activity, i.e. how much does it reduce the total value of Damage and protection? 
• Does any Risk mitigating activity reduce more than one Risk? How does that affect its profitability?

• Knowing all this, propose to your peers what combination of Risk Mitigating activities you find most profitable (within affordable limits – your purse is restricted), compared to doing nothing (nothing new, that is). 

Of course you will make the most astonishing presentation of your proposals, so you will get your OK. Then go out and do it! And don't forget to continuously develop your security through the PDCA process (see any Management System standard).

Operational Risk Treatment

Recently I’ve blogged about how to reduce Risks from Threats using Vulnerabilities by eliminating Threats, by reducing Vulnerabilities or by reducing Consequences – or by a combination. Acting this way is an example of one of the three major strategies for Operational Risk Treatment – Risk Reduction.

The Risk Management Concept is about optimizing your outcome of Risk. Your Management should contain your organization’s expertise on managing Business Risk, and you may be your organization’s Operational Risk Management guru. If so, you know that Operational Risk Treatment is about minimizing the total costs for Risk outcome and protection and about keeping your Risk within limits defined by your organization’s Risk Appetite.

One good source for knowledge about Operational Risk Management is ISO/IEC 27005. For those of you who prefer free access to information, open sources include ENISA, who presents the following list of your Risk Treatment options:

1. to avoid the Risk by deciding to stop, postpone, cancel, divert or continue with an activity that may be the cause for that Risk; 
2. to modify the likelihood of the Risk trying to reduce or eliminate the likelihood of the negative outcomes; 
3. to try modifying the consequences in a way that will reduce losses; 
4. to share the Risk with other parties facing the same Risk (insurance arrangements and organizational structures such as partnerships and joint ventures can be used to spread responsibility and liability); (of course one should always keep in mind that if a Risk is shared in whole or in part, the organization is acquiring a new Risk, i.e. the Risk that the organization to which the initial Risk has been transferred may not manage this Risk effectively.) 
5. to retain the Risk or its residual Risks 

The (residual) Risk level is a result of your application of the three major Risk Treatment strategies: Risk Reduction (p. 2 & 3), Risk Avoidance (p. 1) and Risk Sharing (p. 4). Or, of course, if Risk is acceptable from the beginning, by applying the fourth strategy: Retaining Risk (p.5). In either case, you may not stop treating Risk before each and every (residual) Risk is either explicitly accepted by the Risk Owners or fitting into your organization’s Risk Appetite picture. I.e. every application of a Risk treatment Strategy ends in Retaining Risk.

To Be Compliant Or To Be Secure? There Is A Risk...

Both Compliance and Risk are Business issues. Security deals with Operational Risks, which may include the Risk of being non-compliant. But Compliance seldom cares about Risk or Security. It cares about whether you follow the rules or not.

IMHO, Compliance is Compliance and Security is Security, and they seldom meet. Being compliant might give you  some protection you need - and some you don't need as well - but to achieve the security level optimal for you, you must do your entire homework. 

What I try to point out is that Security needs a Risk based approach to be successful. Of course you need to be compliant, too. But Compliance only gives you license to play a risky game. It does not make the game a safe one. 

"I follow law, agreements and policies" is a poor excuse for not doing the right things. 

Policies are decisions made beforehand, assuming a specific reality, both in-house and in the surroundings. Think budget, as an analogy: Budgets are predictions, built on plans and assumptions about the future economic outcome. If reality turns other ways than predicted, even if you follow your plans your results will not be as budgeted. 

And as reality changes, following policies will give other results than expected, too - unless you are Aware of the changes and Able to change or neglect policies when appropriate, or at least to initiate policy changes (always assume you are Accountable!). 

Did you see the AAA Triplet in the paragraph above? Here is another triplet: There are three levels of defense in an organization: Management, Control, and Audit. Never mix them! And never assume that Control or Audit can establish Security in your organization! What is poorly done in Management may be found by Control and criticized by Audit, but only Management has the means and the obligation to introduce the corrective changes needed.

Compliance (i.e. abiding law, agreements, incl. agreed standards, and policies) will introduce some good "security" and some good "governance", but it cannot give you all you need in either respect; there will be wants and deficits to deal with, which you will not find if "Compliance" is your only tool. And there is an obvious Risk (sic) with a Compliance based approach that you get - and pay for - much more than you need; lookout for the "best practice trap"! This your stakeholders will dislike...

In short: Do not abdicate by letting Compliance (or Audit) set your agenda! You cannot afford it.

Security Aware Employees - Yes, It Is Possible!

I often use the thought model AAA = Awareness, Accountability and Ability.

There is a "lowest organizational level" where formal Accountability may be found, and that is just so far from Management where you still are allowed to use your Abilities to manage both the costs for risk and the costs for mitigation connected with the information. On and above that level, too little Risk (and Cost) Awareness hurts severely.

But to get that full engagement from all your co-workers, you need a little more. Your Co-workers will never act "correctly", from your point of view, if they are not Risk Aware and thus understand how threats use vulnerabilities to create damage. And they will not read - or understand - all your policies, rules and smart blog posts on your intranet if they lack time or interest.

So how do you create that interest? By giving, and asking for, confidence, down to the lowest levels. By communicating (give and take) on risks, threats, vulnerabilities, and mitigation, and by positive(!) and negative feedback on behavior. By Good Management, to be short. MBWA, if you wish.

Communication is both ways (up, and down) and mutual understanding smoothes the road. But to start with, and often down the road, too, it is one way information. Since "we", the senders, really want to share our knowledge with "them" and "they", the receivers, have very little time for us (being just one of a zillion eager senders with each his own professional language), "we" are accountable for the results of the communication and thus need to make our message observed and easily digested. 

You cannot blame the receiver for not observing or understanding a message in a difficult language...

Profitable Security

Security is when no possible threat will result in consequences you cannot accept. If you are not already secure, you need to mitigate your risks. But how do you efficiently mitigate risks? Is risk mitigation profitable? 

First of all, how and when does a threat become a risk? 

In my last blog post I wrote that a threat needs a vulnerability to be able to cause damage. No vulnerability or no threat means that no damage will occur. If both exist, future damage is probable. How probable damage is depends on the nature of both the threat and the vulnerability. So the probability part of “risk = probability * consequence” depends primarily on how threats interact with vulnerabilities. 

But there are interdependencies between threats, vulnerabilities and consequences that need to be understood. Let’s take a look at an attacker whose rule of decision is “maximize profit” (a fairly simple scenario). 

The probability of damage from an attacker is a function of the attacker’s decisions. Those in turn depend on the presumed consequences from attacks (i.e. the earnings) and on the “cost of use” of your vulnerabilities. 

The attacker wants your money to add to his earnings. He has a couple of methods that use your vulnerabilities, he knows how much each method will cost him (in time, money, punishment etc.) and he estimates how much money there will be left for himself in each case. He also contemplates over his ability to use his methods on you – does he need to enhance his knowledge or abilities (or your vulnerabilities) beforehand (i.e. more costs)? 

He adds up all the costs and the expected earnings for each of the possible attacks and decides which, if any, to use. If you are more costly (= secure) than he likes, he is no threat for the moment – he will attack someone else instead. 

It is all summed up in this simple picture (adapted to the Attacker Scenario): 

As you see, there is a battlefield to keep within for both of you. There is no point in this scenario to work with other parts of the Risk Pyramide than Ability, Vulnerability and Consequence. The attacker works steadily on his Ability to use our vulnerabilities (and to make them worse, if he can). Our choice of Risk Mitigation is to reduce our Vulnerabilities and the Consequences of attacks – in fact we are trying to persuade the attacker that it is uninteresting for him to attack us. If he agrees, it is Game Over. For a while.

OK, with all this cleared out, how do you know when enhanced risk mitigation is profitable? You must think Return On Investment (ROI). What is the Present Value, or the Annuity, of your suggestion? What do you put into your calculations?

The only really difficult part should be the probabilities. A small tip is to transform probabilities into frequencies, i.e. make your consequences distributed over time, just as your activities. You initially need the frequency of the damage you want to avoid and the distributed value – or costs – of that damage (the Zero Alternative, i.e. doing nothing). Then you need to know the frequencies and the values – or costs – of the damages that will occur after your selected choices of activities are implemented and the frequencies and the values – or costs – of the corresponding suggested sets of activities. Then calculate e.g. the present value of each of your cases defined, including the case of doing nothing. Your prime choice is the cheapest.

Done. No go and inform your peers and ask for their support for your suggestions.

How To Treat a Threat?

A threat is a possible cause of possible damage to your business. It may come from

a)      people, inside or outside of your organization, ether deliberately or through neglection/ignorance/carelessness;

b)      technology, working as expected or failing; or

c)       environment, like lightning, landslide, flood, emissions, contamination etc.

You might add "acts of God", but that cause adds no value to this discussion. Sorry. Let's stay with common logical causes for the moment. As long as they exist, we need no more.

However, no threats make damage if there are no vulnerabilities for the threats to use. So: No vulnerabilities means no damage, whatever the threats. In other words, and so far:

1.       eliminating a cause/threat eliminates damage through vulnerabilities used by that cause/threat.

2.       eliminating/reducing a vulnerability eliminates/reduces damage from all causes/threats using that vulnerability.

But however complete you manage to eliminate/reduce threats and vulnerabilities, I bet there still are both threats and vulnerabilities left, and still damage may occur. To deal with this, you need to be prepared to act wisely in unwanted or unexpected situations. We need to add a weapon to our arsenal:

3.       preparing for business continuity and disaster recovery – just in case…

One basis for your choice of actions, whether they aim at elimination/reduction of threats or vulnerabilities or preparedness for unwanted situations, is a threat and vulnerability analysis. But this is not enough. In order to understand the profitability of your possible actions, you also need to analyze the probability of the damage you want to avoid, and the total value – or cost – of that damage and your choice of mitigation.

Now we have what we need to decide on treatment of threats – a more or less complete Risk Analysis.

The JES Concept explained

JES = Just Enough Security. Why, and What?

The Just Enough Security Concept strives for a situation where the total consequences from damage and protection are as low as possible over time. JES accepts the fact that 100% Security is unattainable.

JES is almost as far from “Best Practice” as you may be. The only obvious strategy – besides JES – that by definition is further away from “Best Practice” is the “No Protection At All” strategy. But that strategy is probably even more expensive for your Organization than “Best Practice”.

Let me explain.

Risk is sometimes defined as the Consequences of an Event multiplied with its Probability. To know your organization's Risks, you must know – or, at least, be strongly convinced about – both Probability and size of the Consequences of all possible damaging Events. But if you don’t know - which are your best choices, in terms of risk mitigation strategy?



Genuine Uncertainty means no knowledge whatsoever of possible damaging Events. Your simplest choice is a "No Protection At All” strategy, where you just face the costs connected with unwanted Events. And you really do not see any reason to do anything else.

Common Uncertainty means some knowledge of possible Events with damaging Consequences but no usable knowledge of Probabilities for the Events. A reasonable strategy is to follow “Best Practice” for protection. You will face costs connected with protection you both need and do not need, and costs for damage you chose not to protect against, either from weaknesses in Best Practice or from lack of resources. And you cannot optimize your costs for protection and damage; you lack sufficient knowledge.

Knowing your Risks is one essential foundation for the ability to optimize total costs for protection and damage – “Just Enough Security”.



In the Cost/Protection diagram, “No Protection At All” will put you to the left. “Best Practice” will put you partly to the right and partly to the left, because some of the needed protection will be omitted for some reason or another.

Knowing your Risks allows “Just Enough Security”, which will move you close to the green arrow.

Where would you like to be?

Basics On Information Classification

Important note #1: Information Classification is about more than just IT. 

Through your Information Classification, you decide on (i.e. classify) the required level of protection for your specific (types of) information resources (not only for information as such) in terms of Confidentiality, Integrity, Availability and sometimes Traceability (CIA-T).

Important note #2: Information Classification has 2 dimensions.

You also need to understand and document (i.e. classify) the level of protection of Confidentiality, Integrity, Availability and sometimes Traceability (CIA-T) offered to your information resources by your information environment, i.e. your infrastructure, your information handling/storing tools, etc (which in turn are information resources, i.e. need to be classified both according to #1 and #2).

Important note #3: Your Information Classifications need to be quantified.

Forget about relative values like High/Medium/Low. What are you supposed to do with that data? Instead, quantify the consequences if Confidentiality, Integrity, Availability or Traceability is not kept on the required levels, e.g if your service is not available for your customers as agreed. What will that cost your customers – and what will that cost you? This is the kind of data to put into your plans for investments in information security!

Usually, today, I only see qualitative/relative classification of information as such in IT environments and in terms of Confidentiality, and no corresponding analysis of the protection offered by the information environment. Not good enough.

Can We Trust Biometry for Authentication?

Simple answer: No. Not alone. 

There are several obvious attack points in the biometrical authentication chain. And, unfortunately, the very face, eye, hand, or fingerprint, is not always as unique as we may think. As an example, fake fingers have fooled fingerprint readers from the beginning, and they still do.

And making those fake fingers is not rocket science. In her M.Sc. thesis, Marie Sandstrom of Linkoping University, Sweden, showed how she could fool every existing fingerprint reader with gelatin fingertip copies made quite simply from fingerprints picked up with common forensic techniques. The thin gelatin fingertip copies were put on her own fingertip, thereby bypassing those temperature and pulse controls.

Update: A similar technique was used to "hack" the fingerprint reader on the new iPhone.

Consequently, a mould rubber mask constructed from a 3D portrait photo might fool a face recognition system. A rubber copy of my hand put on your (smaller) hand might fool a hand reader. And soft eye lenses with printed patterns might fool an iris reader. I do not know whether this is tested, but I would not be surprised if such tests were successful. 

For me as a security professional, this is what I must consider, and it leads me to one conclusion: Never trust one security mechanism alone. If you need to be reeeaaalllly safe, you need more controls. Preferably simple, layered, and independent.

Why do we need Security at all?

Different kinds of threats may use different vulnerabilities to create damage, and if the risk for damage from such reasons is not under control, your organization has a too low security level. There are basically three main roads to reduce the risk for such damage, or, in other words, to establish the level of security you wish for yourself: 

• eliminate threats, 
• reduce vulnerabilities, or 
• react wisely when damage occurs. 

Or, which is usually the case; apply a combination of these three.

Security is about keeping you in business, i.e. not losing your market from operational reasons, and keeping your operational ability to deliver to that market, virtually whatever happens. Security focuses on managing Operational Risks for your business – all other risks, e.g. Business Risks, are for the Business people to manage by themselves.

One quite lively branch of Security is Information Security, i.e. Security applied on Information, regardless of environment, carriers, etc. This is very often mixed up with IT Security, which – at its best – is about eliminating vulnerabilities in IT environments. But, of course, IT Security is an essential tool for Information Security Management. The same goes for Physical Security, trying to reduce physical vulnerabilities and used as a tool both by Information Security Management and by overall Security Management.

All these colours are needed on the Security Palette; none is The Answer to The Question of how to keep us in business whatever happens. But, well played, they offer cards for Management to play in that everlasting Marketing Warfare Game.

Which Messages Reach the Top?

How do we reach Top Management with our Information Security issues? Why don't they act on our message? One of many obstacles is our presentation. We conceal our message in nerdy language.

In those days when I tried to speak the predecessors of "ISO/IEC 27000-ish" with Top Management, they sent me to the auditors - or, in fact, anywhere out of their sight. Of course they did not listen, why should they? I was showing them so clearly that I was what Scott Adams, the author (in chapter 26 of "The Dilbert Principle") calls "one level removed" from the essentials of the business, and that is not a position of great strength.

Today, I translate risk and (information) security management language into the language of those in power. They have a language fit to manage business, and that is what it is all about.

So, for the last 25 years, I've been informing about alternative action patterns (including doing nothing), the profitability of the possible action plans, distribution of accountability, the need and building of awareness and ability, and the way to follow up on results, and things usually - but not always! - go my way.

My conclusion: Specialists should make themselves understood by speaking Top Management language, not by teaching Top Management any odd Specialist language. And specialists, like myself, need help to manage that. 

The Three (or Four) Laws of Consultics (eng)

The three laws of robotics were created by Isaac Asimov, who also completed them with the “Zeroth Law”, so named to continue the pattern of lower-numbered laws superseding in importance the higher-numbered laws. 

Below, compared with the Asimov set of laws,“robot” is replaced by “Consultant”, “humanity” is replaced by “Markets”, “human being” is replaced by “Customer”, and “existence” is replaced by “integrity”. 

I hope it makes sense to you. It does to me.

0.              A Consultant may not harm Markets, or, by inaction, allow Markets to come to harm.

1.              A Consultant may not injure a Customer or, through inaction, allow a Customer to come to harm.

2.              A Consultant must obey orders given to it by Customers, except where such orders would conflict with the First Law.

3.              A Consultant must protect its own integrity as long as such protection does not conflict with the First or Second Law. 

Hur svårt kan det vara, det där med säkerhet?

Träffade en server idag. Han (eller hon) tyckte inte alls att säkerhet var komplicerat. Tvärtom. Och jag håller med. Vad är problemet? Här är serverns berättelse:

- Jag är en server. Jag får information från andra datorer. Jag lämnar information till andra datorer. Däremellan bearbetar jag den information jag har. Det är mitt liv. Hela livet. Jag gör inget annat, jag vill inget hellre.

- Det finns regler för vad jag ska göra när information kommer till mig, hur jag ska bearbeta informationen jag har och vad jag ska göra när någon ber mig lämna ut information. Vissa regler finns i mina program och databaser, andra regler finns i kataloger hos mig själv och på andra datorer.

- Jag vet inte om reglerna är bra eller dåliga, jag vet inte vad den tänkte som skrev reglerna. Men jag gör exakt det jag är tillsagd att göra. Jag är ju en dator.

- Vissa speciella kataloger innehåller regler som bestämmer om jag överhuvud taget ska ta emot, bearbeta eller lämna ut information när någon ber om det. Reglerna kan t ex säga att den som sitter vid datorn som jag pratar med ska vara identifierad på ett visst sätt och ha en viss typ av roll, eller att den aktuella datorn eller kommunikationen ska ha vissa typer av skydd. Ibland säger reglerna att jag ska kontrollera saker, exempelvis kontrollsummor. Men allt detta är bara exempel på regler jag måste följa.

- Varje gång någon annan dator ber mig göra något kollar jag i katalogerna vilka krav som finns. Om alla krav är uppfyllda låter jag mina program arbeta enligt sina regler. Om något är fel eller fattas, jämfört med katalogen eller enligt programmens regler, gör jag ingenting. Enkelt.

- För att man ska kunna se att jag följt reglerna sparar jag information om vad som hänt och vad jag gjort i min logg. Men eftersom jag är en dator gör jag alltid som jag är tillsagd. Så loggen visar aldrig att jag gjort något fel - tack för det. Om något blir fel beror det alltid på fel i reglerna - som jag alltid följer.

- Så - hur svårt kan det vara att vara säker, egentligen - jag ska ju bara få rätt regler att följa?

Vem i hela världen kan man lita på?

Nätet har skapat en värld där relationer inte känner geografiska, kulturella eller tekniska restriktioner. Vem som helst kan i princip upprätta en relation med vem som helst om vad som helst i den digitala världen. Ofta är relationerna ytliga, ungefär som samtal mellan främlingar på en trottoar, men ibland påverkas stora mänskliga, kulturella, etiska eller ekonomiska värden genom relationen. Därför behöver vi i olika grad känna till saker och ting om vår motpart och dennes förhållanden. Vi behöver helt enkelt känna tillräcklig "trust" i sammanhanget.

Parterna i en relation har inte alltid behov av samma "trust". I princip är den nivå man önskar en funktion av den risk man upplever i det speciella sammanhanget, dvs behovet kan variera beroende på relationens tillfälliga innebörd.

Låt oss ta ett typiskt exempel: Jag och min bank.

Från min sida sett ska banken göra det jag säger att banken ska göra (inom lag och avtal) när jag säger till banken att göra det. Men om någon annan säger samma sak till banken ska banken inte göra det. Enkelt. Mitt behov av "trust" handlar således om att jag ska vara rimligt säker på att jag pratar med banken och ingen annan och att ingen annan kan få banken att göra saker med mina pengar.

Banken å sin sida kontaktas av både kunder och icke-kunder och behöver därför ha koll på med vilket syfte de kontaktas. Varje fråga/order får besvaras/utföras endast om den som kontaktar banken är behörig att få frågan/ordern besvarad/utförd. Beroende på ärendet måste banken därför vara "tillräckligt säker" på vem som är motparten, så att banken inte besvarar/utför obehörigas frågor/order.

Sammanfattningsvis handlar "trust" i detta sammanhang således om att:

1. jag (båda) ser till att vara tillräckligt säker på vem jag umgås med
2. jag (bank, leverantör) förvissar mig om att min motpart är behörig
3. jag (kund) litar på att min motpart hanterar vår relation och min information/egendom "korrekt"