Yesterday, during a webcast for the Cloud Security Alliance, one review comment suggested that all I was describing was the ‘trust but verify’ methodology. I was a bit surprised, but thought the comment deserved some thought—a lot of future audience members may have the same impression. The webcast was recorded and available on demand here.
Trust decisions, including any decisions to trust digital assets, are calculations that require rules and information. One of the critical challenges in engineering and working within complex information systems is that the information required to calculate trust must itself come from sources outside the control of the actor or team calculating trust.
‘Trust but Verify’ begins with a presumption of trust. The trust decision model has a different starting point—there is no trust until an affirmative calculation can be made. That difference is precisely the focal point of my work.
In digital space, we can no longer presume trust in any asset. Instead, we have to author the rules that structure our calculations of trust, find qualifying information, and then execute the calculation. Once trust is affirmatively calculated, then management of the trusted asset does require the continual input of ongoing sensory and performance data to confirm the initial calculation of trust remains effective.
In researching the origins of the concept of ‘Trust but Verify’, I discovered the phrase originates in Russian and was popularized by President Reagan in describing the terms of agreement on the nuclear arms controls he negotiated. It was interesting to learn that Secretary of State John Kerry told a news conference in Geneva on September 14, 2013 that the United States and Russia had agreed on a framework to dispose of Syria‘s chemical weapons. He said “President Reagan’s old adage about ‘trust but verify’ … is in need of an update. And we have committed here to a standard that says ‘verify and verify’.”
It is the same concept—there is no trust until the rules for trust have initially been authored and the information acquired to calculate trust is justified. And that is where the hard work begins—identifying and authoring the rules, including the rules to trust the sources of the information required to calculate trust.
In any cloud-based service, the customer requires data to verify the customer’s requirements are being satisfied by the performance of the vendor. But can the vendor itself be trusted as a source? Or are one or more sources required to be identified and vetted?
The Trust Decision Model presented in my book explains the sequencing of these decisions and their dependencies. The book is now available!
I welcome your comments and reactions.