Das gebe ich mal weiter:
Wir suchen Interessierte aus der Verwaltung, die sich zum Thema Informationssicherheit im Rahmen von Lean Coffees austauschen wollen.
Ursprünglichen Post anzeigen 391 weitere Wörter
Das gebe ich mal weiter:
Wir suchen Interessierte aus der Verwaltung, die sich zum Thema Informationssicherheit im Rahmen von Lean Coffees austauschen wollen.
Ursprünglichen Post anzeigen 391 weitere Wörter
Nothämmer in öffentlichen Verkehrsmitteln werden gerne geklaut. Das hat zwar keinen Sinn, ist aber ganz leicht und manchem betrunkenen Halbstarken reicht die bloße Gelegenheit. Heute ist mir diese clevere Diebstahlsicherung begegnet: An den Nothammer kommt man erst, nachdem man die Notbremse gezogen hat. Das ist im Notfall kein Hindernis, aber Gelegenheitsdieben verdirbt es den Spaß. Zwar ist es nicht schwer, den Notbremsgriff zu ziehen, doch zieht man damit sogleich die Aufmerksamkeit der Fahrerin auf sich. Das dürfte zur Abschreckung genügen.
Lisa Forte has a proposal how to end the ransomware pandemic, and it is a good one: Stop ransom payments. After all the perpetrators are doing it for the money, so their attacks become pointless if they won’t make any. This sounds simple but is often forgotten in favor of blaming the victims. Security is a common good.
Juristen unterscheiden aus gutem Grund zwischen Eigentum und Besitz. Mein vor gut einem Jahr geklautes Fahrrad zum Beispiel ist immer noch mein Eigentum, ich besitze es nur nicht mehr. Das Eigentum ist ein Recht, welches sich aus Gesetzen, Verträgen und nötigenfalls Gerichtsbeschlüssen ergibt. Der Besitz, die Verfügungsgewalt ist eine Tatsache, deren Ausprägung rechtmäßig oder unrechtmäßig sein kann. Verleihe ich etwa ein Fahrrad, so gelangt es rechtmäßig in den Besitz eines anderen, während ich Eigentümer bleibe. Gibt der Entleiher das Fahrrad nicht wie vereinbart zurück, sondern unterschlägt es, wird sein Besitz unrechtmäßig.
Solche Begriffe und Unterscheidungen sind über Jahrhunderte gewachsen und haben sich bewährt. Nun ist jedoch die wunderbare Blockchaintechnologie angetreten, unser geachsenes Verständnis von Eigentum und Besitz zu zerreißen. Wie zu erwarten war, geht das in die Hose.
Ihr habt sicher die Geschichte von dem Programmierer gelesen, der ein Passwort vergessen hat. Dieses Passwort gehört zu einer verschlüsselten Festplatte, auf dieser Festplatte ist ein Bitcoin-Wallet gespeichert, an diesem Bitcoin-Wallet hängen quantisierte Blockchain-Ergänzungsprivilegien im Umfang von ungefähr 7.000 Bitcoin und bei den Preisen, zu denen solche Privilegien derzeit gehandelt werden, könnte man sie für ein mittleres Vermögen in echtem Geld verkaufen. Das ist blöd gelaufen und wenn etwas blöd läuft, kann man daraus lernen.
Unter den klassischen Schutzzielen Vertraulichkeit, Integrität und Verfügbarkeit wird letztere von Security-Laien gerne als Mauerblümchen behandelt. Oft ist Verfügbarkeit wie hier jedoch das wichtigste Schutzziel. Zwischen Verfügbarkeit und Vertraulichkeit muss man meistens abwägen, gerade wenn man Daten verschlüsselt, denn je sicherer die Verschlüsselung ist, desto schwieriger wird es, die Verfügbarkeit sicherzustellen. Ob und unter welchen Rahmenbedingungen Verschlüsselung zur Sicherheit beiträgt, muss man deshalb im Einzelfall anhand einer gründlichen Bedrohungs- und Risikoanalyse herausfinden.
In der von libertären Vorstellungen geprägten Blockchain-Welt ist sich jeder selbst der Nächste. Den Unterschied zwischen Besitz und Eigentum gibt es dort nicht, nur die Verfügungsgewalt über bestimmte Schlüssel („Wallets“). Wie beim guten alten Sparstrumpf unterm Kopfkissen muss jeder selbst für seine Sicherheit sorgen, ohne Unterstützung von Institutionen zu erhalten. Das ist im richtigen Leben anders, da kann man sein Bargeld zur Bank bringen und erhält dafür eine Anspruch auf Auszahlung. Unter Umständen kann man seinen Anspruch sogar noch nach einer Bankenpleite erfolgreich geltend machen, nämlich im Rahmen der Einlagensicherung. Im Vergleich zu einer Bank ist ein Bitcoin-Wallet sehr unbequem, weil es nur Besitz und kein davon unabhängiges Eigentum gibt.
Nicht nur muss man sich mit einem Bitcoin-Wallet ganz alleine um seine Sicherheit kümmern, man hat es dabei auch noch besonders schwer. Alles hängt am Wallet. Das muss vertraulich bleiben, denn wer Zugriff auf die geheimen Schlüssel bekommt, erhält die Verfügungsgewalt über die am Wallet hängenden Transaktionsprivilegien. Nebenbei braucht man auch noch eine sichere Ausführungsumgebung für Programme, um das sicherzustellen. Ein Wallet muss aber auch verfügbar bleiben, denn sonst kann man selbst nichts mehr damit anfangen. Das alles unter einen Hut zu bringen, ist schwer. Als Bankkunde hat man viel einfacher und bekommt nebenbei noch Service dazu, zum Beispiel Karten, mit denen man bezahlen kann.
Etwas weniger offensichtlich ist ein weiteres Problem. Bitcoin-Fans erklären oft und gerne, die Gesamtzahl der in der Bitcoin-Community herstellbaren quantisierten Transaktionsprivilegien sei von vornherein auf einen Maximalwert begrenzt. Dies ist jedoch nur die halbe Wahrheit, denn mit jedem verlorenen Wallet gehen, falls die Technik wie spezifiert funktioniert, die daran gebundenen quantisierte Transaktionsprivilegien unwiderruflich verloren. Das tatsächlich verfügbare Volumen an Transaktionsprivilegien („Bitcoins“) nimmt also auf lange Sicht ab, bis keine mehr übrig sind. Geld auf der Bank kann man zum Beispiel problemlos erben, wenn man über die erforderlichen Papiere verfügt. Bitcoin nicht, wenn der Erblasser sei Passwort nicht aufgeschrieben hat. Schreibt er es jedoch auf, riskiert er den Kontrollverlust.
Vielleicht ist es das beste, Bitcoin und alles davon Abgeleitete als Aktionskunst zu betrachten. Dann macht es wenigstens Sinn.
The below video gives an example of what some people would call a threat model. For all I can tell the video leaves out some detail but is otherwise accurate. Why does it appear hilarious or silly rather than reasonable?
As a joke the video exploits a mismatch between the sensible, even verifiable analysis it presents and the ridiculous assumptions it implies. If this attack scenario manifested itself it would play out pretty much as presented. However, the implied very narrow and specific mode of operation – firing cannon rounds at computers – does not correspond with the behavior of any reasonably imaginable threat agent. Any agent with the capability to deploy main battle tanks is facing a wide range of possible uses and targets. Shooting individual personal computers remains not only far from being one of the more profitable applications of this capability, but guarantees a negative return. The cost is high and destruction of specific, low-value items promises rather limited gains. There are also much cheaper methods to effect any desired condition on the specific type of target, including its complete destruction.
While the attack scenario is accurate, it lacks, therefore, a corresponding threat that would produce actual attacks. Such a threat would exist, for example, if the assumed target were other main battle tanks rather than personal computers.
Corona ändert alles. Jahrzehntelang stand die Deutsche Bahn unangefochten an der Spitze der deutschen Meckercharts, doch nun muss sie der Corona-Warn-App Platz machen:
Ob wir alle am Coronavirus oder aber an Corona-Apps sterben werden, bleibt offen.
Diese Woche war wenig los.
Der Sommer neigt sich dem Ende zu und langsam könnte eine Corona-Warn-App ihren Nutzen beweisen, aber anscheinend glaubt kaum noch jemand daran:
Nicht gehört habe ich in den letzten Tagen von den Bemühungen um eine europaweite Integration der nationalen Corona-Apps. Weiß man, wie es darum steht?
In Sachen Corona-App drehen wir uns zunehmend im Kreis:
Auf in die nächste Runde!
Corona-Apps füllen das diesjährige Sommerloch ganz gut aus:
Schönen Montag!
Die Infektionszahlen steigen, die Aktienkurse sinken und mit den Corona-Apps geht es langsam voran:
Habt Ihr alle Eure Klopapiervorräte aufgestockt?
Die Infektionszahlen steigen und mit ihnen die Aufgeregtheit:
Jetzt warten wir mal ab, wie sich die zweite Welle auf die App auswirkt. Habt Ihr alle noch genug Klopapier?
Auch diese Woche blieb es vergleichsweise ruhig.
Vielleicht gewöhnen wir uns jetzt einfach an die App?
Bis zum 5. Juli:
Thematisch passt es hier eigentlich nicht rein, aber vielleicht stolpert trotzdem jemand darüber, den es interessiert. Zurzeit läuft eine Crowdfunding-Kampagne mit dem Ziel, eine deutsche Übersetzung des Buchs „Pearls of Juggling“ von Anthony Trahair zu finanzieren. In diesem Buch geht es nicht ums Werfen und Fangen, um Tricks und Muster oder die verschiedenen Gegenstände, die sich jonglieren lassen, sondern um Themen wie Bewegung, Musik, Training, Kreativität und Auftritte. Erreicht die Kampagne ihr Ziel von 120 Vorbestellungen, erhaltet Ihr für 24 € ein signiertes Exemplar der Übersetzung.
Bei Interesse bitte hier entlang: https://www.ulule.com/pearls-of-juggling-in-deutsch/
Das Wetter ist zu schön, um das Wochenende vor dem Computer zu verbringen. Trotzdem hier eine Auswahl der Links rund um Corona-Apps und verwandte Themen, die sich während der vergangenen Woche angesammelt haben:
Bei so viel Text wünscht man sich fast eine Quarantäne, um genügend Zeit zum Lesen zu haben.
Auch diese Woche haben sich allerlei Meldungen und Artikel zum Thema Corona-App angesammelt:
Die deutsche App soll nach aktuellem Stand im Juni erscheinen. Das Thema wird uns also noch eine Weile begleiten.
Auch in der automatischen Kontaktverfolgung per Smartphone-App traut sich Großbritannien, einen eigenen Weg zu gehen. Dort beginnt gerade der Testbetrieb einer Corona-App, der eine zentrale Datenverarbeitung zugrunde liegt. Die Briten verfolgen damit in jeder Hinsicht das Gegenteil des deutschen Ansatzes: Während dort eine zentrale Lösung weitgehend einsatzreif ist, hat man hier gerade dezentral von vorne angefangen, nachdem das bereits laufende Projekt PEPP-PT mit seiner Entscheidung gegen eine streng dezentralisierte Lösung politisch in Ungnade gefallen war. Die hierzulande mitschwingenden paneuropäischen Großmachtphantasien fanden auf der Insel naturgemäß ohnehin keinen Raum.
Die Gretchenfrage: „Zentral oder dezentral?“ entstand als Artefakt einer öffentlichen Debatte, weil sie zu Positionierungen einlud, ohne Sachkenntnis zu verlangen. Den Anschein überragender Bedeutung erlangte sie zum einen durch die im Nachhinein ungeschickt wirkende Ankündigung von PEPP-PT, den technischen Datenschutz in den Mittelpunkt zu rücken, zum anderen durch das eigennützige Handeln einiger Beteiligter. Während PEPP-PT im Laufe seiner Entwicklungsarbeit offenbar das Problem und den Lösungsraum besser verstand und sich vom dezentralen Extrem verabschiedete, spitzten dreihundert Professoren die ohnehin zu enge Fokussierung auf technischen Datenschutz noch zu. Als ginge es darum, unter idealisierten Voraussetzungen zwischen zwei einander widersprechenden Hypothesen die richtigere auszuwählen, konstruierten sie ein Entweder-Oder zwischen zentral und dezentral und gaben sogleich ohne Experiment die Antwort, selbstverständlich müsse es dezentral sein. Unterdessen sprangen Apple und Google auf den bereits abfahrenden Zug auf und präsentieren sich seither so geschickt als Retter der Privatsphäre, dass sogar Margrethe Vestager darauf hereinfällt und galant darüber hinwegsieht, wie das Duopol seine Plattform-Macht ausspielt.
Welche Erfolgsaussichten die Kontaktverfolgung per Smartphone und Bluetooth insgesamt hat, bleibt unabhängig von der technischen Architektur vorerst unklar. Setzt man diese Idee jedoch um, und sei es nur als Experiment, sollte man sich dabei um die bestmögliche Lösung bemühen. Was eine Lösung gut oder weniger gut macht, bestimmt dabei nicht ein zentrales technisches Detail, sondern der reale Nutzen im Anwendungskontext.
Für zentrale Elemente wie in Großbritannien spricht einiges. Erstens ist eine komplett dezentrale Architektur ohnehin nicht realistisch. Zum einen braucht man selbst bei Datenspeicherung auf den Endgeräten irgendeine zentrale Instanz zur Nachrichtenverteilung und Koordination, wenn man zugleich jede Datensammlung anonym halten und nicht Adressen wie zum Beispiel Telefonnummer für die spätere Benachrichtigung speichern möchte. Zum anderen gehören zu den verwendeten Plattformen unvermeidlich zentrale Instanzen wie Appstores und Telemetrie. Ausgehend von einem Aluhut-Bedrohungsmodell können sich Nutzerinnen und Nutzer in solch einer Umgebung sowieso auf keine Eigenschaft einer App verlassen, denn jederzeit könnte eine neue Version automatisch installiert werden, die alles ganz anders macht.
Zweitens gehören Feedbackmechanismen heute zum Stand der Technik. Seit Software nicht mehr auf Datenträgern in Pappschachteln, sondern online vertrieben und auf vernetzten Geräten benutzt wird, haben Entwickler die Möglichkeit, Telemetriedaten aus der Software selbst sowie Nutzerfeedback unmittelbar zu erhalten und auszuwerten. Das erleichtert und beschleunigt die Fehleerkennung und -behebung sowie die Weiterentwicklung enorm und erlaubt sogar interaktive Experimente mit realen Benutzerinnen und Benutzern. Beim Einsatz einer noch wenig getesteten Technologie sind Feedbackmechanismen besonders wichtig, denn sehr wahrscheinlich erlebt man Überraschungen und muss unerwartete Probleme lösen. Eine letztlich experimentelle App im Zuge der Pandemiebekämpfung einfach herauszugeben und dann sich selbst zu überlassen, wäre grob fahrlässig, zumal über das neue Coronavirus noch zu wenig bekannt ist.
Drittens kollidieren Anforderungen aus dem Anwendungskontext mit extremistischen Datenschutzkonzepten. Die Kontaktverfolgung ist kein belang- und folgenloses Smartphonespiel wie Pokémon Go, sondern sie soll reale Konsequenzen haben. Beim herkömmlichen Vorgehen gehören zu diesen Konsequenzen Quarantäneanordnungen der Gesundheitsämter. Solche Anordnungen benötigen einen Adressaten und im Rechtsstaat müssen sie auch begründet sein, um ggf. einer gerichtlichen Prüfung standzuhalten. Im Sozialstaat ist darüber hinaus geregelt, wer welchen Teil der Lasten trägt und wie beispielsweise eine quarantänebedingte Arbeitsunfähigkeit abgefedert wird. Die Verfechter eines dezentral-anonymen Ansatzes haben bis heute keine Vorschläge unterbreitet, wie das eine oder das andere funktionieren soll. Weder können die Gesundheitsämter damit irgend etwas durchsetzen, noch erhalten Betroffene eine ausreichende Begründung oder gar eine Bescheinigung zur Vorlage bei Vertragspartnern und öffentlichen Stellen.
Viertens drängen sich Nebenfunktionen einer für den Masseneinsatz bestimmten App geradezu auf. Eine offensichtliche ist die Erfassung statistischer Daten, um den Gesundheitsbehörden ein klareres Bild des Pandemieverlaufs zu vermitteln. Dazu muss man doch wieder Daten an eine zentrale Stelle übermitteln und es kann gut sein, dass sich dann aus einem integrierten Ansatz schnell Synergieeffekte ergeben.
In Großbritannien hat man sich offenbar mit den Anforderungen der Anwendung auseinandergesetzt, während Deutschland kontextarm über Technik stritt. Dort möchte man zum Beispiel besonders gute Virenverteiler anonym ausfindig machen und darauf Risikoeinschätzungen stützen. Ob das funktionieren kann, wird sich zeigen; um eine an der Oberfläche nicht offensichtliche Idee handelt es sich allemal. Ein zentralerer Ansatz ist auch nicht automatisch ein Zeichen für Nachlässigkeit oder Primitivität der Implementierung, er kann für alle realistischen Belange einen gleichermaßen effektiven Datenschutz gewähren. Nur eines haben die Briten ebenso versäumt wie die Bundesregierung: die entwickelte Technik rechtlich und organisatorisch mit vertrauensbildenden Maßnahmen zu flankieren. Ich wünsche ihnen dennoch viel Erfolg. Schneller fertig werden sie schon mal, wie auch einige andere Länder, die dem dezentralen Extremismus eine Absage erteilten.
Privacy – or security or any other desirable, ethereal property – by design sounds like a great thing to do. Alas, design is complicated and hard to guide or control as a process. One common misunderstanding has become obvious in current efforts to develop and deploy contact tracing technology contributing to epidemic control. Some of these efforts such as DP^3T, TCN, or Apple’s & Google’s announcement promote privacy to the top of their list of objectives and requirements. This is wrong. It would be appropriate in an R&D project developing experimental technology, but contact tracing is an actual, real-world application and must fulfill real-world requirements. Premature optimization for technical privacy protection does not help its cause.
First and foremost, an application needs to support a basic set of use cases and provide the necessary functions in such a way that the overall approach makes sense as a solution of the given problem(s). For contact tracing, essential use cases include:
In addition, any large-scale application of contract tracing needs to support:
Each use case entails requirements. Contact identification must be sufficiently reliable and comprehensive; it must also take place quickly after an infection has been detected. Contact listing needs some form of risk assessment, a method to notify contacts, and a way to justify mandatory quarantine requests. Contact follow-up needs some idea how and when to interact with listed contacts. Underlying the whole design must be some conception of which contacts matter, what an identified contact implies, what to do with or require from identified contact persons, and what to achieve through contact tracing. There needs to be some definition of success and failure for the system and individual cases, and some monitoring of how well the system operates. One also has to think about possible abuses and misuses of the system such as evasion, manipulation, or exploitation, and find ways to prevent them or to deal with them when they occur.
Such questions are to be answered in the high-level design of a contact tracing system. They can and should be pondered at the level of paper prototypes, forcing developers to get specific but allowing quick modification and user testing. Technology has to be considered at this point primarily as a constraint: What is realistically possible or available and would the design be feasible to implement? However, some fundamental design decisions have to be made at this level after evaluating alternatives, for example, which parts of the system to automate and which ones to leave to humans, or which technologies, platforms, and devices to consider and use.
Like any design process, this high-level system design may take any number of iterations before converging toward something that might work when implemented. New questions will likely come up in the process. If, for example, the system is to leave tracing to humans, how much time can they spend per case, how many of them will be needed, how will they work, and which types of data and support would really help them?
Secondary requirements like performance or privacy can and should already be considered at this stage. Privacy by design means just that, to consider privacy protection as dimensions of the design spaces from the beginning on. However, privacy is a dependent design dimension and like all other requirements it is subject to trade-offs. Dependent means that any design decision can affect the privacy properties of a system. One cannot delegate privacy to a system component or function that would take care of it comprehensively regardless of the design of any other aspect of the system. Trade-offs occur when once has to choose between design alternatives; each option will likely have some advantages over the others but also some disadvantages, so that one has to compromise and keep a balance.
Misunderstanding privacy by design as privacy technology über alles, demonstrated by current proposals for privacy-preserving contact tracing, is a recipe for disaster. Starting with perfect technical privacy protection as the primary requirement constitutes a premature optimization that de-prioritizes all other requirements and design dimensions, delays important design decisions while arbitrarily constraining them without impact assessment, and prevents well-considered trade-offs from being made. The most likely result is a system that performs well at most in the privacy dimension, reflecting the priorities of its designers.
As a symptom, none of the proposals for privacy-preserving contact tracing has yet answered question like the following: How does it assure the reliability of the data it collects or produces? Which failure modes and error rates does it produce? How is the system to be monitored for problems and abuses? In which institutional framework is it designed to operate? How does it distribute responsibilities between involved parties? How are outputs of the system to be interpreted and used in the real world, which consequences should they have and which ones are not desirable? How can its operation become transparent for its users? Should participation be mandatory or voluntary and how can the design be optimized for either case? If participation is mandatory, how would this be enforced, how can the system be made universally accessible for everyone, and how may people evade it? If voluntary, which incentives does the system create and which features let users trust or distrust the system? Such questions need to be discussed and addressed long before the technical minutiae of data protection.
Placing technical privacy protection in the center of attention can make sense in a research project, where one develops new technology to evaluate its properties and capabilities. The stakes are low in such a project, where the results are prototypes and research papers. Developing a real-world system, especially one to be used at the intended scale of contact tracing apps, requires a broader perspective and comprehensive requirements analysis.
P.S. (2020-04-18): Government Digital Services of Singapore with their TraceTogether app apparently got their requirements analysis and design process right:
One thing that sets TraceTogether apart from most private efforts to build a Bluetooth contact tracer, is that we have been working closely with the public health authorities from day 1. (…) The team has shadowed actual real-life contact tracers in order to empathise with their challenges.
P.S. (2020-04-19): The closest to a requirements document I have seen so far is this: Mobile applications to support contact tracing in the EU’s fight against COVID-19, Common EU Toolbox for Member States (via).
P.S. (2020-04-22): The Ada Lovelace Institute published a quick evidence review report titled: Exit through the App Store? A rapid evidence review on the technical considerations and societal implications of using technology to transition from the COVID-19 crisis, which makes a number of reasonable recommendations.
Another video clip from Thames TV with a security theme, this time reporting on the insecurity of car locks and drivers’ failure to lock their cars in the first place:
Seit inzwischen zwei Jahrzehnten fordert man uns immer wieder auf, E-Mail-Anhänge vorsichtig zu öffnen. Wie das geht, zeigt der folgende kurze Film:
There will be another International Workshop on Secure Software Engineering in DevOps and Agile Development (SecSE) this year. The upcoming edition is going to take place in Dublin in conjunction with the Cyber Security 2020 conference (June 15-17 2020). Please submit your papers until 6 February 2020 – three weeks to go! – and spead the word.
This clip from 1983 allows us a glimpse into the history of computer crime. Much of what is being said still sounds familar today, doesn’t it?