Kreavolution – Dualismus von Entwurf und Evolution

[Eine Tangente zu dieser Diskussion – Fragt nicht. Scrollt. – und eine Folge der Vorstellung, dass Design die gezielte Beeinflussung von Eigenschaften sei.]

Intelligenter Entwurf oder Evolution? Geht es um das Leben auf der Erde, ist dies eine Frage nach der Weltanschaung, die viele mit Aussagen der Wissenschaft, einige mit einem Glaubensbekenntnis und manche mit Zweifeln beantworten. Für Artefakte wie ein Auto, einen Computer oder ein Stück Kreide hingegen scheint sie Sache klar: der Mensch hat sie geschaffen, diese Gegenstände sind Ergebnisse bewusster Entwicklungsprozesse. Wie könnte man daran zweifeln?

Doch so einfach ist die Sache nicht. Wer etwa je eine Softwareentwicklung aus der Nähe betrachtet hat, wird den Begriff der Software-Evolution für selbstverständlich halten. Angesichts agiler Entwicklungsmethoden – man lernt und verfeinert die Anforderungen unterwegs und sie können sich unterdessen auch ändern – bleibt diese Evolution nicht auf die Wartungsphase nach einer initialen Entwicklung beschränkt. Ist Software ein Entwurfs- oder ein Evolutionsprodukt?

Kreavolution – Dualismus von Entwurf und Evolution weiterlesen

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.

Leichte Kopfverletzungen

Am besten schützt ein Helm vor Kopfverletzungen, wenn wir Kopfverletzungen als das definieren, wovor ein Helm schützt. Mehrere verlorene Zähne sind nach Ansicht der Helmpropagandisten von Amts wegen keine Kopfverletzung:

»Der Rennradfahrer erlitt bei dem Zusammenstoß laut Polizei Prellungen, leichte Kopfverletzungen und verlor mehrere Zähne. Zum Glück trug er einen Fahrradhelm …«

(Echo Online: Rennradfahrer bei Unfall schwer verletzt)

 

Mandatory Life Jacket Advertisement

From an Australian campaign against mandatory bicycle helmet laws:

(YouTube, via)

They picked a perfect analogy. Here in Germany, the number of people drowning and the number of people dying in bicycle accidents, repsectively, has the same order of magnitude: a few hundred a year. Both cycling and being around water are everyday activities for most of us, and the overall risk remains pretty low. Yet in one case we frequently discuss the need for protective gear as if it were particularly dangerous, while in the other, we just shrug it off—if the matter comes to our attention at all.

Keeping a Secret

One of my credit cards is going to expire soon. Apparently somebody at the credit card company has read Ross Anderson’s Liability and Computer Security: Nine Principles and tries to apply it to they advantage. I just received a letter informing me that my next card would come with a chip, and that in the future I would use a PIN instead of my signature to authorize payments. The company offers me to tell them my favorite PIN in advance so they can use that one, otherwise they would pick one for me. That’s all fine.

However, after setting me up to tell them my PIN – which shouldn’t be a problem, I will later give the PIN away to strangers with every payment anyway – their letter tries to instruct me to keep my PIN secret. My PIN would be for my eyes only, and the company would never ask me for it. Wait, what did this very letter just do?

I think I’m going to send them a nice letter. With my favorite PIN, handwritten. Followed by a few unpleasant questions.

Italian Internet Mafia

Just returned from Italy, where I attended NSPW and spent a few days on the beaches of Rimini. It seems the Italian Internet Mafia is after me: I just received a load of malware in an e-mail message colorably coming from Banca Popolare dell’Emilia Romagna – Emilia-Romagna was my destination region – and asking me in italian to open an attachment. I really wonder where they harvested my e-mail address. Any idea?

Tracking und Targeting

In ihrem Paper Targeted, Not Tracked: Client-side Solutions for Privacy-Friendly Behavioral Advertising (HotPETS’11) machen Mikhail Bilenko, Matthew Richardson und Janice Y. Tsai auf eine verbreitete Begriffsunsauberkeit in öffentlichen Datenschutzdebatten aufmerksam. Sie diskutieren den Unterschied zwischen dem Targeting als Zweck und dem Tracking als Mittel, den ich vor einiger Zeit hier in der Serie Datenkrake Google behandelt habe.

Tracking ist das, wovor alle Angst haben: jemand sammelt quer durchs Internet individualisierte Daten über das Nutzerverhalten. Daraus entsteht eine große, unheimliche Datenhalde aus detaillierten Informationen über jeden von uns, mit der man alles Mögliche anstellen könnte. Isoliert betrachtet ergibt dieses Tracking jedoch als Geschäftsmodell wenig Sinn:

  1. Sammle detaillierte Verhaltensdaten über alle
  2. ???
  3. Profit!

Viel Sinn ergibt hingegen das Targeting von Werbung, um das Kosten-Nutzen-Verhältnis der Werbetreibenden zu optimieren. Targeting ist, was die Werbewirtschaft in erster Linie möchte. Tracking stellt ein mögliches Mittel zu diesem Zweck dar und ist übrigens nur so effektiv wie die Modelle, mit denen man aus den vorhandenen Daten Entscheidungen ableitet.

Tracking kann ein Mittel zu allen möglichen Zwecken sein. Targeting ist nicht zwingend auf bedrohliches Tracking angewiesen.

Theorie und Praxis

Theorie:

»In this work we propose a new security paradigm, that aims at using the network’s flexibility to move data and applications away from potential attackers.« (C.W. Probst; R.R. Hansen: Fluid Information Systems, NSPW’09)

Praxis:

»Willkommen auf der „Silk Road“, dem Portal für Abhängige, dem Amazon für Dealer. Silk Road, zu Deutsch: Seidenstraße, das klingt geschmeidig und weich. Dahinter verbirgt sich ein Onlineshop, der stündlich auf einen anderen Server wechselt, um erreichbar, aber nicht greifbar zu sein.« (Tagesspiegel, Klicken, bezahlen, nach Hause liefern lassen)

Lernung:

Gut und Böse gibt es in der Sicherheit nicht. Es gibt nur Interessen und Bedrohungen sowie Maßnahmen, die Interessen vor Bedrohungen schützen.

Scheintransparenz

Wer sich die Datennutzungserklärung von PayPal durchliest, findet darin eine lange Tabelle. Sie informiert ihn darüber, mit welchen Unternehmen PayPal zu welchen Zwecken welche Daten teilt. So erfährt er beispielsweise, dass Nuance Communications »Aufnahmen von ausgewählten Kundengesprächen, in denen Kontoinformationen im Gespräch genannt werden können« für die »Einstellung und Optimierung von Spracherkennungssystemen für den telefonischen Kundenservice« bekommt oder RSA Security »alle Kontoinformationen« zur »Identitätsprüfung«.

Diese Tabelle macht gut die Hälfte der ganzen Erklärung aus. Dass sie so lang ist, lässt sich ohne Datenkrakengeschrei damit erklären, dass sich PayPal wie jedes moderne Unternehmen einer Reihe von Dienstleistern bedient. Um den Kern seines Geschäfts kümmert man sich selbst, mit allem anderen beauftragt man Spezialisten, die es besser und günstiger können – gewöhnliche Arbeitsteilung, wie sie jeder betreibt, der einen Steuerberater, eine Reinigungskraft oder einen Handwerker beschäftigt.

Der formal korrekte Transparenzmechanismus einer solche Auflistung schafft jedoch nur wenig Verständnis dafür, was dort eigentlich geschieht und welche Auswirkungen es auf den Nutzer hat. Um mehr zu erfahren, müsste man die Firmen abklappern und sich jeweils das Geschäftsmodell anschauen. Das ist nicht praktikabel, und so vermittelt die lange Tabelle wenig nutzbare Information. Der Nutzer ist förmlich informiert, weiß aber doch nicht mehr.

Das Web funktioniert heute genauso arbeitsteilig. Hinter kaum einer Website steckt noch ein in sich geschlossener Dienst, ein einsamer Webserver mit Inhalten und Programmen drauf. Wer eine Website nutzt, interagiert mit einer umfangreichen Dienstaggregation, manchmal sichtbar, oft auch verdeckt. Ein Symptom ist die umfangreiche Keksmischung, die man vom Besuch mit nach Hause nimmt.

Der Datenschutz hat bislang keinen konstruktiven Umgang mit diesem Phänomen gefunden. Heftige Diskussionen entzünden sich zuweilen an einzelnen seiner Ausprägungen, etwa am Like-Button von Facebook oder an Google Analytics. Der organisierte Datenschutz behandelt diese Ausprägungen als Einzelfälle statt als Repräsentanten einer Grundsatzfrage, und diskutiert etwa die Behandlung von Google Analytics als Auftragsdatenverarbeitung oder die Anforderungen an eine wirksame Einwilligung vor dem Einblenden eines Like-Buttons.

Sinnvoller wäre, das grundsätzliche Problem zu diskutieren: Was müsste geschehen, damit Nutzer in einem komplizierten (und variablen) Gefüge miteinander vernetzter Dienste ein praktisches Verständnis der Datennutzung erwerben können? In welchen Situationen entstehen tatsächlich Risiken? Welche praktikablen Kontrollmechanismen stehen diesen Risiken gegenüber? Welches Verständnis ist überhaupt nützlich, weil es die Auswahl zwischen Handlungsmöglichkeiten unterstützt? Für die formale Datennutzungserklärung spielen solche Fragen keine Rolle. Sie dient nicht der Interaktion mit dem Nutzer, sondern der Beruhigung der Aufsicht.