Usually a system manager proposes a policy, gets approval from higher management (a written one if lucky enough, or if compliance with standards is needed) and proceeds to implement it.
Then it begins:
The manager must enforce the policy, with one exception. Then another and another. And later an exception of the form: Deny access to this resource, except from these people, with the exception of these circumstances and provided that the stars are in the right angles. Or in order to give a real life (pseudo)example:
You use a DNSBL. A certain host is included and there are valid reasons for this. But you need to unblock this host because someone with authority asks you to. However, the hard reality forces you not only to implement the exception, but also an exception to the exception (unblock this host for certain recipients, who do not want certain senders from this host, etc).
In this process nobody tries to understand the very root cause of the problem: Are we correct in using the particular DNSBL? And if we are, is there a valid reason for the sending host to be (black)listed? And if there is, is it wise to implement a series of exceptions, or is it better to wait for the host’s administrators solve the problem?
A great number of people seem to misunderstand the robustness principle: “Be liberal in what you accept; be conservative in what you send” (they stick to the “accept” part) and I think we need to rephrase it:
If you want me to be liberal in what I accept, be conservative in what you send
A policy ruled by exceptions is not an exceptional policy.
→ Asking the security team for a firewall exception.
Managing organized complexity 