Tag Archives: security philosophy

An Exercise in Lateral Thinking

A year ago, in a slightly heated debate on secure software engineering, I used a photography analogy to make my point. The precise background of this debate does not matter; it should suffice to say that one party – “us” – opined that security engineering is difficult and complicated, while the the other party – “them” – held the view that average software developers need just a couple of tools and examples to improve the results of their work, security-wise. Both sides had a point, considering their respective backgrounds, but they spoke of requirements while we spoke of the difficulty of fulfilling these requirements. To explain my position on the issue, I tranferred the problem from security engineering into a totally unrelated field, photography. They seemed to expect they could turn average people into reasonably good photographers by handing them a highly automated point-and-shoot camera and a few examples of great photos. We ended the quarrel agreeing to disagree.

The train of thought thus started led to my latest paper Point-and-Shoot Security Design: Can We Build Better Tools for Developers? which I finished a few weeks ago, after having presented and discussed an earlier version at this year’s New Security Paradigms Workshop. In this paper I explore the photography analogy in general, interpreting (some aspects of) photography as visual engineering, and the point-and-shoot analogy of tool support in particular. The final version of the paper does not fully reflect its genesis as I moved the photography part, from which everything originates, into a separate section towards the end.

Describing in abstract terms different classes of properties that we can analyze and discuss in a photo, I develop the notion of property degrees, which I then transfer into security. Properties characterize objects, but they do so in different manners:

  • Microscopic properties characterize an object by its parts, and in terms that we can express and evaluate for each part in isolation. Taking a microscopic point of view, we describe a photo by its pixels and the security of a system by its security mechanisms and its defects.
  • Macroscopic properties characterize an object by the way it interacts with its surroundings. Macroscopic properties of a photo represent the reactions the photo evokes in the people viewing it, and the macroscopic security properties of a system characterize the reaction of a threat environment to the presence of this system.
  • In between, mesoscopic properties characterize the object in its entirety (as opposed to the microscopic view) but not its interaction with an environment (as opposed to macroscopic properties). We speak about microscopic properties if we discuss, for instance, the composition of a photo or the security of a system against a certain class of adversaries, considering motivations and capabilities.

Speaking of property degrees as of three distinct classes is a simplification; one should really think of the property degree as a continuum and of the three classes as tendencies. In a rigorous definition, which my paper doesn’t attempt, we would likely end up calling all properties mesoscopic except for those at the ends of the interval.

The ultimate objective of photography and security engineering alike, I argue, is to shape the macroscopic properties of that which one creates. Any object has properties at all three degrees; to design something means to control these properties consciously and deliberately. To do that, one needs to control lower-degree properties to support what one is trying to achieve. However, there are no simple and universal rules how macroscopic properties depend on mesoscopic and microscopic properties. To figure out these dependencies is a challenge that we leave to the artist. That’s necessary in art, but less desirable in security engineering.

Looking at some of the security engineering tools and techniques that we use today, I argue that security engineers enjoy just as much artistic freedom as photographers, although they shouldn’t. Most of our apporaches to security design have a microscopic focus. The few mesoscopic and macroscopic tools we know, such as attack trees and misuse cases, are mere notations and provide little guidance to the security engineer using them.  To do better, we have to develop ways of supporting macroscopic analysis and mesoscopic design decisions. Right now we are stuck in the microscopic world of security features and security bugs, unable to predict how well a security mechanism will protect us or how likely a bug will be exploited in the wild.

Using photography as a model for security engineering is an intermediate impossible, a term coined by Edward de Bono for one aspect of lateral thinking. An intermediate impossible does not make much sense by itself, but serves as a stepping stone to something that might. In the case of point-and-shoot security design, it’s a double impossible, a) ignoring the boundary between art and engineering and, b) ignoring for a moment the adversarial relationships that we are so focused on and, simultaneously, so ignorant of in security. Out of it we get the universal notion of property degrees, and an application of this notion to the specific problems of security.

In a way, this work is a follow-up on my 2009 NSPW paper What Is the Shape of Your Security Policy? Security as a Classification Problem (mentioned here, here, and here). I based my considerations there on the notion of security policies, and later found it difficult to apply my ideas to examples without something bothering me. Security policies tend to become arbitrary when we understand neither what we are trying to achieve nor what it takes to achieve it. If you meticulously enforce a security policy, you still don’t have the slightest idea how secure you are in practice, facing an adversary that cares about your assumptions only to violate them. Property degrees don’t solve this problem, but maybe they make it a bit more explicit.

Advertisements

Causal Insulation

I just came across an essay by Wolter Pieters that complements my 2009 NSPW paper (mentioned here and here in this blog before) in style and content. In The (social) construction of information security (author’s version as PDF), Pieters discusses security in terms of causal insulation. This notion has its roots in Niklas Luhmann’s sociological theory of risk. Causal insulation means that to make something secure, one needs to isolate it from undesired causes, in the case of security from those that attackers would intentionally produce.On the other hand, some causes need to be allowed as they are  necessary for the desired functioning of a system.

I used a similar idea as the basis of my classifier model. A system in an environment creates a range of causalities—cause-effect relationships—to be considered. A security policy defines which of the causes are allowed and which ones are not, splitting the overall space into two classes. This is the security problem. Enforcing this policy is the objective of the security design of a system, its security mechanisms and other security design properties.

A security mechanism, modeled as a classifier, enforces some private policy in a mechanism-dependent space, and maps the security problem to this private space through some kind of feature extraction. In real-world scenarios, any mechanism is typically less complex than the actual security problem. The mapping implies loss of information and may be inaccurate and partial; as a result, the solution of the security problem by a mechanism or a suite of mechanisms becomes inaccurate even if the mechanism works perfectly well within its own reference model. My hope is that the theory of classifiers lends us some conceptual tools to analyze the degree and the causes of such inaccuracies.

What my model does not capture very well is the fact that any part of a system does not only classify causalities but also defines new causalities, I’m still struggling with this. I also struggle with practical applicability, as the causality model for any serious example quickly explodes in size.