Making an Intelligent, Defensible Trust Valuation

Monday, April 23, 2012

Rafal Los


Is trust a binary decision? Can you trust something to varying levels?

These are important questions for any security professional to have good answers to. Applying this logic to computing - can we ever really trust any computer environment, system, or application?

 If you're making a binary decision the obvious answer is no.  I would argue that this is a silly situation to be in.  While it's good to be in a healthy state of paranoia, saying you either trust or don't is a difficult position to be in.

I would postulate that the more reasonable alternative is to develop levels of trust - so that you can go on the assumption that nothing is ever fully deserving of blind, unverified trust - and still set the bar somewhere.  

The logic here being that at some level you're going to say to yourself "this is reasonably trustworthy" and develop strategies for levels of trust above and below that line you've just designated.  This is touching areas of risk management thinking, as a necessity, because trust is really about how much risk you're willing to take on, after all.

If I trust you I'm taking on an incredible amount of risk because I won't protect myself against you.  However if I trust you some arbitrary amount then I can say that due to that level of trust I choose to adapt my risk defense in some meaningful way.

This actually has a large amount to do with the state of the Information Security industry, because this misunderstanding of trust is leading to all kinds of seemingly crazy decisions on both the business and security end of the candle.  

The state of the security industry is still so poor in large part because there is a misunderstanding of what trust is, and what its all about... and more importantly how it should be viewed.

Let's look at the application to clouds, and cloud computing since that's the topic of the day. As an example, a simple question.  "Can you build a trusted cloud environment?"

If you're following the binary school of thinking, and trust is absolute one way or the other, and you're forced to admit that everything is fallible, then the answer is no. Given that answer, it's difficult to understand what to do next.  Does your enterprise simply forego the incredible benefits of cloud technologies because of your binary states of trust?  I would hope not.  

What you should be saying is that after doing some due-diligence the level of trust you have in your vendor, or internal cloud, or whatever - is some pre-defined level.  You can use modifiers like "high", "moderate", and "low" to describe your level of trust based on empirical evidence, history (if available) and yes sometimes good 'ol gut feeling.

Think of your trust decision as being based on a triangle, where each side is critical in its own way and has function - without which the triangle doesn't stand.

Historical evidence is sometimes difficult to obtain with new providers, vendors, or products and services.  Often times non-disclosure agreements (NDAs) will prevent current customers from sharing experiences openly with the community, and there really aren't a whole lot of good forums for exchanging reviews of technology products/services out there.  Luckily customers do talk, and write blogs, articles and share opinions on social mediums so it's possible to get that historical evidence through a little research.

Empirical evidence is a little bit easier to obtain.  You can ask for artifacts from audits, compliance documents, and things like architecture and design schematics to assuage your fears.  You can ask your vendor to share information with you that can be attested by a reasonably trusted 3rd party such as an audit firm or reputable organization.  Now, before you go off and start complaining about the reputation management that lots of organizations do - I will acknowledge that but you have to be rational.  

How much empirical evidence do you as the customer need to have a reasonable degree of trust in the security of your cloud provider?  This is a very valid question and one you should have an answer to before you start looking.  Everything is risk-based... and the level of trust you're willing to accept should be proportional to the amount of risk you're taking inherently in the application, system, or data.

There's always room for the good 'ol gut feeling in things like this.  While I would not weigh gut reaction too heavily in this triangle of trust measure, sometimes your gut will tell you things empirical evidence and history cannot.  Have you ever talked to a vendor who produced spotless reports, had a fantastic and squeaky clean history only to have this feeling that something's wrong?  Maybe they're too good?  

Often times it's that reaction that is driven by some subconscious understanding of a personal interaction, experience-driven knowledge or simply "something else" that helps us make a decision.  This is why it's an important, although not super-critical part of our triangle.

Is trust binary?  No, I don't think so... I think trust, like risk, is shades of no.  I think everything is untrusted to varying levels from "absolutely untrusted" to "slightly untrusted" and as crazy as it may sound - this, I think, is the only sane way to approach trust and to build a good foundation for a well functioning information security industry.

Cross-posted from Following the White Rabbit

Possibly Related Articles:
Enterprise Security
Information Security
Cloud Security Risk Management Risk Assessments Managed Services Due Diligence Trust Information Security Infosec Analysis
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.