Random Ruminations

by Oddbjørn Steffensen

Information Security - a Wicked Problem?

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?

Cross-pollinating Security

The classic waterfall model from Managing the Development of Large Software Systems by Winston W. Royce, 1970

Forty years ago, Winston W. Royce described what has later been named the waterfall model, pictured to the right. He states the he believed in the concept, but: “the implementation described [..] is risky and invites failure” due to the testing occurring very late in the lifecycle, and the long way from initial requirements to operation.

Twenty years ago, when I was studying software engineering, the waterfall philosophy was still the foundation for how large-scale systems were developed. The results were predictable — a string of failures in development of large-scale software systems in the late eighties and throughout the nineties.

In the software development world, the backlash to the Big Design Up Front (BDUF) of the waterfall model was to do what Royce really proposed: iterative, incremental and evolutionary development. One of the best known models based on these principles is Barry Boehm’s spiral model, published in 1986.

In the same year Hirotaka Takeuchi and Ikujiro Nonaka published the The New New Product Development Game in Harvard Business Review. Instead of rigid sequential development (the “relay race” approach), they propose a (the “rugby” approach) where development emerge from multidisciplinary teams working together from start to finish. A few years later, this philosophy was adapted to the software development world by Ken Schwaber and Jeff Sutherland in the Scrum framework, officially presented at OOPSLA in 1995. This again led to the agile software development movement, culminating with the publication of the Agile Manifesto in 2001.

While the software development world has clearly progressed beyond the top-down approach of years past, enterprise security still seem to cling to this approach — based on perceived stakeholder interests, we create entire “information security management systems” (ISMS) in the style of ISO/IEC 27001 in order to solve the enterprise security conundrum.

The problem is that entities like this are more or less designed to operate as a crudely bolted-on accessory to the enterprise instead of as a organically integrated part of the daily activities. As a result, properly ensuring a reasonable level of security in a modern enterprise is a sisyphusian task, where “security” are running behind in an effort to catch up with the dynamic complexity of a modern enterprise.

In short — we need to learn from developments in other disciplines in order to achieve our goal of both effective and efficient security.

The next posts on this blog will attempt to explore the implicit and explicit connections between security and related disciplines.

Writing to Learn

Almost exactly ten years ago, I shifted my attention from Unix and system management to working exclusively on various topics within the field of information security. While it’s hard to claim that the overall security standing haven’t improved in the past decade, it is fair to say that we still have a long way to go in this area.

I believe that the field of security can benefit from looking at recent developments in surrounding areas, for example:

Writing to Learn Around a decade ago, I read William Zinnser ’s inspiring Writing to Learn. In his book, Zinsser promotes the process of writing in order to better understand a topic by forcing oneself to deeper thinking. Expressed in a nutshell by Toby Fulwiler and Art Young:

Writing to learn is different. We write to ourselves as well as talk with others to objectify our perceptions of reality; the primary function of this “expressive” language is not to communicate, but to order and represent experience to our own understanding. In this sense language provides us with a unique way of knowing and becomes a tool for discovering, for shaping meaning, and for reaching understanding.

While I may be a slow adopter, this blog is my attempt to use this philosophy to “connect the dots”. I will try to keep the postings within the realm of information security in its widest sense, it may occasionally delve into wholly unrelated topics. Only time will tell if I also remember anything from one of Zinsser’s other books: On Writing Well ..