Helmet law FAIL

English, Safety, Unterwegs, ,

This is what bicycle helmet laws achieve:

»The New Zealand helmet law (all ages) came into effect on 1 January 1994. It followed Australian helmet laws, introduced in 1990–1992. Pre-law (in 1990) cyclist deaths were nearly a quarter of pedestrians in number, but in 2006–09, the equivalent figure was near to 50% when adjusted for changes to hours cycled and walked. From 1988–91 to 2003–07, cyclists’ overall injury rate per hour increased by 20%. Dr Hillman, from the UK’s Policy Studies Institute, calculated that life years gained by cycling outweighed life years lost in accidents by 20 times. For the period 1989–1990 to 2006–2009, New Zealand survey data showed that average hours cycled per person reduced by 51%. This evaluation finds the helmet law has failed in aspects of promoting cycling, safety, health, accident compensation, environmental issues and civil liberties.«

(Colin F. Clarke:
Evaluation of New Zealand’s bicycle helmet law)

Betreutes Denken

Geschäft, Security, Testlabor, , , , , , , , , ,

Mein Kollege Jörn Eichler sucht Studenten, die unter seiner Betreuung ihre Abschlussarbeit zu einem der folgenden Themen schreiben möchten:

  • Modellgetriebene, sichere Konfiguration von Laufzeitumgebungen für elektronischer Prozesse
  • Entwicklung eines Werkzeugs für die Sicherheitsmodellierung elektronischer Prozesse
  • Modellgetriebenes Testen elektronischer Geschäftsprozesse

Rezeptdatenhandel

Bedrohung, Datenschutz, Geschäft, Risiko, Security, Wahrnehmung, , ,

Wer Gesundheitsdaten missbraucht, will bestimmt Patientenprofile anlegen und damit irgend etwas böses tun. Das scheint plausibel, wenngleich irgend etwas böses selten klar definiert wird, und spielt im Bedrohungsmodell der mühsam im Inkubator am Leben gehaltenen Gesundheitskarte eine zentrale Rolle. Nur halten sich Angreifer nicht an Angreifermodelle:

»Mit den Rezeptdateien, die nicht anonymisiert worden waren, konnten die Unternehmen eventuell nachvollziehen, welche Medikamente von bestimmten Arztpraxen verschrieben wurden. Derartige Informationen würden es ermöglichen, die Arbeit von Außendienstmitarbeitern zu kontrollieren. So könnte man demnach überprüfen, ob Ärzte nach den Besuchen von Vertretern der Pharmaindustrie häufiger bestimmte Medikamente verschreiben.«

(Heise Online: Bericht: Illegaler Handel mit Rezeptdaten)

Warum das verboten ist, spielt keine so große Rolle. Interessanter finde ich die Frage, ob man solche Angriffe im Entwurf unserer Gesundheits-IT berücksichtigt hat. Mehrseitige Sicherheit ist ja kein völlig neues Konzept.

Das Personalchefargument

Angst, Datenschutz, Geschäft, Propaganda, Spackeria, , ,

Kommentarrecycling (dort im Spamfilter hängengeblieben):

Aus Diskussionen über öffentliche persönliche Informationen ist der googelnde Personalchef kaum wegzudenken. Gestritten wird dann darüber, was er denn nun sehen oder nicht sehen soll, damit dem Verkäufer eigener Arbeitskraft nichts schlimmes passiere. Gerne malt man sich phantasievoll die möglichen Folgen verstaubter Partyfotos aus, das gehört zu den Standards solcher Diskussionen. Doch es gibt ein grundlegendes Problem mit dem googelnden Personalchef: das Personalchefargument ist falsch, weil es von falschen Voraussetzungen ausgeht. Auf die Feinheit, ob der Personalchef nun etwas finden soll oder lieber nicht, kommt es dabei nicht an. Im Gegenteil, die Beliebigkeit in diesem Aspekt deutet auf ein grundlegendes Problem in den Axiomen hin. Wer mit einem falschen Satz von Axiomen anfängt, kann damit bekanntlich alles und das Gegenteil begründen.

Das Personalchefargument unterstellt als – regelmäßig unausgesprochene – Voraussetzung ein Unterwerfungsverhältnis zwischen Unternehmen („Arbeitgebern“) und für sie Arbeitenden („Arbeitnehmern“). Der Arbeitnehmer habe sich dem Arbeitgeber wohlgefällig zu verhalten, folgt daraus. In dieser Einseitigkeit ist das Modell falsch. In Wirklichkeit gibt es einen Arbeitsmarkt. Wie jeder andere Markt führt der Arbeitsmarkt führt der Arbeitsmarkt Parteien zusammen, die jeweils ihre eigenen Interessen verfolgen, und lässt sie Geschäfte zum beiderseitigen Nutzen machen. Dabei muss jeder dem anderen entgegenkommen, um seinen angestrebten Nutzen zu realisieren. Ich muss Zeit opfern, um Geld zu verdienen; eine Firma muss Geld opfern, um meine Zeit und meine Fähigkeiten zu bekommen. In der Ökonomie drückt man alles in Geld aus; im richtigen Leben spielen Faktoren wie das Betriebsklima auch ohne explizite Umrechnung eine Rolle.

In einem idealen Markt gibt es keine Ungleichgewichte, keine Seite kann den Markt über ihre Teilnahme hinaus zugunsten der eigenen Interessen beeinflussen. In der Realität greift man zuweilen regulierend ein, wo sich ein Markt zu weit von diesem Ideal entfernt. Regulierende Eingriffe können auch deshalb nötig sein, weil einige der theoretischen Eigenschaften idealer Märkte gar nicht realisierbar sind, zum Beispiel unendlich viele Teilnehmer auf beiden Seiten.

Das Personalchefargument ignoriert die Gegenseitigkeit des marktwirtschaftlichen Austauschs. Es postuliert Verhaltensregeln für Arbeitende, aber keine für Unternehmen, als gäbe es ein Kartell der Arbeitgeber. In Wirklichkeit muss aber jede Seite der anderen entgegenkommen, sonst finden keine Geschäfte statt, und was in einer Paarung von Marktteilnehmern nicht funktioniert, kann in einer anderen zum guten Geschäft werden.

Es mag also durchaus vorkommen, dass Personalchefs Saufbilder aus dem Internet in ihren Entscheidungen berücksichtigen. So wie es auch vorkommt, dass Firmen ihre Entscheidungen auf Horoskope oder graphologische Gutachten stützen. Das bedeutet dann aber nicht, dass jemand keine Arbeit findet, sondern lediglich, dass in einer bestimmten Konstellation kein Geschäft zustandekommt. Sind die Gründe dafür irrational, so ist das sogar zum Schaden des irrational Handelnden.

Eine Voraussetzung für einen gut funktionierenden Markt ist übrigens Transparenz: jeder Teilnehmer soll alle für rationale Entscheidungen relevanten Preise und Qualitätsmerkmale kennen. Die richtige Schlussfolgerung aus dem Personalchefargument ist deshalb nicht, dass jeder Arbeitende sein Online-Image zu polieren habe, sondern dass neben unseren Saufbildern auch die Dreckecken der Unternehmen ins Netz gestellt gehören. Wenn ich mich bei einem Unternehmen bewerbe, bewirbt sich gleichzeitig das Unternehmen bei mir. Da möchte ich schon etwas über seine Vergangenheit erfahren, und die Sommerfeste und Weihnachtsfeiern sind dabei minder relevant.

Missverständnis

Datenschutz, Philosophie, Rechtsabteilung, Regierungsviertel, Spackeria, Wolkenkuckucksheim, ,

Kommentarrecycling:

LeVampyre schreibt sich einen Wolf um zu erklären, warum sie Datenschutz gut und die Spackeria doof findet. Was sie schreibt, fühlt sich irgendwie richtig an, geht aber am Thema vorbei. Ihrem Text fehlt ein Begriff und damit der Kontext: informationelle Selbstbestimmung. Datenschutz ist nur ein Mittel zum Zweck. Wer »den Mißbrauch von Daten (…) unter Strafe stellen« möchte, braucht erst einmal einen Rahmen, in dem sich Missbrauch definieren lässt. Diesen Rahmen bildet nun nicht der Datenschutz als Selbstzweck, sondern die informationelle Selbstbestimmung als Idee: Jede soll Herrin ihrer persönlichen Informationen und Daten sein.

Informationelle Selbstbestimmung ist der Zweck, Datenschutz nur ein Instrument dazu. Vergisst man den Zweck, während man die Anwendung des Instruments optimiert, kommt Paternalismus heraus. Dann bestimme nicht mehr ich, was mit meinen Daten geschieht, sondern Beauftragte, Minister oder die Subkultur meiner Peer Group. Wenn ich Google, Facebook oder dem ganzen Internet bewusst und absichtlich Daten zur Verfügung stelle, ist das weder ein Datenverbrechen der anderen noch meine eigene Dummheit, sondern zuallererst mein gutes Recht. Der Datenschutz muss mich unvoreingenommen dabei unterstützen, dieses Recht auszuüben, ganz gleich, ob ich etwas verschweigen oder etwas mitteilen möchte.

Gleichzeitig vollziehen sich grundlegende Änderugen in der Art und Weise, wie wir – und Unternehmen – Daten verarbeiten und nutzen. Die spezifischen Regelungen des Datenschutzes stammen aus einer anderen Ära und sie können mit diesen Änderungen nur ungenügend umgehen. Das gilt im Guten wie im Schlechten: die endlose Diskussion um den Personenbezug von IP-Adressen zum Beispiel ist einerseits irrelevant für Google und Facebook, andererseits nervig für alle, die sich damit auseinandersetzen müssen.

Nach meinem Verständnis treiben diese beiden Aspekte die Spackeria, der Mismatch zwischen Idee und Umsetzung sowie der Mismatch zwischen Konzept und Realität. Das Ziel der Spackeria ist nicht, die Informationelle Selbstbestimmung abzuschaffen, sondern den Datenschutz als Mittel und Werkzeug der Realität anzupassen.

Zwei Euro fuffzich

Risiko, Security, Unterwegs, Zahlenspiele

In Hessen werden jedes Jahr gut 14-15.000 Fahrräder geklaut, davon 4000 in Frankfurt. Der geschätzte Gesamtschaden liegt bei 6,5 Millionen Euro, die Aufklärungsquote unter zehn Prozent. Bundesweit sind es  300.000 bis 350.000 im Jahr. Dramatische Zahlen? Nö. Bei 70 Millionen Fahrrädern im Land entspricht das gerade mal einem halben Prozent. Der hessische Gesamtschaden ergibt bei 14.000 Fahrrädern einen Schaden von weniger als 500 Euro pro Rad. Auf 350.000 Räder hochgerechnet macht das 175 Millionen Euro – oder zwei Euro fuffzich pro Rad.

Cyber-Krieg, nüchtern betrachtet

Begriffe, Forschung, IT, Security, Vulnerability, Wahrnehmung, ,

Die Süddeutsche hat James A. Lewis (vermutlich den hier) zum Thema Cyberwar interviewt. Herausgekommen ist eine Reihe vernünftiger Ansichten wie diese:

»Ein Staat würde für den Einsatz von Cyberwaffen die gleiche Art militärischer Entscheidungen vornehmen wie für jede andere Art von Waffen. Welchen Vorteil bringt es, die Stromversorgung zu kappen? Und was sind die Risiken dabei? Wenn die USA und China im südchinesischen Meer kämpfen, ist das ein begrenzter Konflikt. Wenn China zivile Ziele auf dem Gebiet der USA attackiert, ist das eine ungeheure Eskalation, die das Risiko birgt, dass die USA auf chinesischem Boden zurückschlagen. Streitkräfte werden gründlich darüber nachdenken, bevor sie einen solchen Angriff wagen. Dazu kommt, dass solche Attacken schwierig sind, und wir dazu neigen, den Schaden zu überschätzen, den sie anrichten. Ich kann mir nicht vorstellen, warum jemand sich die Mühe machen sollte, die Wasserversorgung anzugreifen.«

(sueddeutsche.de: „Wir müssen unsere Verteidigung stärken“)

Lewis betrachtet das Thema nicht im Hollywood- oder Scriptkiddie-Modus, sondern konsequent aus einer militärischen Perspektive. Militärs handeln rational, sie verfolgen taktische und strategische Ziele mit verfügbaren Mitteln und gegen die Handlungen eines Gegeners. Daraus ergibt sich auch das Angreifermodell, das der Verteidigung zugrunde liegt, wie oben im Zitat illustriert. Cyber-Krieg, so Lewis‘ Paradigma, ist keine neue Form des Krieges, die andere verdrängt, sondern eine neue Waffengattung, die den Krieg nicht grundlegend reformiert.

Geisterfahrerzählung

Risiko, Safety, Unterwegs, Zahlenspiele, , , ,

Wieviele Geisterfahrer gibt es eigentlich? Der ADAC hat gezählt:

»Im Zeitraum von Dezember 2008 bis Dezember 2009 seien demnach 2800 Falschfahrer im Radio gemeldet worden. Bei den zwölf Unfällen, die dadurch verursacht worden seien, hätten insgesamt 20 Menschen ihr Leben verloren.«

(Spiegel Online: Geisterfahrer: Plötzlich falsch unterwegs)

Das sind ungefähr siebeneinhalb pro Tag, bundesweit. Mancher Radweg schafft diesen Wert pro Minute.

Causal Insulation

Begriffe, Classifier Security Model, English, Philosophie, Security, , , , , , ,

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.

Unterschätzte Risiken: Kinderüberraschung

Safety, Unterschätzte Risiken, Unterwegs, Verboten, Zahlenspiele,

Laptopdurchsuchung an der Grenze? Pah! Viel eifriger ist der amerikanische Zoll im Beschlagnahmen von Überraschungseiern:

»The U.S. takes catching illegal Kinder candy seriously, judging by the number of them they’ve confiscated in the last year. Officials said they’ve seized more than 25,000 of the treats in 2,000 separate seizures.«

(CBS News: Kinder Surprise egg seized at U.S. border)

 

Cookies, Clients und die Cloud

Datenkrake, Datenschutz, Forschung, Freundlich zum Nutzer, Regierungsviertel, Spackeria, Wolkenkuckucksheim, Zeitmaschine, , , , , , , , ,

Politiker und Bürokraten wollen die Verwendung von Cookies gesetzlich regulieren, erst die EU (mit unklarem Regelungsgehalt und schleppender Umsetzung), ein paar Jahre später nun auch die SPD. Warum ist das blöd? Ich hole mal etwas weiter aus:

Persönliche Computer, PCs, waren in den 70er und 80er Jahren des letzten Jahrhunderts eine große Sache. Jedem seinen eigenen Computer, klein genug für den Schreibtisch und mit verschiedenen Anwendungsprogrammen für vielerlei Zwecke einsetzbar, das hatte es vorher höchstens als Vision gegeben. Aus dieser Frühzeit der Jedermann-IT stammen viele Vorstellungen, die wir noch heute hegen, darunter die Wurzeln unseres Datenschutzes.

Auf den ersten Blick hat sich seitdem wenig geändert. Aus dem PC auf Arbeit wurde ein Gerätezoo für alle Lebenslagen aus PCs, Note- und Netbooks, Smartphones, Tablets, Internetradios, Spiekonsolen und so weiter, technisch im Grunde genommen immer noch persönliche Computer, nur schöner und kleiner und schneller. Seit den 90er Jahren folgte dem Jedermann-Computer das Jedermann-Netz und im folgenden Jahrzehnt wurde dieses Netz mobil und sozial. Allen Schichten gemein ist, dass ihre Nutzer in Selbstbedienung nach Bedarf Dienste einkaufen, die nach dem Umfang der Nutzung bzw. den zugesicherten Ressourcen abgerechnet werden. Dienstanbieter stellen aus einem Pool an Ressourcen ohne Zeitverzug die jeweils nachgefragten Dienste bereit.

Die jetzige Dekade wird das Jahrzehnt des Cloud Computing. So wie der PC in den 70ern entstand und in den 80ern seinen Namen bekam und sich verbreitete, ist Cloud Computing keine ganz neue Sache, sondern längst erfunden, einsatzbereit und zum Teil auch schon etabliert. Neu ist nur, dass es jetzt einen Namen dafür gibt und alle ein Geschäft wittern, nachdem die Early Adopters vorgemacht haben, dass es funktioniert.

Cloud Computing bedeutet, dass ein Großteil der IT als Dienst ins Netz wandert. Das kann auf verschiedenen Abstraktionsebenen geschehen. Infrastructure as a Service (IaaS) bietet virtuelle Maschinen und Speicher, Platform as a Service (PaaS) liefert Anwendungsplattformen und Software as a Service (SaaS) schließlich macht Anwendungssoftware zu einem Dienst. Ein Beispiel für SaaS ist wordpress.com, wo dieses Blog gehostet wird. Die Schichten lassen sich stapeln, ein SaaS-Anbieter kann auf PaaS-Dienste zurückgreifen, die sich ihrerseits auf IaaS stützen. Die unteren Schichten IaaS und PaaS sind vor allem für Unternehmen interessant, während SaaS in Form von allerlei Webdiensten längst Teil unseres Alltags ist und die klassische Nutzung von Anwendungssoftware auf einem PC teils ersetzt, teils ergänzt.

Geht es um Sicherheit und Datenschutz im Cloud Computing, starren alle wie gebannt auf die Dienstseite. Daten wandern ins Netz, ob aus dem Rechenzentrum eines Unternehmens oder vom heimischen PC, und man weiß nicht genau, wo sie eigentlich gespeichert und verarbeitet werden. Das macht Angst und wirft technische, organisatorische und rechtliche Fragen auf. Hinzu kommt, dass der Übergang von Software in Kartons zu Diensten im Netz in Verbindung mit agilen Entwicklungsmethoden die Softwareentwicklungs- und -lebenszyklen verändert. Es gibt kein Google 3.0, das ich kaufen und dann ein paar Jahre verwenden könnte, sondern Änderungen am Dienst im Wochen-, Tage-, Stunden- und sogar Minutentakt. Continuous Deployment und DevOps nennen wir diese bewusste Vermischung von agiler Entwicklung und Produktivbetrieb.

Ein SaaS-Dienst ist nicht in sich abgeschlossen und unabhängig vom Rest des Netzes, sondern es handelt sich, für Nutzer manchmal schwer erkennbar, um eine Aggregation mehrerer Anwendungs- und Hilfsdienste, ergänzt um spezifische Funktionen des aggregierenden Hauptdienstes. Like-Buttons, Widgets, Videos, RSS-Feeds, Analytics, Werbebanner, Nutzerkommentare, Payment, Fonts und so weiter stützen sich auf Fremddienste, die, oft clientseitig, in den Hauptdienst integriert werden. Hilfsdienste haben meist ihren eigenen Betreiber und sie werden in viele verschiedene SaaS-Dienste eingebunden.

Weniger Aufmerksamkeit erhält beim Blick auf die Cloud die irdische Hälfte des Systems, die Client-Seite. Cloud-Dienste besitzen praktisch immer ein Webinterface, mindestens fürs Management, oft auch – und bei SaaS sowieso – für den eigentlichen Dienst. Der Nutzer bekommt damit eine universelle Client-Umgebung, bestehend aus einem Browser mit generischen Plugins (Flash, Java, Silverlight) und Unterstützungsanwendungen (PDF-Viewer, Office, iTunes) auf dem klassischen PC oder aus einem Browser und anwendungsspezifischen Apps auf mobilen Gadgets wie Smartphones oder Tablets.

Nach dieser langen Vorrede nun zurück zu den Cookies. Das Konzept des Cookies wird demnächst volljährig, es handelt sich ursprünglich um kleine Datenhäppchen, die eine Website einer Browserinstanz zur Speicherung übermittelt. Der Browser merkt sich diese Daten und schickt sie für einen festgelegten Zeitraum bei jeder weiteren Interaktion mit der Website dorthin zurück. Heute gibt es darüber hinausgehende Persistenzmechanismen auch für größere Datenmengen im Browser selbst sowie in verbreiteten Plugins, zum Beispiel im Flash Player.

Jeder Dienst in einer SaaS-Aggregation kann Cookies setzen und mit Hilfe dieser Cookies Daten über das Nutzerverhalten über alle Dienstnutzungen hinweg erfassen und sammeln. Die aggregierten Hilfsdienste erhalten dabei Daten aus verschiedenen SaaS-Anwendungskontexten verschiedener Anbieter und sind gleichzeitig für den Nutzer schwer zu identifizieren. Datenschützer stellen zu Recht die Frage, wie die Dienstnutzer unter diesen Bedingungen wirksam von ihrem Recht auf informationelle Selbstbestimmung Gebrauch machen können. Sie geben darauf aber die falschen Antworten.

De jure und traditionell wäre das Problem durch Kommunikation und Vereinbarungen des Nutzers mit jedem einzelnen involvierten Dienstanbieter zu lösen. Aggregierte Hilfsdienste als Auftragsdatenverarbeitung unter einer Vereinbarung zwischen dem Nutzer und dem Anbieter des Hauptdienstes zu subsumieren, wie es etwa für Analytics-Dienste diskutiert wurde,  vereinfacht die Sache wegen der Mehrfacheinbettung der Hilfsdienste in verschiedenste SaaS-Anwendungen nur scheinbar. Außerdem ändert sich permanent irgendwo irgendwas, so dass wir als Nutzer am Ende nur noch mit Zustimmen beschäftigt wären, wenn uns keine Generalvollmacht diese Mühe abnimmt. Erforderlich sind Lösungen, die die Architektur von SaaS-Mashups und der Client-Plattform als gegeben hinnehmen und darauf effektive Mechanismen für den technischen Datenschutz bereitstellen.

Cookies sind dabei nur ein wenig kritisches Randphänomen. Da sie clientseitig gespeichert werden, lässt sich ihre Speicherung und Übermittlung auch clientseitig effektiv steuern. Verbesserungsbedarf gibt es dabei vor allem in der Usability. Wünschenswert wäre zum Beispiel ein einheitliches User Interface für Einstellungen über alle Teilsysteme (Browser, Plugins, Apps, etc.) des Clientsystems hinweg anstelle getrennter, inkonsistenter Management-Schnittstellen für Cookies, Persistent DOM Storage und Flash-Cookies. Sinnvoll fände ich auch eine Möglichkeit, meine Datenschutzeinstellungen zwischen meinen fünf regelmäßig genutzten Clientsystemen zu synchronisieren statt fünfmal dasselbe konfigurieren zu müssen. Aber Clientsysteme und ihre Eigenschaften kommen in der Diskussion oft gar nicht vor. Soll ich ernsthaft mit dreiundzwanzig Diensten Vereinbarungen treffen, statt mir einmal eine Policy zusammenzuklicken, die meine eigene Technik für mich durchsetzt? P3P hatte zwar Schwächen und hat sich nicht durchgesetzt, aber damals hat man doch immerhin noch das Gesamtsystem angeschaut und eine Komponente an die richtige Stelle gesetzt, nämlich in den Client.

Mit formalisierten Rechtsritualen aus der Frühzeit der Alltags-IT ist das Problem nicht in den Griff zu bekommen. Gesucht sind effektive und benutzbare Mechanismen. Das ist die technische Sicht, die politische Dimension hat Benjamin Siggel vor einiger Zeit im Spackeria-Blog betrachtet.

Flawed Security Economics

English, Geschäft, Preisschild, Security, , , ,

I just stumbled upon a piece of economics-of-security reasoning that amazes me:

»Bank robbers steal approximately $100 million per year in the US. (…) To prevent this, banks spend $600 million per year on armored car services and $25 million per year on vault doors. The FBI spends $50 million per year investigating robberies. A good deal more is spent on security guards—approximately 1 million in the US, paid about $24 billion per year (outsourcing makes it difficult to say how many work for banks). In summary, the cost of protecting against bank robberies far exceeds the loss.«

(Michael Lesk, Cybersecurity and Economics, IEEE S&P Nov./Dec. 2011)

I don’t doubt the figures, but the conclusion does not make sense to me. Why should one put the cost of security measures in relation to the losses that they don’t prevent? The $100 million per year are the losses that remain after security. What the security investment prevents is the losses that would occur without it, not the losses that continue to occur despite the effort. I’d love to see an estimation of this quantity. The author even gives a hint towards the possible magnitude, as he continues:

»To look at a less safe society, in a single 2007 bank robbery in Baghdad, robbers made off with $280 million (it was an inside job).«

Perhaps it is even normal for the cost of security to exceed the losses that remain, once the security spending has been optimized?