Category Archives: Geschäft

Business

Verdient „cyber“ so viel Aufmerksamkeit?

Millionen Euro
Schäden durch Cybercrime (2016) 51
Jahresetat des BSI (2016) 89
Schäden durch Fahrraddienbstahl (2014) 100
Jahresetat des BSI (2017) 107
Schäden durch Ladendiebstahl 2.000
Schäden durch Wirtschaftskriminalität (2011) 4.100
Rundfunkgebühren (2015) 8.131
Verkehrsinfrastrukturinvestitionen (2016) 12.296
Schaden aus Cum-Ex- und Cum-Cum-Betrug (kumuliert) 31.800
Verteidigungshaushalt (2017, inkl. CIR) 37.005
Unbelegte Cyberschadensdrohung des Verfassungsschutzes 50.000
Googles weltweiter Umsatz (2016) 79.450
(89.460 $)
Jährlicher Umsatzverlust durch schlechte Führungskräfte 105.000
Umsatz im Lebensmitteleinzelhandel (2016) 176.000
Bundeshaushalt (2017) 329.100
Bruttoinlandsprodukt (2016) 3.124.364
(3.466.639 $)

Cyberzeilen sind fett markiert. Zu jeder Zahl ist die Quelle verlinkt. Ich aktualisiere die Tabelle ab und zu mit weiteren Angaben.

Can Penetration Testing Trigger Change in Development Teams?

Software penetration testing has become a common practice in software companies. Penetration testers apply exploratory testing techniques to find vulnerabilities, giving developers feedback on the results of their security efforts—or lack thereof. This immediate benefit is mostly uncontested, although it comes with the caveat that testers find only a fraction of the present vulnerabilities and their work is rather costly.

Security experts commonly recommend that developers should respond to the results of a penetration test not merely by fixing the specific reported vulnerabilities, but rather analyze and mitigate the root causes of these vulnerabilities. Just as commonly, security experts bemoan that this does not seem to happen in practice. Is this true and what prevents penetration testing from having an impact beyond defect fixing?

Studying Software Developers

We studied this question by observing a product group of a software company over the course of a year. The company had hired security consultants to test one of its products for security defects and subsequently train the developers of this product. We wanted to know how effective this intervention was as a trigger for change in development. To this end we conducted two questionnaires, observed the training workshop, analyzed the contents of the group’s wiki and issue tracker, and interviewed developers and their managers.

The product group in our study comprised several Scrum teams, development managers, and product management. Scrum is a management framework for agile software development. Scrum defines three roles—Development Team, Product Owner, and Scrum Master—and artifacts and ceremonies for their collaboration. The Development Team is responsible for and has authority over technical matters and development work; the Product Owner is responsible for requirements and priorities; and the Scrum Master facilitates and moderates their collaboration.

The participants of our study appreciated the penetration test results as feedback and the training workshop as an opportunity to learn. They managed to address the particular vulnerabilities reported by the consultants. They also felt that security needed more attention in their development work. Yet, after addressing the vulnerabilities uncovered by the penetration test, they returned to their familiar ways of working without lasting change.

Analyzing our observations through the lens of organizational routines, we found three key factors inhibiting change in response to the penetration test and training: successful application of existing routines, the organizational structure of roles and responsibilities, and the overall security posture and attitude of the company.

(1) Existing Routines

To address the immediate findings of the penetration test, our developers used an existing bug-fixing and stabilization routine. Defect reports arrive asynchronously and sometimes require quick response; developers therefore commonly dedicate some—variable—percentage of their working time to defect fixing in response to reports. The penetration test fed the team dozens of new defects at once, but developers hat a routine to deal with it. Moreover, management tracked the number of open defects, so that the sudden increase raised attention and created pressure on the team to get this number down.

Feature development, on the other hand—where change would have to occur—remained mostly unaffected. Feature development followed the process of Scrum and the penetration test neither had a specific impact here nor did it feed requests or ideas into this routine.

(2) Organizational Structure

Following the ideas of Scrum and agile development, a strong division of labor and responsibilities characterized the organizational structure in the setting of our study. Product management and product owners were responsible for the direction of the development work, whereas development teams enjoyed a certain autonomy in technical questions. This structure worked as a social contract: managers expected developers to take care of security as a matter of quality and developers were keen to deliver the features requested by management. However, the penetration test had little impact on the manager’s priorities beyond the pressure to reduce the number of open defects. The developers thus found themselves in a situation where security was not explicitly required and additional security work could not be justified.

(3) Business Role of Security

Finally, security had limited perceived importance for the business of the studied company, which thus far had not experienced any public security disaster and did not actively sell security. The company therefore lacked a security narrative that could have been used to justify security efforts beyond defect fixing. This, together with the inherent low visibility of security and insecurity, shaped priorities. Product managers knew that features sell their products—new features are easy to show and explain, whereas security improvements are not. Security was perceived as contributing little to the success of the product and the company, making it a low-priority requirement.

Our study points to some of the complexities of managing software development and of triggering change by interventions. While it would be tempting to assign blame to a single factors, such as agile development or negligent management, the problem is really more complicated. Organizational structures and routines exist and they are shaped by business needs. Scrum, for example, is highly beneficial for the studied company. One might even ask whether the company’s dealing with security is a problem in the first place. Are they perhaps doing the right thing for their market and customers?

Our Paper:

A. Poller, L. Kocksch, S. Türpe, F. A. Epp; K. Kinder-Kurlanda: Can Security Become a Routine? A Study of Organizational Change in an Agile Software Development Group. Proceedings of the 2017 ACM Conference on Computer Supported Cooperative Work and Social Computing (CSCW’17), February 25–March 1, 2017, Portland, OR, USA.
[DOI: 10.1145/2998181.2998191, BibTeX, slide deck]

Apple, the FBI, and the Omnipotence Paradox

“Can God create a rock so heavy He could not lift it?” this is one version of the omnipotence paradox. To make a long story short, ominpotence as a concept leads to similar logical problems as the naïve set-of-sets and sets-containing-themselves constructions in Russel’s paradox. Some use this paradox to question religion; others use it to question logic; and pondering such questions generally seems to belong to the realm of philosophy. But the ongoing new round of (civil) crypto wars is bringing a tranformed version of this paradox into everyone’s pocket.

Can Apple create an encryption mechanism so strong that even Apple cannot break it? Apple claims so, at least for the particular situation, in their defense against the FBI’s request for help with unlocking a dead terrorist’s iPhone: “As a result of these stronger protections that require data encryption, we are no longer able to use the data extraction process on an iPhone running iOS 8 or later.” Although some residual risk of unknown vulnerabilities remains, this claim seems believable as far as it concerns retroactive circumvention of security defenses. Just as a locksmith can make a lock that will be as hard to break for its maker as for any other locksmith, a gadgetsmith can make gadgets without known backdoors or weaknesses that this gadgetsmith might exploit. This is challenging, but possible.

However, the security of any encryption mechanism hinges on the integrity of key components, such as the encryption algorithm, its implementation, auxiliary functions like key generation and their implementation, and the execution environment of these functions. The maker of a gadget can always weaken it for future access.

Should Apple be allowed to make and sell devices with security mechanisms so strong that neither Apple nor anyone else can break or circumvent them in the course of legitimate investigations? This is the real question here, and a democratic state based on justice and integrity has established institutions and procedures to come to a decision and enforce it. As long as Apple does not rise above states and governments, they will have to comply with laws and regulations if they are not to become the VW of Silicon Valley.

Thus far we do not understand very well how to design systems that allow legitimate law enforcement access while also keeping data secure against illiegitimate access and abuse or excessive use of legitimate means. Perhaps in the end we will have to conclude that too much security would have to be sacrificed for guaranteed law enforcement access, as security experts warn almost in unison, or that a smartphone is too personal a mind extension for anyone to access it without its user’s permission. But this debate we must have: What should the FBI be allowed to access, what would be the design implications of guaranteed access requirements, and which side effects would we need to consider?

For all we know, security experts have a point warning about weakening what does already break more often than not. To expectat that companies could stand above the law because security, however, is just silly.

PS, remember Clarke’s first law: “When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.”

PPS: Last Week Tonight with John Oliver: Encryption

Verbraucherschutz für #Neuland

Wieder einmal ist ein Programm damit aufgefallen, dass es dort, wo es installiert wird, die Umgebung vandalisiert. Kristian Köhntopp fasst das Problem anschaulich zusammen und die Kommentare unter seinem Post illustrieren, dass es sich nicht um einen Einzelfall handelt. Technisch kann man das Problem im Prinzip lösen, indem man einen vertrauenswürdigen Anbieter eine geschlossene Plattform betreiben lässt, die solche Programme verhindert beziehungsweise erkennt und ausschließt. Da stecken freilich einige Annahmen drin, die nicht unbedingt erfüllt sind.

Eigentlich handelt es sich jedoch um ein ökonomisches Problem, das nach einer ökonomischen Lösung schreit: “Moral hazard occurs under a type of information asymmetry where the risk-taking party to a transaction knows more about its intentions than the party paying the consequences of the risk. More broadly, moral hazard occurs when the party with more information about its actions or intentions has a tendency or incentive to behave inappropriately from the perspective of the party with less information.” — (Wikipedia: Moral Hazard)

Produkthaftung löst das Problem nicht unbedingt, sondern führt nur zur risikominimierenden Gestaltung von Firmengeflechten. Jedes Produkt bekommt eine eigene Wegwerffirma ohne nennenswertes Vermögen, die man im Krisenfall kostengünstig opfern kann. Dieses Modell ist auch im Security-Geschäft längst erprobt (Fallstudie: DigiNotar). Man müsste die Unternehmen zwingen, Rücklagen zu bilden und in einen Haftungsfond oder so etwas einzuzahlen. Kann man tun, passt aber besser zu Atomkraftwerken.

Zwangsweise hergestellte Transparenz bietet sich als Lösungsweg an. In #Altland haben wir dafür die Stiftung Warentest, aber die hat mit ihren Vergleichstests von Sonnencreme, Fahrradhelmen und Akkuscharubern schon genug zu tun. In #Neuland glaubte man früher, das Problem mit Positivzertifizierungen lösen zu können, die einem einzelnen Produkt definierte Sicherheitseigenschaften bescheinigen. Das funktioniert nur in Nischen gut. In jüngerer Zeit gesellen sich dazu allerlei Bug Bounties und Initiativen wie das Project Zero.

Wenn ich diese Ansätze frankensteine, komme ich auf eine unabhängige und solide finanzierte Europäische Stiftung IT-Sicherheit, die sich relevante Software näher anschaut und die Ergebnisse publiziert. Gegenstand ihrer Tätigkeit wären Consumer- und Massenprodukte, die sie auf Sicherheitsmängel und überraschende Funtionen prüft. Das Verschleiern von Funktionen müsste man vielleicht noch unter Strafe stellen, damit das funktioniert. Außerdem wird man sich überlegen müssen, wie die Tester ungehinderten Zugang zu SaaS bekommen. Das sind freilich Detailprobleme; erst einmal müssen wir grundsätzlich entscheiden, wie digitaler Verbraucherschutz jenseits von Seien Sie vorsichtig mit dem Internet aussehen soll.

(Geringfügig überarbeitete Fassung eines Posts auf Google+)

Sicherheit muss zweitrangig sein, sonst steht sie im Weg

Seit zwei Jahrzehnten träumt Deutschland erfolglos davon, die elektrische Regierung, staatsnahe Systeme wie die Gesundheitstelematik sowie das Internet überhaupt dadurch zu fördern, dass man generische Sicherheitsdienste amtlich entwickelt, standardisiert und reguliert. Sichtbare Zeichen dafür sind das Signaturgesetz, die Gesundheitskarte, DE-Mail sowie die eID-Funktion des Personalausweises.

Gut funktioniert hat das in keinem dieser Fälle. Die elektronische Signatur ist so wenig verbreitet, dass man ein darauf gestütztes Verfahren für den elektronischen Entgelt-Nachweis (ELENA) einstellen musste. Die Gesundheitskarte kann nach mehr als einer Dekade Entwicklungszeit – die Gründung der gematik liegt länger zurück als der erste Spatenstich für BER – kaum mehr als ihre Vorgängerin. De-Mail ist im Gegensatz zum Vorgänger eID noch nicht im Stadium der Ideenwettbewerbe angekommen, leidet jedoch unter vergleichbaren Akzeptanzproblemen.

Gemeinsam ist diesen Fällen der Versuch, eine generische Sicherheitstechnologie für eine Vielzahl noch unbekannter Anwendungen zu schaffen in der Annahme, diese Sicherheitstechnologie sei genau das, was den Anwendungen fehle. Beides ist falsch. Wer mit der Sicherheitstechnologie anfängt, macht den Entwurfsprozess kaputt und bekommt Design around Security statt Security by Design, und Anwendungen müssen zuerst funktioneren, bevor man beginnt, ihre Sicherheit zu optimieren. Continue reading Sicherheit muss zweitrangig sein, sonst steht sie im Weg

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.

Kosten und Nutzen

“Jede Sicherheitsmaßnahme lässt sich umgehen.” – Jochim Selzer argumentiert auf G+, dies sei keine gute Begründung für den  Verzicht auf Sicherheitsmaßnahmen. Damit hat er Recht, aber dies ist umgekehrt keine ausreichende Begründung für beliebige Sicherheitsmaßnahmen. Seiner Betrachtung fehlt ein Faktor: das Kosten-Nutzen-Verhältnis. Mehr Sicherheit oder auch überhaupt Sicherheit wird zum Verlustgeschäft, wenn dem Aufwand keine adäquate Risikoreduktion gegenübersteht. Das klingt trivial, macht die Sache in Wirklichkeit jedoch ziemlich kompliziert.

Die Kosten einer Sicherheitsmaßnahme sind nicht nur die Anschaffungs-, sondern auch die Betriebskosten. Nicht alle Kosten manifestieren sich in finanziellen Transaktionen, sondern zum Beispiel in Zeit- und Arbeitsaufwand. Auch sehr kleine Aufwände können zu erheblichen Kosten führen, wenn sie in Alltagssituationen immer wieder anfallen. Auch das Ändern von Gewohnheiten ist teuer. Ein häufig verwendetes Passwort zu ändern, kostet mich zum Beispiel jedesmal einige Tage voller Fehlversuche mit dem alten Passwort, bis ich mich an die Änderung gewöhnt habe — und eine andere Empfehlung legt mir nahe, meinen Rechner beim Verlassen immer zu sperren.

Der Nutzen einer Sicherheitsmaßnahme ergibt sich nicht aus ihrer lokal messbaren Wirkung, sondern aus ihrem Einfluss auf das gesamte Risikoprofil. Sicherheitsmaßnahmen können irrelevant sein, wenn das Risiko – bezogen auf die Konsequenzen – insgesamt sehr klein ist und von anderen Risiken dominiert wird. Wenn ich zum Beispiel ein Smartphone oder einen Laptop mit mir herumtrage und darauf keine ungewöhnlich wertvollen Daten gespeichert sind, dann liegt das dominante Risiko im Verlust der Hardware. Ob ich meine Daten verschlüsselt habe oder nicht, ist dann relativ belanglos. Ebenso brauche ich mich als Individuum, zumal im Mitteleuropa der Gegenwart, nicht vor der NSA zu fürchten, wenn ich bedenkenlos auf Haushaltsleitern steige und am Straßenverkehr teilnehme. Ich werde höchstwahrscheinlich an einem Unfall, an einer Krankheit oder an Altersschwäche sterben und nicht an einem Drohnenangriff wegen eines algorithmisch hergeleiteten Terrorverdachts.

Hinzu kommt, dass Sicherheitsmaßnahmen nicht notwendig Risiken verringern, sondern sie oft nur verlagern oder transformieren. Einbrecher durchwühlen die unverschlossene Gartenlaube und nehmen tragbare Wertsachen sowie Alkoholvorräte mit. Einbrecher durchwühlen die verschlossene Gartenlaube und nehmen tragbare Wertachen und Alkoholvorräte mit, nachdem sie die Tür oder das Fenster demoliert haben. Was habe ich nun vom guten Schloss? Die Einbrecher müssen ein Brecheisen mitbringen und werden vielleicht (aber unwahrscheinlich) gehört – und ich habe höhere Kosten pro Vorfall, selbst wenn nichts gestohlen wird. Ich fahre besser, wenn ich die Tür offen lasse und kein potenzielles Diebesgut lagere.  Das Problem der Risikoverlagerung und -transformation ist typisch für Security, wo wir es mit adaptiven Angreiferkollektiven zu tun haben. In geringerem Maße kann es aber auch bei Safety-Maßnahmen auftreten, wenn diese Maßnahmen unerwünschte Nebenwirkungen haben und man also eine Risikoausprägung gegen eine andere eintauscht. Im Klettergerüst getragen kann ein Fahrradhelm Kinder strangulieren.

Ökonomisch betrachtet sind deswegen viele Sicherheitsratschläge für die Katz. Kosten und Nutzen haben außerdem eine subjektive Komponente. Ökonomische Rationalität beschreibt ein (angenommenes) Optimierungsverhalten unter Berücksichtigung persönlicher Präferenzen. Jeder ist frei darin festzulegen, wie viel ihm ein bestimmter, quantifizierter Nutzen im Vergleich zu anderen Angeboten mit denselben Kosten wert ist oder wie sehr ihn eine bestimmte Unannehmlichkeit im Vergleich zu einer anderen belastet. Auch ein Selbstmörder, der sich vor seiner Rettung schützt, kann ökonomisch rational handeln, wenn ihm sein eigener Tod nur wichtiger ist als alles andere. In diesem Sinne ist nichts daran auszusetzen, dass sich jemand etwa gegen den Sicherheitsgurt, gegen den Fahrradhelm, gegen ein kompliziertes Password oder gegen die E-Mail-Verschlüsselung entscheidet. Präskriptive Overrides sind nur dort angebracht, wo aus solchen Präferenzen erhebliche gesellschaftliche Probleme resultieren.

Wohlfeile Empfehlungen

Ungefähr einmal pro Woche rät man uns zur Abkehr von einem beliebten Dienst und empfiehlt uns Nischenanbieter als Alternativen. Die Begründung: Sicherheit und Datenschutz. Die tatsächlichen Reaktionen bleiben vorhersehbar verhalten und nächste Woche geht es mit neuem Anlass wieder los. Was soll das?

Offenkundig gehen diese Ratschläge an der Realität vorbei. Auf einem funktionierenden Markt ist niemand erfolgreich von Gottes Gnaden. Nachfrager entscheiden, welche Angebote ihre Bedürfnisse am besten erfüllen. Die meisten Nutzer und Kunden hat derjenige, der die Bedürfnisse der breiten Masse ausreichend gut erfüllt. Er verliert seine Rolle, wenn ein anderer das besser tut; er verliert sie nicht, wenn sich daneben ein Nischenanbieter auf eine kleine Gruppe mit besonderen Bedürfnissen spezialisiert.

Dass viele Menschen zum Beispiel Google, Facebook oder WhatsApp nutzen, hat handfeste Gründe, die man untersuchen und erklären kann. Die Marktpositionen dieser Firmen und Dienste sind nur das Resultat. (Sie können sich auch schnell ändern. Erinnert sich noch jemand an Lycos, Altavista, Yahoo, Nokia, MySpace oder StudiVZ?) Sicherheit und Datenschutz sind dabei bereits eingepreist: Wer ein Angebot auswählt, weil es am besten zu seinen Präferenzen passt, wählt alle anderen ab, die dazu weniger gut passen. Ihm die abgewählten Alternativen noch einmal aufzuzählen und einen bereits in die Wahl eingeflossenen Aspekt herauszustreichen, wird die Entscheidung selten ändern.

Warum tun sie’s dennoch immer wieder und empfehlen uns, was wir bereits zurückgewiesen haben? Weil der Nachrichtenmarkt so etwas kauft. Wer auf sich aufmerksam machen möchte, muss Material liefern, mit dem Medien etwas anfangen können. Unabhängige Expertenempfehlungen sind gut, die kann jeder guten Gewissens verbreiten und sie sind auf diesem Niveau auch nicht schwer zu geben. Das Versprechen von mehr Sicherheit und Datenschutz ist noch besser, denn dieses Versprechen lässt sich kurzfristig kaum wiederlegen.

Vielleicht tun sie’s auch, weil sie am Ende vom ständigen Scheitern profitieren. Was wären die Mahner und Aktivisten, wenn alle ihren Ratschlägen folgten?

P.S.
Nico Lumma über Die Sache mit der hilflosen Datenschutzhysterie
.

Zeckenalarm außer der Reihe

Abweichend vom gewohnten Zeckenalarmzyklus warnt das Robert-Koch-Institut mitten im Winter vor einer Krankheit, die jedes Jahr ungefähr 0.0005% der Bevölkerung – 400 von 80.000.000 – befällt:

»Mit Blick auf die überdurchschnittliche hohe Zahl von Hirn- und Hirnhaut-Entzündungen nach Zeckenbissen im Jahr 2013 rät das Robert Koch-Institut (RKI) Menschen, die in Risikogebieten wohnen und sich aufhalten, sich impfen zu lassen.
(…)
Für das Jahr 2013 liegen bundesweit bisher rund 400 Meldungen für die von Zecken übertragene Frühsommer-Meningoenzephalitis (FSME) vor. Rund die Hälfte der vom RKI erfassten Patienten erkrankte schwer an einer Entzündung der Hirnhaut oder des Gehirns.«

(stern.de: Robert-Koch-Institut rät zur Impfung: Zecken übertrugen 2013 oft gefährliche Viren)

Das Robert-Koch-Institut empfiehlt eine Immunisierung durch drei aufeinanderfolgende Impfungen, die danach alle fünf Jahre aufzufrischen sei.

Experten bei der Arbeit. Das Missverhältnis zwischen Aufwand und Nutzen dürfte offensichtlich sein. Wer sich gegen FSME impfen lässt, läuft auch im kugelsicheren Anzug herum. Alle anderen behandeln besser näherliegende Risiken.

Verständige Menschen

Vielleicht ist die Helmdiskussion bei den Juristen ganz gut aufgehoben, denn gute Juristen sind der natürliche Feind schlechter Argumente:

»Die Helmquote läge bei Erwachsenen wohl kaum bei unter 10%, wenn tatsächlich alle „verständigen Menschen” den Helm trügen.«

– Rechtsanwalt Professor Dr. Winfried Born, Editorial NJW 31/2013

Helmquoten veröffentlicht die Bundesanstalt für Straßenwesen regelmäßig. Trotz jahrelanger Propaganda konnte sich dieses Utensil bei Radfahrern nicht durchsetzen. Ausnahme: unmündige Kinder. Die PR der Styroporbranche versucht sich in den Spin zu retten, Kindern seien vernünftiger als Erwachsene.

Afraid of the Intercloud

Jürgen Geuter asked on G+:

»Ok, help me understand. Why is #Google buying #Nest seen as bad for privacy/data control/etc.?

I don’t get it, the data Google already has about individuals is better. Is it because Google is seen tied to objects that just exist around us (and are not our direct extensions such as smartphones)? Is it the usual underspecified feeling of “creepyness”?«

I went for the creepiness option. This is my reply, which I recycle here:

Maybe it’s because we’re mentally still living in the pre-cloud and in the database paradigm. Google represents like no other organization – maybe except the NSA – a technological progress that’s hard to grasp. We have no appropriate conception of information risk and risk management for a world in which a single organization can process various data about the wealthier half of the planet’s population and draw inferences from these data. Google represents this development, working at its forefront and pushing the limits.

We have no intuition what may, could, or will happen to us in the long run due to this new technology, and we have no idea ho to manage the risks (or non-risks) that we don’t understand. In a way we are in a similar situation as those who drafted our first data protection laws back in the seventies and early eighties: having to manage not only the uncertainty inherent in any risk consideration, but rather an uncertainty about the uncertainty. Back then, the tentative conceptual and legal solution was to ban all storing and processing of personally identifiable data and grant permission only on a case-by-case basis.

Progress has turned this approach into a delusion, but we lack a convincing replacement. We don’t know what’s risky and what isn’t; most of us don’t even understand what creates value in an Internet-scale data processing business. We project all our uncertainties on the pioneers.

P.S.: Just while I was writing this, the following quote appeared in my G+ stream:

»The desire for security and the feeling of insecurity are the same thing. To hold your breath is to lose your breath. A society based on the quest for security is nothing but a breath-retention contest in which everyone is as taut as a drum and as purple as a beet.«

— Alan Watts

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?

Attack-as-a-Service Market Prices

An article in the latest issue of CACM (paywalled) quotes some prices advertised by criminals for elementary attack building blocks:

  • DoS – $50…$500 per day
  • hacking a private e-mail address – $30…$50
  • forged identity documents – <$30
  • software opening fake accounts – <$500
  • custom-made malware – $1,500 + monthly service fee

If you want to get rich, don’t waste your time on developing sophisiticated attack techniques. Look at the services available and devise a business model.

Unterschätzte Risiken: Homöopathie

Homöpathie kann nicht schaden? Denkste! Manche glauben daran, andere nicht. Blöd, wenn die anderen Polizisten sind, das weiße Pulver im Paket aus Uruguay für Heroin halten und gegen die Empfänger ermitteln:

»De nada sirvieron sus explicaciones de que aquel polvo blanco era su tratamiento homeopático contra su mielitis idiopática, que dificultaba su caminar.«

(El País: “Es homeopatía, no heroína”)

In deren Ohren klingt Homöpathie nach einer ganz schlechten Ausrede.

Das Angstgeschäft – ein Verriss

Für den Tagesspiegel nimmt Kevin P. Hoffmann die allgegenwärtge Sicherheitspropaganda auseinander. Kostprobe:

»Gleichwohl sind Bürger heute bereit, mitunter 60 bis über 100 Euro für ein Fahrradschloss auszugeben, um damit ein Rad zu schützen, das kaum doppelt so teuer war.

Auffällig ist auch, mit welcher souveränen Arroganz Vertreter der Sicherheitsbranchen ihrer potenziellen Kundschaft entgegentreten. Bürger seien zu dumm, Gefahren richtig einzuschätzen, hört und liest man immer wieder

(Tagesspiegel: Nach den Anschlägen von Boston: Gute Geschäfte mit der Angst)

Mit Sicherheit ist kein Geschäft zu machen. Investitionen in Sicherheit sind erzwungener Konsum; wer bei Verstand ist, wird die Ausgaben für Sicherheit minimieren und allerlei Risiken einfach hinnehmen. Geschäfte macht man mit Angst, und mit Produkten, die Angst reduzieren. Auf Sicherheit kommt es dabei nicht an.

Number Crunching

HP veröffentlicht den 2012 Cyber Security Risk Report. Neben dem Security Report 2013 von Checkpoint sieht HP natürlich alt aus, aber dafür legen die mit der neuen Forschungsabteilung jetzt ja 14-tägig neue Hot Topics auf den Tisch. Es gab mal Zeiten, da mangelte es an Zahlen, aber mittlerweile gibt es mehr als genug davon. Leider gibt es immer noch zu wenig Maßgebliches oder Interessantes. Gibt es eigentlich eine Statistik über die Anzahl der IT-Sicherheitsstatistiken?