Pragmatic Security Engineering

This is a set of pragmatic guidelines that have resulted from observation of real security implementations. On a regular basis I am aghast at the gap between theoretical security and security in practice.

  1. Whenever an incentive is contrary to a security control, the incentive will dominate and the security control will fail (unless a second security control is in place to prevent this occurrence).
  2. Any security solution that cannot be reduced to a clear and coherent pattern is probably not secure.
  3. Security by obscurity as bad security is not an axiom. Any cipher is a form of security by obscurity, and can be very effective security. Question security axioms.
  4. Passwords as authenticators as bad security is not an axiom. Recognize the limitations of passwords as authenticators and account for that in your model.
  5. Certificates as authenticators as good security is not an axiom. Really. Certificate authorities are commercial entities with a strong profit motive that is contrary to certificate identity assurance (see rule 1).
  6. Trust is not transitive. Just because you trust A, and A trusts B does not mean you should trust B. Your relationship with B is likely very different than the relationship between A and B.
  7. Degree of trust can be quantified based on how this translates to assumption of liability. Can you trust to store your credit card with an online account if they are not explicitly assuming liability if they are compromised?