Chesterton's Fence is a cautionary tale to make sure that before you change things you actually understand their purpose.
This is particularly important for controls or other risk mitigation. When new leaders come into an organization they sometimes look at the array of controls and want to streamline them. So they start whittling away at things that apparently don't make sense or have no obvious purpose and then a few months later (maybe less maybe more) you start seeing issues, incidents or other consequences. Then the organization starts putting those things, or more often new things, back in place.
That’s Chesterton’s Fence in action. It’s tempting to blame the whittler for not considering the first or second order consequences of such change. However, it is also the fault of the people who put that control in place for not documenting or otherwise enshrining its purpose. This is why well-managed and visible control catalogs are essential along with a process of continuous control monitoring.
Here are some examples I've heard from many organizations of controls that are typical victims of Chesterton’s Fence:
1. Web speed bump. Requiring a click through (at least) when a web proxy blocks an uncategorized web site. People see this and think what a waste of time I have to click through that link what were these people thinking? But the point is to put one more bump (line of defense) in the wire of a malware chain.
2. USB media R/O vs. R/W. Many assume the purpose of portable media control is to stop data leakage but it’s also to stop malware ingress and unauthorized data ingress. The data ingress point is particularly important in business sectors where intellectual property (IP) is crucial - a new employee contaminating the environment with someone else's IP can be just as harmful as taking IP. Although, you do have to make sure there is a controlled and efficient alternate authorised ingress process.
3. Production access controls. Developer or other engineering production access control is not just to reduce the risk of accidents or malevolent activity but also to compel use of effective production management (monitoring tools) and software lifecycle (CI/CD pipeline) behavior which have significant other benefits.
4. Immutable infrastructure. This is not just an important security tenet and operating practice, like production access, it is also to make sure your changes carry less operating risk.
5. Crisis drills. Your regular crisis / incident response drills build organization muscle memory to respond to anything not just what is encompassed in the drill or your disaster / crisis plans. Doing fewer drills (or fewer small scale "micro-drills") make you less resilient even if you believe you've maintained solid capability vs. the explicit plans.
The list could go on.
So if you are a leader wanting change then beware of Chesterton’s Fence, but if you are control designer be aware of this tendency and enshrine control rationale.
Bottom line: it is important to streamline and rationalize, of course. If you are truly convinced you could offer a way to improve a process and add value to the organization by streamlining or removing things — then first watch. Watch the process over the course of a few weeks (perhaps longer). Try to understand every aspect of it. Only then rationalize.
Comments