Over on Charlie Stross’ blog guest author Karl Schroeder introduces the concept of “wicked problems”. I recommend spending the time to read the whole article and the links in its first paragraph.
It’s not a concept I’d come across before:
But often, in the human sphere, there are what’re called “wicked” problems. In 1973, Horst Rittel and Melvin Webber defined a wicked problem this way:
- There is no definitive formulation of a wicked problem (defining wicked problems is itself a wicked problem).
- Wicked problems have no stopping rule.
- Solutions to wicked problems are not true-or-false, but better or worse.
- There is no immediate and no ultimate test of a solution to a wicked problem.
- Every solution to a wicked problem is a “one-shot operation”; because there is no opportunity to learn by trial and error, every attempt counts significantly.
- Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan.
- Every wicked problem is essentially unique.
- Every wicked problem can be considered to be a symptom of another problem.
- The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem’s resolution.
- The social planner who tackles a wicked problem has no right to be wrong (planners are liable for the consequences of the actions they generate).
The examples given are the obvious ones: fiscal policy, climate change etc, but it’s also a useful insight to bring to security problems. We can divide security issues into two groups (if not cleanly, then in a way that gains insight):
- Non-wicked problems: does this patch crash my server? Does this exploit work? What’s the patch level of my server estate?
- Wicked problems: how should we trade off privacy online for physical security?
Between these two, these a set of semi-wicked problems where much of the day-to-day difficulties in security policy come from e.g.
- if we lock down all our client machines really hard, is that worth the trade off in innovation?
Problems in this class might not fit all the requirements above but will fit many of them E.g. 3, 9 and 10 seem very relevant here: often the person writing the security policy has no motivation other than to be as restrictive as possible, while the person doing the work wants to do the least possible.
A good counter when confronted with the more technological end of things.
