So Who Owns Trust?

If the decision of whether or not to place your information in the “cloud” comes down to a simple matter of trust, trust in whether the cloud provider can deliver the availability they market, trust in the protection of your information in a multi-tenancy environment, trust in their staff (including all the staff they outsource to) to not damage or impact on the service. And this trust is all we have because we aren’t able to view their premises, their procedures, their audit statements and we aren’t able to assess their systems, their applications or environment. Who is it that stands up and says “Yes, we trust them. Lets do it“?

At first I used to think this was the business, I mean they’re the ones fronting the cash to move their important information into the cloud. They’re they ones who will see all the benefits of not having to rely on IT. Then I realised that they wouldn’t know whether or not to trust the cloud provider, surely more often than not they would ask someone within IT “Hey, can we trust these guys?“.

So can IT really dictate back to the business that “Yes, we trust them. Lets do it“? Can the CIO put his hand on his chest and declare yes? How does IT even come up with that answer? Do they even know? Is it the architecture teams perhaps that look at the service being offered and reviewing what the business is trying to do and going “Yes, we trust them. Lets do it“? At this point I would imagine those architects turning to the risk/security/governance people within their organisation and once again asking the question “Hey, can we trust these guys?“.

Hopefully this is where the line of questioning comes around full circle. Hopefully this is where the downwards questions stop. Hopefully this is where the security people ask the business people “What’s the value of your information? What would happen if it was unavailable, or disclosed, or modified?” While this is an important question, and one that will have to be answered at some point, it doesn’t really help anyone with whether or not they can trust the provider. It’s often here that things get difficult and the incessant pushing and probing of the provider starts to weigh heavy on the heads of the business. The costs are piling up and time has run out.

The next thing you know you’re in the cloud. But who gave the definitive answer to the question of trust? Probably no-one.

3 thoughts on “So Who Owns Trust?”

  1. AS/NZS put out a document circa 2002 as an addendum (right term?) to 4360 from an outsourcing perspective. At the time, and I haven’t re-visited it, I thought it was pretty good. From memory, it would fit well with all this “Cloud” service. Might be worth a read. I reckon only about 10 people read it. :) Could be a valuable resource now. If interested, let me know and I will grab more details for anyone interested if you cannot locate it yourself.


  2. I think I was one of those ten :) I still even have a copy.

    I just blogged about this the other day to some extent. It comes back to how trust is gained, assured, and to some extent – quantified and measured. Which is interesting because CIOs are already starting to grapple this very issue.

    Who do we trust? How much do we trust them? How can we verify that our trust is founded (or otherwise ascertain the extent of which we can trust them)?

    I’m not against cloud based services but it all does raise very serious questions that must be addressed. Right now, the trust isn’t there and there’s no real uniform approach or standards to providing it. Everyone is applying their own adhoc interpretations – of standards, audits and frameworks. And as you know, adhoc is the bane of security…

  3. Hey Jarrod,

    Cheers for the comment. I’ve been following /dev/null for a while and really enjoying it too.

    Whilst we don’t have the quantity of the US based bloggers, I’m happy with the quality we bring to the table.

    You know what you’re presenting on @ AusCERT this year. I’m wondering if I’ll be able to get over. Also, you on twitter?

Leave a Reply

Your email address will not be published. Required fields are marked *