Information security is too often treated as a binary problem; we’re either ‘secure’ or ‘insecure’. This approach fails to appreciate the complexity of the issue at hand, and tend to lead us into treating the symptoms rather than the root causes.
A better approach may be to view information security as a ‘wicked problem’.
The term was first used by Horst Rittel and Melvin Webber of University of California at Berkeley in “Dilemmas in a General Theory of Planning” (1973). Their context was the challenges of social policies in the late 1960s and early 1970s, and they concluded with the following:
The search for scientific bases for confronting problems of social policy is bound to fail, because of the nature of these problems. They are “wicked” problems, whereas science has developed to deal with “tame” problems. Policy problems cannot be definitively described.
Moreover, in a pluralistic society there is nothing like the undisputable public good; there is no objective definition of equity; policies that respond to social problems cannot be meaningfully correct or false; and it makes no sense to talk about ‘optimal solutions’ to social problems unless severe qualifications are imposed first. Even worse, there are no “solutions” in the sense of definitive and objective answers.
They defined the following characteristics of a ‘wicked problem’, and I’ve tried to map each of them against the field of information security below:
| # | Characteristics of wicked problems | … as applied to the domain of information security |
|---|---|---|
| 1 | There is no definitive formulation of a wicked problem | The number of potential attacks or mishaps are near infinite, so our best hope is to use our current knowledge, experience, categorization and judgment to focus on what we deem the most important subset of them. |
| 2 | Wicked problems have no stopping rule | When do we stop securing our systems? When is the final security patch applied? |
| 3 | Solutions to Whenicked problems are not true-or-false, but good-or-bad | A given environment shouldn’t be defined as ‘secure’ or ‘not secure’, but we can state that it is (most likely) more or less secure, given our actions or inactions. |
| 4 | There is no immediate and no ultimate test of a solution to a wicked problem | We cannot state that a given security control will work ultimatender all circumstances, and even not the most thorough penetration test will be able to identify all possible avenues of attack or mishap. |
| 5 | Every solution to a wickeded problem is a “one-shot operation” because there is no opportunity to learn by trial-and-error, every attempt counts significantly | It may be possible to learn by trial-and-error when it comes to information security, but the error may prove to be very costly with regard to lost business cleanup resources needed, compliance and last, but certainly not least reputation. |
| 6 | 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 | While a number of MITRE initiatives (e.g. CWE, MAEC and CAPEC) are a valiant effort to create useful taxonomies within their respective areas, they primarily focus on enumerating the offensive aspects, not the defensive measures design to avert them. Promising frameworks like BSIMM and SAMM along with security frameworks frameworks like ISO/IEC 27000-family, PCI DSS and the ISF SoGP have come a long way in the past few years, but nowhere close to a full treatise of the domain. |
| 7 | Every wicked problem is essentially unique | While most environments build upon many of the same components and processes, the way we integrate, adapt and utilize them make the challenges of securing them differ between environments. In addition, the fickle balance between cost, time and quality will differ, both between organizations and over time. |
| 8 | Every wicked problem can be considered to be a symptom of another problem | One limited example is tdhat flaws introduced by the software development lifecycle must eventually be fixed later by the security patching process. |
| 9 | 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 | One example of This is security vulnerabilities; they may be viewed as flaws of the software development process, chosen technology or simply a fact that must be dealt with by the security patching process. |
| 10 | The planner has no right to be wrong | This is probably the characteristic most tied to the origin in social policies; Rittel and Webber state that “the planner who works with open systems is caught up in the ambiguity of their causal webs”. In the same way, security is often at odds with other interests, most notably cost, time-to-market, resource priorization. |
It might seem a bit far fetched to look to a concept originating forty years ago in a wholly different area, but given the recent high-profile security incidents, perhaps it’s overdue to look beyond the information security field for inspiration for alternative approaches? Do you agree that information security may be viewed as a ‘wicked’ problem, and if so &em; how should this influence how we try to secure our environments?

Around a decade ago, I read