Category Archives: Forschung


Ein schneller Tipp zwischendurch:

Drüben in der Quantenwelt erklärt Joachim Schulz kurz und bündig seine Kriterien, wann er sich Angst machen lässt und wann nicht. Der Kern: Bei unklarer Studienlage ist der untersuchte Effekt wahrscheinlich klein.

Dasselbe Prinzip kann man übrigens nicht nur auf vermutete Schadwirkungen anwenden, sondern auch auf jeden behaupteten, aber zweifelhaften Nutzen. Die Helmdiskussion zum Beispiel wäre dann schnell vorbei, und fast alle Behauptungen über IT-Sicherheit würde uns mangels Empirie sowieso keiner glauben.

Nutzenbehauptungen können wir noch an einem zweiten, ähnlichen Kriterium messen. Verkauft sich etwas nicht (z.B. besonders sichere Messenger) oder nur an strenggläubige Randgruppen (z.B. Homöopathie), dann ist der objektive Nutzen wahrscheinlich nicht so groß wie behauptet. Erst ein starker Glaube verschiebt die subjektiven Präferenzen so weit, dass der Kauf ökonomisch rational wird.

OMG, public information found world-readable on mobile phones

In their Black Hat stage performance, employees of a security company showed how apps on certain mobile phones can access fingerprint data if the phone has a fingerprint sensor. The usual discussions ensued about rotating your fingerprints, biometrics being a bad idea, and biometric features being usernames rather than passwords. But was there a problem in the first place? Let’s start from scratch, slightly simplified:

  1. Authentication is about claims and the conditions under which one would believe certain claims.
  2. We need authentication when an adversary might profit from lying to us.
  3. Example: We’d need to authenticate banknotes (= pieces of printed paper issued by or on behalf of a particular entity, usually a national or central bank) because adversaries might profit from making us believe  a printed piece of paper is a banknote when it really isn’t.
  4. Authentication per se has nothing to do with confidentiality and secrets, as the banknotes example demonstrates. All features that we might use to authenticate a banknote are public.
  5. What really matters is effort to counterfeit. The harder a feature or set of features is to reproduce for an adversary, the stronger it authenticates whatever it belongs to.
  6. Secrets, such as passwords, are only surrogates for genuine authenticating features. They remain bound to an entity only for as long as any adversary remains uncertain about their choice from a vast space of possible values.
  7. Fingerprints are neither usernames nor passwords. They are (sets of) biometric features. Your fingerprints are as public as the features of a banknote.
  8. We authenticate others by sets of biometric features every day, recognizing colleagues, friends, neigbours, and spouses by their voices, faces, ways of moving, and so on.
  9. We use even weaker (= easier to counterfeit) features to authenticate, for example, police officers. If someone is wearing a police uniform and driving a car with blinkenlights on its roof, we’ll treat this person as a police officer.
  10. As a side condition for successful attack, the adversary must not only be able to counterfeit authenticating features, the adversary must also go through an actual authentication process.
  11. Stolen (or guessed) passwords are so easy to exploit on the Internet because the Internet does little to constrain their abuse.
  12. Attacks against geographically dispersed fingerprint sensors do not scale in the same way as Internet attacks.

Conclusion: Not every combination of patterns-we-saw-in-security-problems makes a security problem. We are leaving fingerprints on everything we touch, they never were and never will be confidential.

Confidentiality is overrated

Is security about keeping secrets? Not really, although it seems so at first glance. Perhaps this mismatch between perception and reality explains why threats are mounting in the news without much impact on our actual lives.

Confidentiality comes first in infosec’s C/I/A (confidentiality, integrity, availability) trinity. Secrets leaking in a data breach are the prototype of a severe security problem. Laypeople even use encryption and security synonymously. Now that the half-life of secrets is declining, are we becoming less and less secure?

Most real security problems are not about keeping secrets, they are about integrity of control. Think, for example, of the money in your wallet. What matters to you is control over this money, which should abide by certain rules. It’s your money, so you should remain in control of it until you voluntarily give up your control in a transaction. The possibility of someone else taking control of your money without your consent, through force or trickery, is something to worry about and, if such others exist, a real security problem. Keeping the contents of your wallet out of sight is in contrast only a minor concern. Someone peeking into your wallet without taking anything is not much of a threat. Your primary security objective is to remain in control of what is yours most of the times and to limit your losses across the exceptional cases when you are not.

This security objective remains just the same as you move on from a wallet to online banking. What matters most is who controls the balance in which way. In a nutshell, only you (or others with your consent), knowingly and voluntarily, should be able to withdraw money or transfer it from your account; you should not be able to increase your balance arbitrarily without handing in actual money; others should be able to transfer any amount to your account; exceptions apply if you don’t pay your debts.

Confidentiality is only an auxiliary objective. We need confidentiality due to vulnerabilities. Many security mechanisms rely on secrets, such as passwords or keys, to maintain integrity. This is one source of confidentiality requirements. Another is economics: Attackers will spend higher amounts on valuable targets, provided they can identify them. If there is a large number of possible targets but only a few are really valuable, one might try to make the valuable target look like all the others so that attackers have to spread at least part of their effort across many candidate targets. However, strong defenses are still needed in case attackers identify the valuable target in whichever way, random or systematic.

The better we maintain integrity of control, the more secure we are. Systems remain predictable and do what we want despite the presence of adversaries. Confidentiality is only a surrogate where we do not trust our defenses.

Mein Gott, es ist voller Spam!

Spam kommt überall dort vor, wo jemand mit wenig Aufwand viele Empfänger erreichen kann, aus deren Reaktionen er einen Gewinn zieht. E-Mail ist das klassische Beispiel: Millionen von Nachrichten zu versenden, kostet fast nichts. Kann man Klicks der Empfänger direkt zu Geld machen, lohnt sich Spam, denn bereits bei geringer Antwortrate kommt mehr Geld zurück als der Versand gekostet hat.

E-Mail ist nur ein Träger für Spam. Ein anderer ist mir in Google Analytics begegnet: Referral-Spam. Dabei geben sich die Spammer als Website aus, die auf eine andere Website verlinkt, entweder mit Website-Besuchen durch Bots oder auch mit Fake-Daten, die sie bei der Google-Analytics-API abliefern. Im Referrer steht dabei jeweils eine URL, zu der man Besucher locken will; diese URL taucht dann in Logfiles oder eben in Google Analytics auf. Auf diese Weise kann man sich einerseits Links erschleichen, wenn Websites ihre Logfiles öffentlich machen. Andererseits weckt man die Neugier einzelner Analytics-Nutzer oder Logfile-Auswerter und lockt so Besucher auf die Spammer-Site.

So häufig wie in der E-Mail ist Referral-Spam noch nicht. Aktuell läuft aber gerade eine nertötende Kampagne, die ein unnützes Social-Buttons-Gedöns bewirbt. Wenn’s nervt, kann man sich in Google Analytics einen Filter einrichten. Ausführliche Erklärungen gibt es hier.

CfP: Workshop on Agile Secure Software Development @ ARES’15

We are organizing a workshop on agile secure software development in conjunction with the ARES’15 conference. Please find the full call for papers on the workshop website, The conference takes place in Toulouse this year.

Important dates:

Submission Deadline: April 1522, 2015
Author Notification: May 11, 2015
Proceedings version: June 8, 2015
Conference: August 24-28, 2015

The Social Component of Risk Assessment

(This post appeared first on the ESSE project blog.)

Earlier this year Andreas presented at the New Security Paradigms Workshop our paper An Asset to Security Modeling? Analyzing Stakeholder Collaborations Instead of Threats to Assets (DOI: 10.1145/2683467.2683474). During our work with the GESIS Secure Data Center team it emerged that the common way we use to do risk assessment may be flawed. In this paper we discuss what is missing and how to analyze collaboration networks to understand consequences of security incidents.

Risk assessment, as described for example in ISO 31000, is a systematic process that prepares decisions. The goal of this process is to find appropriate risk responses and treatments. A risks can be accepted or even increased (if doing so entails an opportunity); it can be avoided, shared or transferred; or the risk can be mitigated by reducing its likelihood or impact. As a prerequisite for informed decisions one goes through the risk assessment process, during which one identifies, analyzes, and evaluates pertinent risks. The figure below, a more elaborate version of which can be found in ISO 31000, illustrates this process chain.

A 4-step process: (1) risk identification; (2) risk analysis; (3) risk evaluation; (4) risk treatment. Risk assessment comprises steps 1-3.Stakeholders participate in this process as a source of information, knowing their respective business or business function and being able to assess likelihoods and impacts. This standard approach to risk assessment has the premise that risk treatments are variable and the objective is to find optimal values for them.

In our paper we propose a complementary approach. Our premise: Stakeholders collaborate in complicated networks for mutual benefit. Risk and incident responses are to a large degree determined by their collaboration relationships. These pre-determined responses are not to be defined as a result of risk assessment, they rather constitute a factor to be considered in risk analysis and evaluation. The figure below is a simplified version of Figure 8 in our paper:

SDC Stakeholder NetworkThe Secure Data Center serves its users, which are part of a larger research community; the SDC also needs its users as serving them is its pupose. Beyond the individual user, the research community at large benefits from SDC services and influences their acceptance. Primary investigators provide data; they benefit from wider recognition of their work through secondary analyses and fulfil obligations by archiving their data. Survey participants are the source of all data. Everyone wants to preserve their willingness to participate in studies.

The need for an extension of risk assessment methodologies became apparent when we reviewed and discussed with the participants of our study the threat models they had produced. They expressed various concerns about the stakeholders involved and their possible reactions to security incidents. Although traditional approaches to risk assessment include the analysis of consequences, they fail to provide tools for this analysis. In the security domain in particular it is often assumed that consequences can be evlauated by identifying assets and assigning some monetsary value to each of them. According to our experience it’s more complicated.

Read the paper on our website or in the ACM digital library:

Andreas Poller; Sven Türpe; Katharina Kinder-Kurlanda: An Asset to Security Modeling? Analyzing Stakeholder Collaborations Instead of Threats to Assets. New Security Paradigms Workshop (NSPW’14), Victoria, BC, September 15-18, 2014. DOI: 10.1145/2683467.2683474 [BibTeX]

Hintertüren für den Staat

Smartphones und Tablets sind neben vielen anderen Funktionen auch persönliche mobile Datenträger. Für deren Inhalt – Kontakte, Termine, Fotos, Anrufprotokolle, Kurznachrichten und so weiter – interessieren sich naturgemäß auch Strafverfolger. Die Mobilplattformen iOS und Android können gespeicherte Daten verschlüsseln, wie es sich für ein verlust- und diebstahlgefährdetes Gerät gehört. Neuerdings verspricht Apple, selbst keine Daten aus verschlüsselten Geräten auslesen zu können. Google kündigt für die nächste Android-Version an, die Verschlüsselung standardmäßig zu aktivieren und gibt ebenfalls an, über keinen Zugriffsmöglichkeit zu verfügen. Daraufhin melden sich der FBI-Direktor, der US-Justizminister und andere und kochen die alte Diskussion um Hintertüren für die Strafverfolgung neu auf. Ein Aufschrei ist ihnen sicher.

An anderer Stelle sind Hintertüren für staatliche Organisationen üblich und niemanden juckt es: Viele Gebäude verfügen über ein Feuerwehrschlüsseldepot, das der Feuerwehr den Zugang ermöglicht. Technisch handelt es sich um dasselbe Problem und denselben Lösungsansatz mit denselben Risiken wie im Fall der Verschlüsselung. Warum ist die eine Hintertür im Sicherheitskonzept ein Aufreger, die andere hingegen nicht? Bei näherer Betrachtung fallen allerlei Unterschiede auf:

  • Feuerwehr, Gebäudebetreiber und Gebäudenutzer verfolgen gemeinsame Interessen und profitieren von der Lösung. Alle drei Parteien wollen Brände schnell gelöscht und Fehlalarme ohne unnötige Nebenschäden abgestellt sehen. Strafverfolger hingegen sind für die Verfolgten, ob schuldig oder unschuldig, stets ein Gegner und für Dienstanbieter mindestens lästig. Die Krypto-Hintertür schafft keine Win-Win-Situation.
  • Im Fall der Schlüsseldepots wirkt ein weiterer Player, der ein eigennütziges Interesse an optimaler Sicherheit hat: die Versicherer, die weder für Brandschäden noch für Einbrüche mehr als unbedingt nötig zahlen möchten. Sie setzen sich mit handfesten wirtschaftlichen Mitteln dafür ein, dass das Missbrauchsrisiko gering bleibt. Kryptohintertüren könnte man zwar prinzipiell der gerichtlichen Kontrolle unterwerfen, aber den Gerichten fehlt das ökonomische Optimierungsinteresse.
  • Es gibt ein sichtbares und plausibles Risikomanagement. Feuerwehrschlüsseldepots geben bei richtiger Implementierung der Feuerwehr Darmstadt Zugang zu ausgewählten Gebäuden in und um Darmstadt und der Feuerwehr Kassel Zugang zu ausgewählten Gebäuden in Kassel. Ein Secure Golden Key™, wie es in der Neuauflage der Kryptodiskussion heißt, gäbe vermutlich den Strafverfolgungsbehörden mehrerer Länder Zugriff auf alle Geräte der jeweiligen Plattform – man wäre sonst machtlos gegen kriminelle Touristen und im Ausland gekaufte Telefone.
  • Schlüsseldepots werden vorwiegend in öffentlichen und halböffentlichen Gebäuden (Kaufhäuser, Bürogebäude, Industrieanlagen usw.) eingesetzt. Das Reihenhaus von Tante Erna hat keins.
  • Die gewährten Zugangsrechte sind begrenzt. Der Generalschlüssel aus dem Depot öffnet eine definierte Menge von Zugängen; der Safe im Büro gehört nicht dazu. Demgegenüber ermöglicht ein Kryptogeneralschlüssel mit hoher Wahrscheinlichkeit eine Privilegieneskalation, wenn sich damit  Zugangsdaten (neben Passworten zum Beispiel Session-IDs) für weitere Dienste oder Geräte lesen lassen.
  • Die Betroffenen haben subjektiv und objektiv mehr Kontrolle über die Verwendung der deponierten Schlüssel: Das Feuerwehrschlüsseldepot ist gut sichtbar vor Ort installiert, was unbemerkte Zugriffe erschwert. Dass jemand meine Daten entschlüsselt, bekomme ich dagegen nie mit.
  • Der relative Sicherheitsverlust bei Missbrauch ist geringer. Sowohl die Feuerwehr als auch Einbrecher kommen sowieso rein, wenn sie das wirklich wollen und eine Weile Lärm machen dürfen. Ein Schlüssel macht es einfacher, aber selten überhaupt erst möglich. Das ist auch jedem klar. Von verschlüsselten Daten erwarten wir, dass sie ohne Schlüssel so gut wie gelöscht sind.

Hintertüren beziehungsweise Generalschlüssel für den Staat können akzeptabel sein – wenn der Kontext und die Implementierung stimmen. Ob man sie dann auch braucht und haben möchte, ist noch einmal eine andere Frage. Die Notwendigkeit, Beweise mit einem gewissen Ermittlungsaufwand beschaffen zu müssen, statt sie einfach irgendwo auszulesen, kann ein ganz brauchbarer Kontrollmechanismus sein.


Diese Schlagzeile war wohl zu gut, um sie sich von Tatsachen kaputt machen zu lassen: »Straßenbahn-Unfälle mit Verletzten in Leipzig nehmen zu – Statistik: LVB-Fahrer häufig Schuld,« titelt die Leipziger Volkszeitung. Das kommt gewiss gut an bei der Zielgruppe, unterstellt der Leipziger seiner »Bimmel« doch traditionell, sie fahre nach dem UKB-Prinzip– Umfahren, Klingeln, Bremsen.

Im Text wird aus dem häufig erst einmal ein nichtssagendes regelmäßig. Mehr als dies geben die Daten einige Absätze weiter unten auch nicht her. Von 366 Unfällen mit Straßenbahnen verursachten deren Fahrer und Technik im vergangenen Jahr 44, das sind gerade mal 12% oder ungefär jeder achte Unfall. Die Statistik sagt das genaue Gegenteil der Schlagzeile: Die Straßenbahnfahrer sind selten schuld.

2. CAST-Seminar »Sichere Software entwickeln« am 15. Mai 2014

Unser CAST-Seminar »Sichere Software entwickeln – Erfahrungen, Methoden, Werkzeuge« geht in die zweite Runde. Am 15. Mai 2014 laden wir zum Erfahrungsaustausch ins Darmstadtium ein. Vorträge von Praktikern und aus der angewandten Forschung beleuchten das Thema von allen Seiten. Unsere Themen in diesem Jahr:

  • Organisation der sicheren Softwareentwicklung in Großunternehmen
  • Security in schlanken und agilen Processen
  • Denial-of-Service-Schwachstellen in Anwendungen
  • Sicherheitsaspekte der Schnittstellenentwicklung
  • Bedrohungsmodellierung und Sicherheitsanforderungen in der Praxis
  • Skalierung von Methoden am Beispiel der Risikoanalyse

Anmeldung und Programm unter

Denkverbote für Star-Trek-Computer?

Zwei Jahre nach Datenkrake Google ist aus den damals noch unscharfen Gedanken mit Unterstützung meiner Kolleginnen Annika Selzer, Andreas Poller und Mark Bedner ein Artikel geworden: Denkverbote für Star-Trek-Computer?, Datenschutz und Datensicherheit – DuD 38(1), Januar 2014, DOI: 10.1007/s11623-014-0008-x. Abgeschlossen ist das Thema damit nicht, die Diskussion geht gerade erst richtig los.

Vor 30 Jahren definierte das Bundesverfassungsgericht im Volkszählungsurteil das Recht auf informationelle Selbstbestimmung und erklärte es zu einer Voraussetzung für Freiheit und Gemeinwohl. Die elektronische Datenverarbeitung (EDV), so nannte man die Informationstechnik damals, steckte noch tief im Manufakturzeitalter. Datenbanken ersetzten gerade die Karteischränke, das beschriebene und sortierte Papier. Wissenschaftler begannen, über künstliche Intelligenz nachzudenken, aber das war eine Zukunftsvision; der Spielfilm Computer Chess fängt die Stimmung jener Zeit ein.

Einerseits zeugt das Volkszählungsurteil von Weitsicht. Aus der Datenmanufaktur ist eine Datenindustrie geworden. Computer spielen heute nicht nur Schach auf Weltmeisterniveau, sie gewinnen auch im Fernsehquiz Jeopardy! Amazon, Netflix, und viele andere Dienste empfehlen uns, was unserem Geschmack entspricht, und liegen damit häufig genug richtig um uns erfolgreich etwas zu verkaufen. Google ermittelt aus Suchanfragen die Ausbreitung von Grippewellen, wenn auch nicht ganz genau. Das Thema Datensammlung und Datenverarbeitung grundsätzlich anzugehen erweist sich im Nachhinein als richtig.

Continue reading Denkverbote für Star-Trek-Computer?

7 Tätigkeiten, die 2012 gefährlicher waren als das Radfahren

Sven Türpe:

Jetzt probieren wir mal die Reblog-Funktion von aus. PresseRad erinnert uns daran, dass die meisten Menschen bei etwas anderem als beim Radfahren sterben. Nahezu alle, um genau zu sein: Wenn jemand gestorben ist, kann man daraus mit hoher Sicherheit schließen, dass er auf dem Weg ins Jenseits keinen Fahrradunfall hatte. (Note to self: Gelegentlich mal nachrechnen.)

Originally posted on PresseRad:

Im Jahre 2012 starben in Deutschland laut Statistischem Bundesamt exakt 412 Radfahrer. Jeder dieser getöteten Radfahrer war sicherlich einer zu viel, hinter jedem einzelnen Fall verbirgt sich ein trauriges Schicksal.

Aber was bedeutet diese Zahl “412” eigentlich. Sind diese 412 nun viel oder wenig, ist Radfahren nun wirklich so gefährlich, wie es oftmals dargestellt wird? Um das mal ein wenig einordnen zu können, hier ein Vergleich mit anderen “Beschäftigungen” im weitesten Sinne:

  1. 417 Menschen starben durch Ertrinken und Untergehen
  2. 426 Personen sind infolge eines Arbeits-, Spiel- bzw. Schulunfalls gestorben
  3. 526 Menschen starben durch Einatmen oder Verschlucken von Nahrungsmitteln
  4. 572 Motorradfahrer starben im Verkehr
  5. 660 Menschen starben als Fußgänger
  6. 1.073 Menschen starben bei Stürzen auf Treppen
  7. 1.384 PKW-Fahrer kamen ums Leben

Insgesamt verstarben in Deutschland genau 869.582 Personen. Der Anteil der getöteten 412 Radfahrer liegt demnach bei 0,047%.

An “Unfällen, Suiziden und vorsätzlichen Handlungen” weist das Statistische Bundesamt übrigens 32.931 Personen…

View original 89 more words

Kreative Wissenschaft

Die Wissenschaften ergründen und beschreiben die Realität. Anders die Informatik: Sie schafft Realität. Computer und Programme sind Menschenwerk. Auch Menschenwerk kann man wissenschaftlich untersuchen – Historiker, Religionswissenschaftler und so weiter tun nicht anderes. Der objektive Blick auf eine selbst bearbeitete Realität fällt allerdings schwer, nicht nur Einzelnen, auch ganzen Gruppen. Wo hört die berechtigte gemeinsame Weltsicht auf, fängt die kollektive Täuschung an?

In der Theorie sind Theorie und Praxis gleich. In der Praxis sind sie es nicht. Einen Beleg liefert das Paper UML in Practice (DOI: 10.1109/ICSE.2013.6606618) von Marian Petre. Sie befragte 50 Softwareentwickler nach ihrer Nutzung der Unified Modeling Language (UML). Aus der wissenschaftlichen Literatur ist UML nicht wegzudenken. Sowohl die grafischen Notationen als auch die zugrundeliegenden formalen Modelle und Metamodelle werden für alles mögliche verwendet und sind auch selbst Untersuchungsgegenstand.

Von den 50 befragten Praktikern jedoch gaben 35 an, UML überhaupt nicht zu nutzen. Weitere 11 setzen (Teile von) UML zwar ein, jedoch informell als Kreativitäts-, Diskussions- und Kommunikationswerkzeug. Für die formalen Modelle unter der Haube interessiert sich diese Gruppe herzlich wenig und sie hält sich auch nicht daran. Statt im Metamodell Profile und Erweiterungen zu definieren, passen Praktiker die Modellierungssprache ad hoc ihren Bedürfnissen an.

Theoretikern gefällt UML, weil man darüber so viel schreiben und die praktische Bedeutung einfach unterstellen kann. Praktiker brauchen Tools, die ihnen objektiv bei der Arbeit helfen und lassen alles andere liegen.

Morgen kann vielleicht etwas passieren

»Ich will jedenfalls auf dieses Problem aufmerksam machen: Sicherheitsbedürfnisse sind strukturell unstillbar. Es ist gegen das Argument ‘Morgen kann vielleicht etwas passieren’ kein Kraut gewachsen.«

— Winfried Hassemer im Streitgespräch mit Wolfgang Schäuble (via Telepolis)

Zu kurz gedacht wäre allerdings, dies – und die Schlussfolgerung, dass man Grenzen setzen müsse – nur auf staatliche Sicherheitsgesetze, -behörden und -projekte zu beziehen. Der Satz gilt in alle Richtungen und für alle Sicherheitsbedürfnisse, also auch zum Beispiel für den Ruf nach mehr Datenschutz, mehr Verschlüsselung, weniger NSA und so weiter.

Morgen kann vielleicht etwas passieren. Das ist kein ausreichender Grund, auf Segnungen des Internet-Zeitalters zu verzichten, auch wenn sie Google, Facebook oder Cloud Computing heißen. Es ist nicht mal ein ausreichender Grund, sich anders zu verhalten und etwa amerikanische Dienstleister zu meiden, öfter zu verschlüsseln oder Datenpakete anders zu routen.

Morgen kann vielleicht etwas passieren. Etwas dagegen zu tun lohnt sich nur, wenn man sein individuelles Risiko nennenswert reduziert und der Aufwand im Verhältnis zur Risikoreduktion steht. Deswegen erlaube ich mir, die Snowden-Enthüllungen mit Interesse zur Kenntnis zu nehmen, in meinem alltäglichen Verhalten aber nicht weiter darauf zu reagieren. Ich habe keinerlei Anhaltspunkte dafür, dass die NSA mein Leben beeinflusst, folglich lohnt es sich auch nicht, individuelle Maßnahmen zu ergreifen.

Unterschätzte Risiken: Heiterkeit

Jauchzet, frohlocket? Besser erst mal den Hausarzt konsultieren. Das Nutzen-Risiko-Verhältnis beim Lachen ist unübersichtlich, wie eine in der Weihnachtsausgabe des BMJ veröffentlichte Literaturauswertung zeigt. Die Autoren fassen zusammen:

»However, laughter is no joke—dangers include syncope, cardiac and oesophageal rupture, and protrusion of abdominal hernias (from side splitting laughter or laughing fit to burst), asthma attacks, interlobular emphysema, cataplexy, headaches, jaw dislocation, and stress incontinence (from laughing like a drain). Infectious laughter can disseminate real infection, which is potentially preventable by laughing up your sleeve.«

(R.E. Ferner; J.K. Aronson:
Laughter and MIRTH (Methodical Investigation of Risibility, Therapeutic and Harmful): narrative synthesis)


Die halbe Wahrheit

Langsam spricht sich herum, dass mikoskopische Sicherheitsbetrachtungen zwar nicht unnütz sind, für sich genommen jedoch wenig aussagen. Ob Daten verschlüsselt sind oder nicht, ob ein System Standardmechanismen einsetzt oder sich auf andere Constraints stützt, oder wie ein einzelnes Exemplar aus einem Ökosystem auf eine spezifische Angriffstechnik reagiert – wie sicher oder unsicher wir am Ende sind, werden wir aus diesen Informationen alleine nicht ableiten können. Die WIrkung von Sicherheitsmaßnahmen ist relativ zum Anwendungs- und Bedrohungskontext; wer ernsthaft über Sicherheit diskutieren möchte, muss diesen Kontext behandeln.

Zwei lesenswerte Blogbeiträge zu aktuellen Nachrichten illustrieren dies:

  • Hanno Zulla skizziert in Wahl, Ausweispflicht und Wahlfälschung, wieso es völlig normal und kein größeres Problem ist, ohne Ausweiskontrolle wählen zu dürfen. Wer das Gesamtsystem betrachtet, wird seiner Argumentation folgen können.
  • Volker Weber nimmt die Meldungen über erfolgreich angegriffene Fingerabdrucksensoren im iPhone aufs Korn und findet eine hübsche Analogie: Sensation: Glas ist nicht sicher.

Beiden Fällen liegt eine Checklisten-Mentalität zugrunde: Sicher sei nur, was die Mechanismen X, Y und Z mit den Eigenschaften A, B und C enthalte. Eigentlich sollten wir es besser wissen, spätestens seit sich Datensätze auf Plastikkarten gegenüber vielerlei “sicheren” Verfahren zum Bezahlen im Internet durchgesetzt haben.

P.S.: Eine differenzierte Betrachtung über angreifbare Fingerabdrucksensoren.

P.P.S.: Das Wertvollste an einem iPhone dürfte für die meisten Paarungen von Zielinstanz und Angreifer das iPhone sein und nicht die Daten darauf.

Stundensatz: 22 Euro

Praktikanten verderben die Preise und heulen herum, weil man sie wie Praktikanten behandelt. Dieser langjährige Trend macht auch vor der Sicherheitsbranche nicht Halt. Die Deutsche Post führt vor, wie man 1000 Stunden Pentest für 22.000 Euro einkauft: Statt eine Dienstleistung zu beauftragen und für die geleistete Arbeit zu vergüten, veranstaltet sie einen Wettbewerb und bezahlt nur für Ergebnisse. Und bekommt dafür nicht etwa einen Vogel gezeigt, sondern trifft auf ein williges Prekariat, dem Geld egal ist, wenn es nur was mit Medien^H^H^H^H^H^HHacking machen darf. Damit ist die Post nicht alleine, Bug-Bounty-Programme verbreiten sich rapide und tun im Prinzip dasselbe, nur kontinuierlich. Ist das gut oder schlecht?

Learning from History

Everyone knows the story of Clifford Stoll and and West-German KGB hackers (see the video below) in the late 80s.  Does this history teach us something today? What strikes me as I watch this documentary again is the effort ratio between attackers and defenders. To fight a small adversary group, Stoll invested considerable effort, and from some point involved further people and organizations in the hunt. In effect, once they had been detected, the attackers were on their way to being overpowered and apprehended.

Today, we take more organized approaches to security management and incident response. However, at the same time we try to become more efficient: we want to believe in automated mechanisms like data leakage prevention and policy enforcement. But these mechanisms work on abstractions – they are less complicated than actual attacks. We also want to believe in preventive security design, but soon find ourselves engaged in an eternal arms race as our designs never fully anticipate how attackers adapt. Can procedures and programs be smart enough to fend off intelligent attackers, or does it still take simply more brains on the defender’s than on the attacker’s part to win?