Category Archives: Forschung

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
Schaden durch NotPetya bei Maersk 170…256
Schaden durch organisierte Kriminalität (2016) >1.000
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
Bürokratiekosten der Wirtschaft pro Jahr 45.140
Unbelegte Cyberschadensdrohung von Bitkom und Verfassungsschutz 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.

Advertisements

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]

CfP: 3rd Workshop on Security Information Workers (WSIW 2017)

There will be another edition of WSIW this year and it will be part of SOUPS again, which is in turn co-located with the Usenix Annual Technical Conference. WSIW is concerned with  all kinds of security information work and the people doing such work, like developers, administrators, analysist, consultants, and so on. We were there last year with early results of our penetration testing in software development study. If the subject of your reseach is security work, please consider submitting to WSIW.

CfP: https://www.usenix.org/conference/soups2017/call-for-papers-wsiw2017

Workshop website: https://usec.cispa.uni-saarland.de/wsiw17/

Submissions due: 2017-05-25

Vortrag: „Security by Design?“

Triggerwarnung: work in progress

Vergangene Woche durfte ich auf dem 1. IT-Grundschutztag 2017 zum Thema Security by Design? vortragen. Das Leitthema der Veranstaltung war Application Security und ich habe passend zu unserer Forschung einen Blick auf die Softwareentwicklung geworfen. Sichere Software ist leicht gefordert, aber die Umsetzung im Entwicklungsalltag bereitet Schwierigkeiten: In frühen Phasen der Entwicklung kämpft man mit Ungewissheit und es ist schwer, Entscheidungen zu treffen; später weiß man mehr, aber die Veränderung wird schwierig – nicht nur technisch, sondern auch in den Strukturen und Routinen des Entwicklerteams.

Der Vortrag entstand aus einer früheren Fassung, die ich gemeinsam mit Andreas Poller auf dem Workshop „Partizipatives Privacy by Design“ im vergangenen Oktober in Kassel gehalten habe. Aus Andreas’ Vortrag auf der CSCW’17 habe ich mir auch Slides geborgt.

Wer die Tonspur zu den Slides hören möchte: einfach fragen.

An In-Depth Study of More Than Ten Years of Java Exploitation

My colleagues Philipp Holzinger, Stefan Triller, Alexandre Bartel, and Eric Bodden had a closer look at Java and the vulnerabilities discovered in the Java runtime environment during the last decade. They started from known exploits, identified the vulnerabilities exploited, and analyzed and grouped their root causes. Philipp’s presentation of the results at CCS’16 has been recorded and published on YouTube:

(YouTube)

The paper is also available online:

P. Holzinger, S. Triller, A. Bartel, E. Bodden: An In-Depth Study of More Than Ten Years of Java Exploitation. Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (CCS’16), Vienna, Austria, Oct. 24-28, 2016. DOI: 10.1145/2976749.2978361. Artifacts: ccs2016-artifacts-v01.zip

 

Manipulativ gefragt

»Fürchten Sie, dass es in nächster Zeit in Deutschland terroristische Anschläge geben wird oder fürchten Sie dies nicht?« Diese Frage (via) ist unmöglich sauber zu beantworten, denn es handelt sich in Wirklichkeit um zwei Fragen:

  1. Erwarten Sie, dass es in nächster Zeit in Deutschland terroristische Anschläge geben wird?
  2. Fürchten Sie sich davor?

Ich erwarte, dass es in nächster Zeit in Deutschland terroristische Anschläge geben wird, wies es sie seit der Erfindung des Terrorismus immer wieder gegeben hat. Der letzte, von dem ich gehört habe, liegt gerade zwei Tage zurück.

Zu fürchten gibt es dennoch wenig. Wir leben in einem funktionierenden Staat, der Bedrohungen für Leib und Leben gering hält. Um gewaltsam aus dem Leben zu scheiden, muss man schon ordentlich Pech haben.

Die Fragestellung macht es allzu leicht, nüchterne Antworten auf die erste Frage einzusammeln und sie später zu aufgeregten Antworten auf die zweite umzudeuten. Aber auch den Expertinnen und Experten bei infratest dimap kann ja mal ein Fehler unterlaufen, nicht wahr?

Classifying Vehicles

Security is a classification problem: Security mechanisms, or combinations of mechanisms, need to distinguish that which they should allow to happen from that which they should deny. Two aspects complicate this task. First, security mechanisms often only solve a proxy problem. Authentication mechanisms, for example, usually distinguish some form of token – passwords, keys, sensor input, etc. – rather than the actual actors. Second, adversaries attempt to shape their appearance to pass security mechanisms. To be effective, a security mechanism needs to cover these adaptations, at least the feasible ones.

An everyday problem illustrates this: closing roads for some vehicles but not for others. As a universal but costly solution one might install retractable bollards, issue means to operate them to the drivers of permitted vehicles, and prosecute abuse. This approach is very precise, because classification rests on an artificial feature designed solely for security purposes.

Simpler mechanisms can work sufficiently well if (a) intrinsic features of vehicles are correlated with the desired classification well enough, and (b) modification of these features is subject to constraints so that evading the classifier is infeasible within the adversary model.

Bus traps and sump busters classify vehicles by size, letting lorries and buses pass while stopping common passenger cars. The real intention is to classify vehicles by purpose and operator, but physical dimensions happen to constitute a sufficiently good approximation. Vehicle size correlates with purpose. The distribution of sizes is skewed; there are many more passenger cars than buses, so keeping even just most of them out does a lot. Vehicle dimensions do not change on the fly, and are interdependent with other features and requirements. Although a straightforward way exists to defeat a bus trap – get a car that can pass – this is too expensive for most potential adversaries and their possible gain from the attack.

The Key-Under-the-Doormat Analogy Has a Flaw

The crypto wars are back, and with them the analogy of putting keys under the doormat:

… you can’t build a backdoor into our digital devices that only good guys can use. Just like you can’t put a key under a doormat that only the FBI will ever find.

(Rainey Reitman: An Open Letter to President Obama: This is About Math, Not Politics)

This is only truthy. The problem of distinguishing desirable from undesirable interactions to permit the former and deny the latter lies indeed at the heart of any security problem. I have been arguing for years that security is a classification problem; any key management challenge reminds us of it. I have no doubt that designing a crypto backdoor only law enforcement can use only for legitimate purposes, or any sufficiently close approximation, is a problem we remain far from solving for the foreseeable future.

However, the key-under-the-doormat analogy misrepresents the consequences of not putting keys under the doormat, or at least does not properly explain them. Other than (idealized) crypto, our houses and apartments are not particularly secure to begin with. Even without finding a key under the doormat, SWAT teams and burglars alike can enter with moderate effort. This allows legitimate law enforecement to take place at the cost of a burglary (etc.) risk.

Cryptography can be different. Although real-world implementations often have just as many weaknesses as the physical security of our homes, cryptography can create situations where only a backdoor would allow access to plaintext. If all we have is a properly encrypted blob, there is little hope of finding out anything about its plaintext. This does not imply we must have provisions to avoid that situation no matter what the downsides are, but it does contain a valid problem statement: How should we regulate technology that has the potential to reliably deny law enforcement access to certain data?

The answer will probably remain the same, but acknowledging the problem makes it more powerful. The idea that crypto could not be negotiated about is fundamentalist and therefore wrong. Crypto must be negotiated about and all objective evidence speaks in favor of strong crypto.

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+)

Studien

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, http://www.ares-conference.eu/conference/workshops/assd-2015/. 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.

Häufig

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.