Trust ^ Verify
I have been thinking of a new way to express an old idea about the need to trust and verify various components of a system. Inspired by the W^X (write XOR execute, a way to prevent the execution of injected code) relation, I think I came up with a good trust pattern. The pattern is:
Trust XOR Verify. Trust or Verify, but not both, and not neither.
In security systems, it is often desirable to verify the properties of code that are relevant to its trustworthiness. In essence, users of a system traditionally face a choice: either trust the code that you execute (thus tacitly admitting that it can violate your security) or verify the security properties of the code so that you have some assurance that the code behaves as expected.
If you verify the properties that you trust, doing so introduces needless overhead. If you don’t trust a component, but you don’t verify it, then you are exposed to needless risk. So, you should either trust a component but not verify it or not trust a component and so verify it. This logic is captured exactly by the XOR relation:
Trust Verify Trust XOR Verify T T F (needless performance degradation) T F T (acceptable risk, no performance degradation) F T T (non-acceptable risk, justified degradation) F F F (needless risk)
