In my opinion, one of the most harmful notions in infosec is "trust", how many times have you heard someone say - well we trust this server, we trust this group, we trust this zone, we trust this partner, and on and on. I mean people use "trust" over and over again, but there are several problems.
First, Bob Blakley reminds us that "trust is for suckers." Why would anyone charged with security architecture willingly build naivete into their system?
As Kim Cameron mentions, your lawyer does not use the word "trust", instead when you write a contract it is around roles and responsibilities, liability and actions.
Kim pointed out that infosec is in the midst of a "continuing deterioration of privacy and multi-party security due to short-sighted and unsustainable practices within our industry has begun to have the inevitable result", that infosec itself is a primary contributing factor will come as a surprise to many in the industry, but ill-defined notions like "trust" are a leading reason why.
One reason why "trust" is so problematic for infosec is that how do you write a design requirement, operational plan or test criteria about "trusting something?
People use the word trust to mean anything from access control to integrity to certification to liability and many, many other security architecture concerns.
When you hear anyone say the word "trust", you must drill down and get a precise definition of what they mean by "trust", identify the specific verification, controls, monitoring, processes and other mechanisms that seek to deliver "trust."
And then simply exorcise the word trust from your vocabulary, replacing it with precise definitions.
We have big name gurus like Bruce Schneier saying that we must "trust" our Cloud providers. This is misleading at best and utter madness at worst. What did Bruce mean when he said we must "trust" our Cloud providers? Who knows? And how in the world would we even figure this out? We must trust what exactly? Taking the Cloud example, the way forward for infosec has nothing to do with a sloppy definition like trust, its precision and integration, as to the Cloud its Don't Trust. And Verify. That paper describes four security architecture elements for the Cloud - Gateway, Monitoring, PEP/PDP, and STS. They each do very specific things and the sum of the part give you concrete improvements including among other things:
- Gateways manage attack surface
- Monitoring builds visibility into the system
- PEP/PDP gives fine grained, dynamic authorization capabilities
- STS exchanges security tokens
There is not a whiff of squishy trust in the above list, but there are four pieces of security architecture with a unique value proposition that you can plan, budget, draft requirements, design, test and deploy.
What does "trust"ing a system/app/service mean? I presume it means taking some assumed security controls away, but which ones? Does it mean you don't monitor, you don't have access control on, you don't encrypt or verify data? What does it mean and how do you design/build/test it?
Obviously, Bruce Schneier is a smart and articulate guy, I am sure he has some specific things in mind when he says we should trust the Cloud, but like when others use that word, I have no idea what they are.
As Mark Twain said, precise language is the difference between lightning and a lightning bug.
I'd recommend doing a find or grep on any/all of your security architecture docs to find the word "trust" and replace it with a precise definition of what you mean and don't mean.