In diesem Kapitel werden Sie sich in die Lage eines Security Analyst und eines Angreifers oder einer Angreiferin versetzen. Bei proaktiven Datenschutz- und Sicherheitsmaßnahmen verfolgen Sie einen zyklischen Ansatz, bei dem Sie Zeit damit verbringen, sich potenzielle Bedrohungen und Angriffe vorzustellen und dann zu ermitteln, wie Sie sich vor ihnen schützen können. Sicherheit kann jedoch immer nur für einen begrenzten Zeitraum gewährleistet werden, da sich die Bedrohungen weiterentwickeln und sich Ihr System verändert, d.h., es handelt sich um einen fortlaufenden Prozess.
Nachdem Sie die ersten Schutz- und Gegenmaßnahmen getroffen haben, stehen in der Regel noch weitere Schritte an. Da sich die Sicherheit ständig weiterentwickelt und neue Bedrohungen auftauchen, bietet Ihnen dieses Kapitel eine gute Einführung in die Thematik. Sie sollten sich jedoch stets auf dem Laufenden halten und Forschungsergebnisse, Trends und neue Bedrohungen im Auge behalten.
Um wie ein Security Analyst zu denken, ist es wichtig zu wissen, was möglich und was wahrscheinlich ist und wie man sich am besten proaktiv auf potenzielle Angriffe vorbereitet, statt reaktiv zu handeln. In diesem Abschnitt werden Sie bekannte Angriffsvektoren analysieren, bei denen es sowohl Forschern als auch neugierigen Menschen, die sich mit Daten befassen, gelungen ist, sensible Informationen zu enthüllen, die eigentlich geheim bleiben sollten. Nachdem Sie sich näher mit diesen Angriffen befasst haben, werden Sie die gängigsten Methoden zur Offenlegung sensibler Daten besser verstehen und in der Lage sein, Ihre Daten vor diesen Angriffen zu schützen.
Wahrscheinlich gehen Sie davon aus, dass Ihr Onlineverhalten ziemlich normal ist und Ihnen nicht persönlich zugeordnet werden kann. Auch wenn einige Ihrer Verhaltensweisen eher alltäglich sind, etwa eine Gmail-Adresse zu haben, einen beliebten Beitrag zu liken oder ein beliebtes Video anzuschauen, dürfte es dennoch bestimmte Zusammenhänge geben, die Sie eindeutig identifizieren.1 Ihre Interessen, Ihr Standort, Ihre demografischen Daten und die Art und Weise, wie Sie mit der Welt und anderen interagieren, machen Sie unverwechselbar, insbesondere über einen längeren Zeitraum betrachtet. Sehen wir uns an, wie dies möglich ist, indem wir einen Angriff auf den Netflix-Prize-Datensatz untersuchen.
Im Jahr 2007 veranstaltete Netflix einen Wettbewerb, den sogenannten Netflix Prize, bei dem der beste Empfehlungsalgorithmus zur Vorhersage von Nutzerbewertungen gesucht wurde. Im Rahmen des Wettbewerbs gab Netflix eine »zufällige« Stichprobe von Nutzerdaten und -bewertungen weiter, die »anonymisiert« waren.2 Der Datensatz enthielt 100.480.507 Einträge von 480.189 Nutzerinnen und Nutzern. Die Daten wurden geschützt, indem »Identifikatoren« entfernt und durch pseudonyme Identifikationsnummern ersetzt wurden, sodass die Teilnehmenden anhand dieser individuellen Identifikationsnummern einsehen konnten, welche Inhalte ein bestimmter Nutzer bewertet hatte.
Die beiden mit dem Thema Datensicherheit vertrauten Forscher Arvind Narayanan und Vitaly Shmatikov von der University of Texas, Austin, fragten sich, ob die Personen in diesem Datensatz de-anonymisiert (bzw. re-identifiziert) werden könnten. Sie begannen damit, die Nutzer des Datensatzes auszuwerten und diejenigen zu identifizieren, die in der Stichprobe überrepräsentiert waren.3
Anschließend konnten sie die aktivsten Nutzer des Datensatzes mit einem Datensatz abgleichen, den sie durch Scraping von der bekannten Filmwebseite IMDB gewonnen hatten. Sie beschränkten ihre Suche auf einen kurzen Datumsbereich, der mit den Daten des Netflix-Datensatzes übereinstimmte. Auf diese Weise konnten sie ähnliche Bewertungen für denselben Inhalt finden und feststellen, welche Personen im Netflix-Datensatz auch Profile auf IMDB hatten, da ihre Bewertungen übereinstimmten.
Abbildung 4-1 gibt Aufschluss darüber, wie hoch die Wahrscheinlichkeit einer Verknüpfung (engl. Linkage) bzw. einer Re-Identifizierung auf der Grundlage dieser Technik war. Die in der Legende angegebenen Zeitspannen beziehen sich auf den Zeitraum (in Tagen), der jeweils zur Verknüpfung der Bewertungen im Netflix-Datensatz mit den Online-Bewertungen angesetzt wurde. Für jeden der Bereiche auf der x-Achse können Sie die Wahrscheinlichkeit ablesen, eine bestimmte Person auf Basis der Anzahl der online gefundenen Bewertungen zu finden, z.B. wenn drei von vier Bewertungen, die im Datensatz waren, auch online gefunden werden konnten.
Abbildung 4-1: Wahrscheinlichkeiten für eine erfolgreiche Reconstruction Attack auf den Netflix-Prize-Datensatz
Einige Nutzer ändern auf jeder Website ihren Nutzernamen oder verwenden Pseudonyme, die nur schwer mit ihrer echten Identität in Verbindung gebracht werden können. Andere wiederum nutzen wohlbekannte Muster, zum Teil sogar ihre echten Namen. Dadurch, dass ihr IMDB-Profil oder ihr Nutzername zusätzliche Informationen über sie preisgibt (z.B. einen Vornamen, einen Ort, oder sie haben noch andere Profile, die weitere Informationen enthalten), kann ein Angreifer diese Person relativ problemlos identifizieren.
Sie denken jetzt vielleicht: »Ja, und? Sie haben die Filme öffentlich bewertet, warum sollte ich mich um ihre Privatsphäre sorgen?« Dafür gibt es einige Gründe. Erstens sind die meisten Benutzer nicht in der Lage, das eigene Risiko in Bezug auf ihre Privatsphäre richtig einzuschätzen. Das bedeutet, dass sie ihr Risiko, bestimmte Inhalte in einem öffentlichen Forum oder einem anderen Dienst zu veröffentlichen, möglicherweise stark unterschätzen. Es kann auch sein, dass sie einige der Videos, die sie privat auf Netflix angesehen haben, gar nicht gepostet haben, diese nun aber der Öffentlichkeit zugänglich waren, weil Netflix diese Bewertungen veröffentlicht hat. Wie Sie aus der Einleitung über die Arbeit von Helen Nissenbaum und danah boyd wissen, kaschiert die Technologie den Kontext und die Wahlmöglichkeiten der Nutzer, sodass sie oft unsicher sind bzw. ihnen unklar ist, welches Risiko sie eingehen und wie sie die Kontrolle über ihre eigene Privatsphäre behalten können. Eine absolutistische Sichtweise würde es erfordern, niemals etwas öffentlich zu posten, dafür aber in Kauf zu nehmen, dass die Menschen den Nutzen und die Freude an der Technologie verlieren. Auch wenn dies die einzig sichere bzw. private Option ist, kann sie deshalb nur zum Scheitern verurteilt sein.
Zweitens können Nutzerinnen und Nutzer nicht vorhersehen, ob ihre Daten in Zukunft veröffentlicht werden oder ob es zu einem Datenleck kommt und welche Auswirkungen dies auf frühere Entscheidungen hat. Wenn die Nutzer nicht in einem Land wie der EU leben, in dem sie das Recht auf Vergessenwerden haben oder die Löschung ihrer Daten verlangen können, bleiben viele ihrer Onlineaktivitäten auf unbestimmte Zeit gespeichert. In einigen Fällen sind sich die Nutzer nicht darüber bewusst, dass ihre Daten öffentlich zugänglich sind, z.B. wenn die Website kein Privacy by Design verwendet und die Beiträge daher standardmäßig für jeden sichtbar sind. In manchen Fällen werden die Daten illegal über eine Sicherheitslücke gewonnen oder als sogenannte Walled-Garden-Daten, die ohne Zustimmung zu Zwecken des Weiterverkaufs oder zu anderweitiger Verwendung erhoben werden (https://oreil.ly/NRHq-). Zudem werden die Nutzer manchmal dazu verpflichtet, ihre Daten zur Verfügung zu stellen, z.B. für Gesundheitsdienstleister, für eine Regierung oder am Arbeitsplatz. Solange keine Einwilligung zusammen mit den Daten eingeholt wird, kann niemand wissen, unter welchen Bedingungen die Daten erhoben oder veröffentlicht werden.
Nicht zuletzt ist Ihre Verantwortung – als der- oder diejenige, der oder die über die Daten verfügt – vergleichbar mit der Verantwortung derjenigen, die mit dem Bau öffentlicher Infrastrukturen betraut sind. Sie müssen Vorkehrungen treffen, um alle zu schützen, nicht nur diejenigen, die am vorsichtigsten sind. Wenn Sie das Eigentum an Daten von Einzelpersonen übernehmen, ist es Ihre Pflicht, verantwortungsvolle Entscheidungen zu treffen. Dazu gehört auch der Schutz aller Nutzer, selbst derjenigen, die sich im öffentlichen Raum aktiv beteiligen. Das trägt auch dazu bei, dass im Internet und in anderen öffentlichen Räumen ein gemeinschaftliches Miteinander gepflegt wird.
Wer diese Arten von Angriffen ganz allgemein betrachtet, kann herausfinden, wie er sich vor ihnen schützen kann, wenn er Daten veröffentlicht. Der Netflix-Datensatz ist ein gutes Beispiel dafür, wie wirkungsvoll es sein kann, Daten miteinander zu verknüpfen (Linkage Attack) oder Individuen aufgrund ihrer individuellen Charakteristika zu identifizieren (Singling Out Attack). Beide Formen stellen häufig vorkommende Angriffsvektoren dar, die Sie kennen und vor denen Sie sich schützen sollten.
Bei Linkage Attacks wird mehr als eine Datenquelle verwendet, und diese werden miteinander verknüpft, um Personen zu re-identifizieren oder um an mehr Informationen zu gelangen und somit Personen identifizieren zu können. In der Regel sind Linkage Attacks erfolgreich, wenn die Angreifer über eine zusätzliche Datenquelle verfügen, die sich leicht mit einem anderen Datensatz in Verbindung bringen lässt, so wie es beim Netflix Prize und dem IMDB-Datensatz der Fall war. Was die möglichen verfügbaren Datensätze angeht, müssen Sie sowohl private als auch öffentlich zugängliche Datensätze in Betracht ziehen. Dazu können – oder besser sollten – auch Datenbanken gehören, von denen Sie wissen, dass sie in letzter Zeit oder in der Vergangenheit angegriffen worden sind.
Ein Ansatz, um einzuschätzen, ob es zu einer Linkage Attack kommen könnte, besteht darin, aktiv nach potenziellen Datenquellen zu suchen, die andere in Verbindung mit den Daten verwenden könnten, die Sie der Öffentlichkeit zugänglich machen möchten. Gibt es öffentliche Webseiten, die eingesehen oder »gescrapt« werden können und die es einer Person ermöglichen, auf einfache Weise an Informationen zu gelangen, die sie für eine Linkage Attack verwenden könnten? Gibt es frei zugängliche Datenquellen, die leicht mit den von Ihnen bereitgestellten Daten verknüpft werden könnten? Oder gab es in letzter Zeit größere Datenlecks, bei denen Daten möglicherweise dazu missbraucht wurden, Personen zu verknüpfen und sie dadurch zu kompromittieren?
Wie Sie bereits im Zusammenhang mit Differential Privacy in Kapitel 2 erfahren haben, ist es nicht nur mühsam, sich alle denkbaren Zusatzinformationen vorzustellen, sondern auch wenig erfolgversprechend. Sie werden leider nie genau wissen, welche Daten ein Angreifer kennt oder welche ihm zur Verfügung stehen. Allerdings können Sie selbst bestimmen, welche Daten Sie herausgeben und an wen!
Ein anderer Ansatz besteht darin, sicherzustellen, dass alle Daten, die der Öffentlichkeit zugänglich gemacht werden, hinsichtlich des Datenschutzes dem neuesten Stand der Technik unterliegen, z.B. Differential Privacy. Sie können auch festlegen, dass dies für alle Daten erforderlich ist, die an Dritte oder an Partner weitergegeben werden, oder sogar für Daten, die innerhalb Ihres Unternehmens weitergegeben werden. Dadurch können Sie, wie Sie in Kapitel 2 gelernt haben, ebenfalls verhindern, dass Zusatzinformationen genutzt werden können, die erst zu einem späteren Zeitpunkt veröffentlicht werden.
Eine Möglichkeit, festzustellen, ob Ihre Daten leicht zu verknüpfen sind, besteht darin, die Einzigartigkeit Ihres Datensatzes und der Datenpunkte selbst zu bestimmen. Mithilfe einer Kardinalitätsanalyse, wie sie in Googles KHyperLogLog-Forschungsartikel (https://oreil.ly/MSc1L) verwendet wird, können Sie feststellen, ob Ihre Daten gut verknüpfbar sind.
Teil des Problems ist, dass Datensätze oft sehr umfangreich sind. Wenn riesige Datenmengen erhoben werden, die nicht ordnungsgemäß als personenbezogene Daten gekennzeichnet sind, oder wenn Governance und Dokumentation nicht ordnungsgemäß umgesetzt wurden, ist die Privatsphäre der Betroffenen ernsthaft in Gefahr. Wie können Sie feststellen, welche Daten re-identifizierend sind?
Hierbei kann Ihnen die Kardinalitätsanalyse behilflich sein. Wenn Ihnen ein großer Datensatz vorliegt, sind es die vielen unverwechselbaren Kombinationen dieser Datenpunkte, die Informationen über eine Person preisgeben können, wie z.B. die Gerätekennung, der Standort, der Webauftritt oder der bevorzugte Musikdienst. Diese zahlreichen kleinen Punkte sind vordergründig nicht sichtbar, was es schwierig macht, die einzelnen Punkte als einzigartig zu erkennen.
Angenommen, Sie hätten eine ganze Reihe verschiedener Variablen in Ihren Logdateien oder in Datensätzen, die zwar personenbezogene Informationen enthalten, aber nicht unbedingt identifizierend sind. Sie möchten untersuchen, ob diese Daten latente Datenschutzrisiken bergen, indem Sie feststellen, ob die Variablen selbst oder Kombinationen davon identifizierend sind. Bei den von den Forschern verwendeten Variablen handelte es sich jedoch um solche Merkmale wie Browseragenten, protokollierte Anwendungseinstellungen und andere Anwendungs- oder Browserdetails.
Sie interessieren sich dafür, ob es Identifikatoren gibt, die eindeutig zugeordnet werden können, und welche Kombinationen von Identifikatoren wahrscheinlich oder sicher eindeutig zugeordnet werden können. Dazu haben die Forscher eine zweiteilige Datenstruktur entwickelt, die zwei unterschiedliche Hashing-Mechanismen miteinander kombiniert. Der erste ist ein K-Min-Hashing-Mechanismus, der die Wahrscheinlichkeitsdichte des Datensatzes und damit seine Einzigartigkeit anhand der Distanz zwischen den K kleinsten Hashwerten bestimmt. Gleichzeitig werden die Variablen und die zugehörigen eindeutig zuordenbaren Nutzerkennungen einem HyperLogLog- (https://oreil.ly/mcvxp) bzw. einem HyperLogLog++-Mechanismus übergeben, mit denen die Kardinalität auf sehr effiziente Weise geschätzt wird. Durch die Kombination dieser beiden leistungsstarken Mechanismen konnten die Forscher eine schnelle und effiziente Methode entwickeln, mit der Variablen, die nicht sehr eindeutig waren, und Variablen, die viele Nutzer gemeinsam hatten, schnell ausgeschlossen werden können.4
Darüber hinaus können KHyperLogLog-Datenstrukturen miteinander kombiniert werden. Dadurch lässt sich prüfen, inwieweit verschiedene Kombinationen von Variablen die Privatsphäre des Nutzers gefährden. Mit dieser zweistufigen Struktur können sie auch dazu verwendet werden, echte PII-Daten mit diesen »pseudonymisierten« Daten zu vergleichen und zu überprüfen, ob einige Variablenkombinationen als eindeutige Identifikatoren fungieren. Bei Google konnten im Rahmen der eigenen Verwendung des Algorithmus Mängel in Bezug auf den Datenschutz festgestellt und behoben werden, z.B. wurde die Einstellung des Lautstärkereglers des Mobiltelefons mit einer zu hohen Genauigkeit gespeichert.
Auf der Grundlage dieser Informationen können Sie entweder die Empfehlung aussprechen, dass die unterschiedlichen Quellen mit diesen einzigartigen Kombinationen von Variablen niemals kombiniert werden sollten, oder Sie können geeignete Datenschutz- und Sicherheitsvorkehrungen treffen, um das Risiko von Re-Identification Attacks oder fälschlichen Verknüpfungen zu verringern. Das ist insbesondere für die automatisierte Datenverarbeitung oder das Training großer Deep-Learning-Modelle relevant, bei denen die Verknüpfungen ohne menschliches Zutun erkannt und von Algorithmen oder anderen automatischen Systemen genutzt werden könnten.
Diese Form der Kardinalitätsanalyse hilft Ihnen ebenfalls, um festzustellen, wie wahrscheinlich es ist, dass ein bestimmter Nutzer herausgegriffen bzw. ausgesondert werden kann (engl. singling out). Betrachten wir nun einmal, welche Art von Angriffen möglich sind, wenn eine Person in einer bestimmten Gruppe tatsächlich leicht zu identifizieren ist.
Singling Out Attacks beruhen darauf, dass eine Person aus einem veröffentlichten Datensatz ausgesondert (engl. singling out) wird und dann versucht wird, weitere Informationen über diese Person mithilfe desselben Datensatzes oder über andere Quellen zu sammeln. Diese Angriffe können auch in umgekehrter Richtung durchgeführt werden, indem Informationen über eine Person in einen veröffentlichten Datensatz eingebracht werden und versucht wird, abzuleiten, ob diese Person enthalten ist und identifiziert werden kann.
Gehen wir jeweils ein Beispiel für beide Möglichkeiten durch.
Angenommen, Sie sind ein Data Scientist, der eine Datenbank abfragt, die auf simple Weise anonymisiert wurde. Sie möchten das Gehalt einer bestimmten Frau herausfinden, von der Sie wissen, dass sie die einzige Frau im Unternehmen ist, die älter als 60 Jahre ist. Wenn die Datenbank es Ihnen erlaubt, »aggregierte« Antworten bzw. Ergebnisse zu erhalten, ohne dass diese zusätzlich durch Differential Privacy geschützt werden, können Sie eine Reihe von Abfragen durchführen, die auf diese Frau abzielen, und dadurch ihr Gehalt aufdecken. Dafür könnten Sie zum Beispiel das Gehalt aller Frauen, die älter als 60 Jahre alt sind, abfragen und würden somit direkt ihr Gehalt offenlegen. Wenn die Datenbank besser geschützt ist, aber immer noch keinen Schutz gegen Singling Out Attacks bietet, könnten Sie zwei Abfragen durchführen – eine, um die Gehälter aller Arbeitnehmerinnen und Arbeitnehmer über 60 Jahre zu erhalten, und eine, um die Gehälter aller männlichen Arbeitnehmer über 60 Jahre zu erhalten – und ihr Gehalt anhand der Differenz zwischen den beiden Abfragen ermitteln.
Eine weiteres echtes Beispiel ist die Re-Identifizierung von Prominenten im Taxi-Datensatz von New York City. Der Datensatz wurde im Jahr 2014 im Rahmen eines Freedom-of-Information-Act-(FOIA-) (https://www.foia.gov) Antrags der Öffentlichkeit zugänglich gemacht. Ein Data Scientist stellte in dem Datensatz ein seltsames Muster fest, bei dem sich die pseudonyme Kennung mehrerer Taximarken (sogenannte Taxi-Medaillons) wiederholte und manchmal dasselbe Taxi zur selben Zeit an verschiedenen Orten angezeigt wurde. Das ist natürlich nicht möglich, doch es lieferte einen wichtigen Anhaltspunkt. Der Data Scientist hat daraus geschlossen, dass es sich bei diesem Wert in Wirklichkeit um einen Nullwert handelte, bei dem die Angabe des Medaillons fehlte.
Dank dieser Entdeckung war der Data Scientist mittels Reverse Engineering in der Lage, den verwendeten Hashing-Mechanismus zu entschlüsseln (was einfach war, da kein Salt hinzugefügt wurde)!5 Die übrigen Daten konnte er mithilfe einer Rainbow-Tabelle (https://oreil.ly/tzFh9) problemlos wiederherstellen.
Nachdem der Datensatz veröffentlicht worden war, wurde er innerhalb kürzester Zeit mit Paparazzi-Fotos von Prominenten verlinkt, die aus Taxis ausstiegen, da die Kennung des Medaillons auf vielen Fahrzeugteilen des Taxis sichtbar sein muss – den Türen, dem Heck, dem Nummernschild usw. In einem Artikel des Gawker-Magazins (https://oreil.ly/yCp2u) wurde enthüllt, wie viel Trinkgeld diverse Prominente gegeben haben, da die Daten nun leicht verknüpfbar waren. Das ist ein hervorragendes Beispiel dafür, wie eine schlecht anonymisierte Datenquelle mit zusätzlichen Informationen angereichert werden kann, um eine Linkage Attack oder auch eine Singling Out Attack durchzuführen. Während Ihnen die Privatsphäre von Prominenten vielleicht nicht allzu wichtig ist, bedeutet dies aber gleichzeitig, dass auch jede andere Person, die aus einem Taxi steigt, auf einem Foto identifizierbar ist. Inwieweit die Privatsphäre gewahrt bleibt, hängt im Allgemeinen davon ab, wie gut sie geschützt ist. Lässt man es zu, dass die Privatsphäre einzelner Personen (hier: Prominenter) verletzt wird, wird auch der Schutz der Privatsphäre für alle untergraben.
Singling Out und Linkage Attacks sind jedoch nicht die einzigen Arten von Angriffen auf die Privatsphäre. Sensible Informationen gibt es überall, und selbst wenn Sie aggregierte Daten mit einem gewissen Schutz veröffentlichen, können Sie versehentlich sensible Details preisgeben. Gehen wir nun also der Frage nach, wie bei aggregierten Daten Informationen preisgegeben werden könnten.
Im Jahr 2018 veröffentlichte die Sport-Tracking-App Strava eine weltweite Aktivitätskarte. Sie ermöglichte Nutzerinnen und Nutzern sowie auch sonstigen Interessierten, verschiedene sportliche Aktivitäten (Joggen, Radfahren, Wandern) aus der ganzen Welt nachzuvollziehen. Gleichzeitig rühmte sich Strava damit, dass die Daten anonymisiert würden. Es dauerte weniger als einen Tag, bis interessante, weniger bevölkerte Gebiete auf der Karte in den sozialen Medien besondere Beachtung fanden. Während Strava in Nordamerika sowie West- und Mitteleuropa eine große Anwenderbasis aufwies, gab es in Afrika und dem Nahen Osten nicht sonderlich viele Nutzer. Dennoch gab es auch dort Routen, die sehr aktiv genutzt wurden. Bei näherer Betrachtung dieser Routen wurden die Umrisse von bisher nicht ausgewiesenen Militärstützpunkten der USA und der NATO sichtbar, die eigentlich geheim bleiben sollten.
Abbildung 4-2 zeigt einen Screenshot von Strava, in dem ein US-Militärstützpunkt in Afghanistan zu sehen ist. Dieser und ähnliche Stützpunkte wurden in den Tagen und Wochen nach der Veröffentlichung der globalen Heatmap aufgedeckt, was in einem Twitter-Thread eines sicherheitsbewussten Twitter-Nutzers (@Nrg8000) (https://oreil.ly/ZFX8h) und mehreren Antworten hervorgehoben wurde. An dem Tag, an dem die Karte veröffentlicht wurde, machten verschiedene Berichte darauf aufmerksam, dass die Ausreißer – d.h. die Daten von Strava-Nutzern in Afrika und dem Nahen Osten – militärische Geheimnisse von mehr als einem Staat enthüllt hatten.
Abbildung 4-2: Die Militärbasis Bagram in der Strava-App
Dieser Fall zeigt eindrucksvoll, wie sensible Daten versehentlich mit anderen sensiblen Daten verknüpft werden können. Hier sind über persönliche Daten von Soldaten der USA und der NATO vertrauliche Informationen über Militärbasen und Operationen durchgesickert. Es zeigt auch, wie die Privatsphäre des Einzelnen (Individual Privacy) mit der Privatsphäre einer Personengruppe (Group Privacy) zusammenhängt. Im vorliegenden Beispiel führt die Exposition der individuellen Privatsphäre in Kombination mit der Kenntnis der Gruppenzugehörigkeit zur Preisgabe zusätzlicher Informationen (in diesem Fall sogar vertraulicher Informationen).
Individual Privacy, wie sie in Kapitel 2 besprochen wurde, ermöglicht Ihnen, den Schutz der Privatsphäre für eine bestimmte Person zu garantieren. Differential Privacy quantifiziert diese Garantien und hält sie innerhalb eines bestimmten Bereichs, den Sie festlegen und überprüfen können.
Group Privacy bezieht sich auf die Fähigkeit, die Privatsphäre für eine größere Gruppe zu gewährleisten. Dies könnte ähnlich sein wie die Erweiterung der Privacy Unit unter Differential-Privacy-Bedingungen, sodass sie eine größere Anzahl von Personen abdeckt (wie einen Haushalt bei einer Volkszählung). Aber wie Sie sich vielleicht vorstellen können, wäre es unglaublich schwierig, alle Mitglieder einer bestimmten Berufsgruppe, eines bestimmten Geschlechts oder einer bestimmten ethnischen Herkunft zu erfassen, wenn diese einen großen Teil der Bevölkerung ausmachen.
Selbst wenn Sie den Schutz der Privatsphäre für den Einzelnen gewährleisten können, kommt es häufig vor, dass Informationen über Gruppen »durchsickern«. In gewisser Weise ist das großartig, denn das ist die Stärke von Data Science und Statistik! Daten zu untersuchen, sie über Gruppen hinweg zu vergleichen sowie Schlussfolgerungen zu ziehen – und dabei gleichzeitig noch strenge Privacy-Garantien für den Einzelnen zu wahren –, ist äußerst nutzbringend.
Das Strava-Beispiel zeigt, wie eine Ballung von Nutzerinnen und Nutzern an einem bestimmten sensiblen Ort vertrauliche Informationen offenlegen kann. Aber es gibt auch andere Beispiele, bei denen Daten, die auf freiwillige und datenschutzfreundliche Weise erhoben wurden, gruppenspezifische Informationen enthüllten. Im Zusammenhang mit einem Rechtsstreit gegen Google bezüglich der Unterbezahlung von Frauen und Personen mit nicht binärer Geschlechtsidentität im Vergleich zu ihren männlichen Kollegen wurden intern Daten über ein Google-Formular erhoben (https://oreil.ly/VpIxZ). In dem Formular wurde um die freiwillige Angabe der sogenannten Engineering Grade (ein Einstufungssystem bei Google), des Geschlechts sowie des Gehalts und der zusätzlichen Boni, die im Vorjahr gezahlt wurden, gebeten.6
Abbildung 4-3: Googles freiwillige Datenerhebung offenbart bei aggregierter Betrachtung ein Gehaltsgefälle.
Bei aggregierter Betrachtung geht aus diesen Daten ein deutliches Gehaltsgefälle zwischen männlichen Angestellten und ihren weiblichen Kolleginnen sowie den Angehörigen geschlechtsspezifischer Minderheiten bei den verschiedenen Einstufungen hervor. Abbildung 4-3 bietet Ihnen ein genaues Bild davon, wie groß diese Ungleichheit ausgefallen ist, und kam vor Gericht als Beweismittel zum Einsatz. Auf jeder Stufe, mit Ausnahme von Level II, wurden Frauen und Angehörige geschlechtsspezifischer Minderheiten schlechter bezahlt als ihre männlichen Kollegen.7
An dieser Stelle kann festgehalten werden, dass der Schutz der Privatsphäre von Gruppen (Group Privacy) manchmal unerwünscht sein kann, da man gegebenenfalls Entscheidungen auf der Grundlage persönlicher Merkmale treffen möchte. Im Fall der Geheimnisverletzung bei den Strava-Nutzern wäre es jedoch sinnvoll gewesen, den Nutzern die Möglichkeit einzuräumen, sich bewusst für diese Art des Trackings zu entscheiden (Opt-in), anstatt standardmäßig ein Opt-in zu implementieren. Strava hat diese Option später durch eine Opt-out-Option ersetzt, jedoch erst nachdem bereits geheime Informationen durchgesickert waren. Dies ist ein gutes Beispiel dafür, wie Ihnen die Prinzipien von Privacy by Design helfen können, Voreinstellungen und Einwilligungsoptionen zu wählen, die sicher sind!
Eine andere spannende Form von Angriff auf die Privatsphäre und die Gruppenzugehörigkeit ist die sogenannte Membership Inference Attack.
Was wäre, wenn ich Ihnen sagte, dass ich feststellen kann, ob Ihre Daten zum Trainieren eines Modells verwendet wurden. Das mag vielleicht keine Rolle spielen, wenn Daten von Milliarden von Menschen zum Trainieren des Modells verwendet wurden. Aber es wäre sicherlich nicht ganz unbedeutend für Sie, wenn der Trainingsdatensatz wesentlich kleiner wäre und wenn die Tatsache, dass Sie in dem Datensatz enthalten sind, etwas Bestimmtes über Sie, wie z.B. Ihre sexuelle Orientierung, Krankheiten oder andere gesundheitsbezogene Informationen, Ihren finanziellen Hintergrund usw., verraten würde.
Bei einer Membership Inference Attack versucht der Angreifer, in Erfahrung zu bringen, ob eine bestimmte Person in den Trainingsdaten enthalten war. Wenn ein Modell nur mit einem relativ kleinen Datensatz trainiert wird oder wenn eine gewisse Person einen Ausreißer darstellt, könnte diese Person besonders gefährdet sein.
Reza Shokri hat Membership Inference Attacks im Jahr 2016 (https://oreil.ly/DKAvU) entdeckt. Die Vorgehensweise ist wie folgt: Der Angreifer trainiert ein sogenanntes Schattenmodell (engl. Shadow Model), d.h. ein Modell, das dem echten Modell so nahe wie möglich kommen soll. Dies spiegelt das Vorgehen beim Transfer Learning (https://oreil.ly/pR9qc) wider, bei dem es darum geht, Informationen eines Modells zu übernehmen, sodass ein anderes relativ schnell trainiert werden kann – in der Regel in einem ähnlichen Bereich. Zum Beispiel beschleunigt die gemeinsame Nutzung von Ausgangsgewichten und Schichten bei großen Computer-Vision-Modellen meist das Training. Außerdem gibt es noch eine dem Generative Adversarial Network (GAN) ähnliche Architektur (https://oreil.ly/TznAI), bei der ein Diskriminator trainiert und verwendet wird, um festzustellen, ob eine Person (in Vektorform) im Trainingsdatensatz enthalten war oder nicht. Dieser Diskriminator leitet aus dem Output (bzw. der Ausgabe) des Modells selbst ab, ob ein bestimmter Datenpunkt in den Trainingsdaten enthalten war.8 Die vollständige Architektur können Sie in Abbildung 4-4 nachvollziehen. Es werden mehrere Schattenmodelle trainiert, deren Ergebnisse in das Attack Training Set aufgenommen werden, das dann als Trainingsdatensatz für den Diskriminator dient.
Abbildung 4-4: Eine Architektur, die bei Membership Inference Attacks verwendet wird
Sie können sich wahrscheinlich denken, was dabei herauskommt! Wenn sich ein Modell zu sehr an die zugrunde liegenden Trainingsdaten anpasst (engl. Overfitting) oder wenn ein Ausreißer (bzw. die mit ihm verbundene Person) bestimmte Informationen über sich selbst in das Modell einfließen lässt, werden die Wahrscheinlichkeiten für den Trainings- und den Testdatensatz stark voneinander abweichen. Dies gilt insbesondere für Ausreißer, für Modelle, die auf einem kleinen Datensatz trainiert wurden, und für Modelle, deren Generalisierungsfähigkeit schlecht ist.
Membership Inference Attacks verdeutlichen, wie wichtig es ist, dass Modelle gut generalisieren und wie sich Ausreißer auf das oder die resultierenden Modelle auswirken können. Datenschutztechniken und -technologien können dazu beitragen, den Einfluss von Ausreißern zu verringern und eine Generalisierung zu fördern. Ihr Ziel als Data Scientist ist es, dafür zu sorgen, dass Ihre Modelle leistungsfähig sind und dass diese Form der Preisgabe von persönlichen Informationen vermieden wird. In Kapitel 5 werden Sie erfahren, wie Sie Modelle unter Verwendung von Differential Privacy mit Daten, die auch persönliche Informationen enthalten, trainieren können.
Gehen wir die für eine Membership Inference Attack erforderlichen Schritte durch:
Shokri und seine Forschungskollegen haben getestet, wie erfolgreich diese Angriffe bei den Machine-Learning-Systemen von Amazon und Google Cloud sowie einem eigenen lokalen Modell waren. In ihren Experimenten erreichten sie eine Treffergenauigkeit (engl. Accuracy) von 74 % bei Amazons Machine Learning as a Service und eine Treffergenauigkeit von 94 % bei Googles Machine Learning as a Service. Somit konnten sie eindeutig aufzeigen, dass bei den Machine-Learning-Anwendungen private Informationen preisgegeben werden. In einer noch aktuelleren Studie (https://oreil.ly/Ijzl7) waren die Forscher in der Lage, diesen Angriff innerhalb dezentraler Systeme, bei denen die Privatsphäre geschützt bleiben soll, auszuführen, wie z.B. beim Federated Learning (siehe Kapitel 6). Diese Art von Machine-Learning-Architektur wird von Google und anderen großen Unternehmen unterstützt und ermöglicht die Nutzung privater Daten in einem sicheren und datenschutzfreundlichen Machine-Learning-System. Inzwischen hat Shokris Forschungsgruppe eine Open-Source-Bibliothek (https://oreil.ly/1Ftx5) veröffentlicht, mit der es möglich ist, das Risiko, dass im Rahmen von Membership Inference Attacks Informationen nach außen dringen, zu bemessen.
Empfehlungssysteme (engl. Recommender Systems) werden immer stärker personalisiert – basierend auf demografischen Informationen, der Höhe des Vermögens und anderen sensiblen Merkmalen. Bei Modellen, die auf Basis einer kleinen Population trainiert wurden, kann ein Angreifer, der gewisse Informationen über eine Person kennt, herausfinden, ob diese Person zuvor in dem Trainingsdatensatz enthalten war, sofern es ihm gelingt, die entsprechenden Input-Features zu imitieren. Gleiches gilt auch für andere Informationen, die zur Bestimmung der Population der Trainingsdaten zugrunde gelegt werden könnten, wie z.B. das Geschlecht, das Alter, die ethnische Zugehörigkeit, den Wohnort, den Aufenthaltsstatus, die sexuelle Orientierung, die politische Zugehörigkeit oder die Kaufpräferenzen.
In einer späteren Studie fanden Shokri und mehrere andere Forscher heraus, dass Modellerklärungen private Informationen preisgeben (https://oreil.ly/WFJlc) können, insbesondere bei Ausreißern. Dabei haben sie zur Erklärung (bzw. Erläuterung), warum ein Modell zu einer bestimmten Vorhersage oder einem bestimmten Ergebnis kam, die gängigen Standardmethoden herangezogen. Sie kamen zu dem Schluss, dass diese Erklärungen vor allem Informationen über Ausreißer preisgaben. Je mehr sensible Daten ein Modell zur Entscheidungsfindung heranzieht, desto wahrscheinlicher ist es, dass diese Art von Verhalten auftritt.
Diese erhöhte Granularität und Sensibilität des Modells birgt auch andere Risiken, z.B. dass sensible Merkmale von Personen eingesehen werden können, die Interesse daran zeigen, welche Art von Personen in den Trainingsdaten enthalten waren.
Membership Inference Attacks können generell dazu verwendet werden, Merkmale bestimmter Gruppen, die in der Trainingsdatenpopulation vertreten sind, zu analysieren, was als Attribute Privacy Attack (https://oreil.ly/OENQ1) bezeichnet wird. Hierbei möchte der Angreifer etwas über die zugrunde liegende Population herausfinden und verwendet dabei denselben Ansatz, um im Hinblick auf mögliche Personengruppen, die im Trainingsdatensatz enthalten sein könnten, verschiedene Theorien zu testen.
Bei dieser Art von Angriff werden sensible Daten von Personengruppen aufgedeckt. Wenn Sie ein Modell auf der Grundlage Ihrer eigenen Nutzerbasis trainieren und diese Nutzer überwiegend aus bestimmten Regionen stammen, bestimmte persönliche Merkmale aufweisen oder einer kleinen Zielgruppe angehören, die ein bestimmtes Merkmal gemeinsam haben, wie z.B. ihre Surf- oder Kaufgewohnheiten, dann könnten diese Informationen jedem zur Verfügung stehen, der Zugriff auf den Endpunkt des Modells hat, sofern diese Merkmale über die Input-Features oder das Verhalten des Modells offengelegt werden können. An diesem Punkt würde es sich nicht nur um einen Angriff auf die Privatsphäre handeln, sondern wahrscheinlich auch um ein Datenleck, bei dem vertrauliche Informationen preisgegeben werden!
Das ist jedoch nicht die einzige Art und Weise, wie sensible Merkmale an die Öffentlichkeit gelangen können. Eine Studie aus dem Jahr 2013 (https://oreil.ly/wtdqw) zeigte, dass Facebook-Likes in hohem Maße Rückschlüsse auf persönliche Merkmale wie die sexuelle Orientierung, das Geschlecht, die politische Einstellung oder den Konsum von Drogen zulassen. Die Studie wurde an der Cambridge University durchgeführt. Einer der Forscher arbeitete später für Cambridge Analytica, das diese Art von Mustern dazu genutzt hat, das Wahlverhalten zu manipulieren.9
Das zeigt noch einmal deutlich, wie wichtig die aus der Differential-Privacy-Forschung gewonnenen Erkenntnisse sind. Es ist äußerst schwierig, zu bestimmen, welche Merkmale ein potenzieller Angreifer finden, verwenden oder verknüpfen könnte. Die Studie dient als Beispiel dafür, wie aufschlussreich scheinbar harmlose Datenpunkte – wie Facebook-Likes oder das Suchverhalten im Internet – sein können. Wann immer Sie Daten von Menschen sammeln, müssen Sie sich der Tatsache bewusst sein, dass diese Daten andere sensible Merkmale preisgeben könnten.
Deshalb ist es wichtig, alle über Menschen gesammelten Daten so zu behandeln, als seien sie möglicherweise sensibel, und die in diesem Buch beschriebenen Techniken zusammen mit Ihren weiteren Nachforschungen und Experimenten zu nutzen, um so die Daten und die betroffenen Personen zu schützen.
Dass Modelle dazu imstande sind, sensible oder persönliche Merkmale aus scheinbar unsensiblen Datenpunkten zu erlernen, trägt erheblich dazu bei, dass sie sich unfair und diskriminierend verhalten. Wenn das resultierende Modell sensible Merkmale lernt, die aus den Korrelationen in den Trainingsdaten hervorgehen, reproduzieren diese Modelle gesellschaftliche Vorurteile und verstärken die systemimmanente Repression bestimmter Personengruppen. Diese Problematik geht über den Rahmen von Privacy und den des Buchs hinaus. Ich empfehle Ihnen jedoch, sich mit dem Buch Algorithms of Oppression von Safiya Umoja Noble (NYU Press, 2018) zu befassen und den Beiträgen von Timnit Gebru bzw. dem Team des DAIR Institute (https://www.dair-institute.org) sowie der Algorithmic Justice League (https://www.ajl.org) zu folgen, um mehr darüber zu erfahren.
Ein Problem im Zusammenhang mit der Art und Weise, wie Modelle lernen, besteht darin, dass sie Informationen memorieren bzw. speichern (engl. Memorizing) bzw. unbeabsichtigt speichern können. Dies kann vor allem dann leicht passieren, wenn es sich bei den Beispielen um Ausreißer handelt. Außerdem tritt das Problem auf, wenn ein bestimmtes Beispiel, das sensible Informationen enthält, mehrfach vorkommt. Dieses Phänomen steht in direktem Zusammenhang mit der Anzahl der Parameter bzw. der Größe des Modells (je größer die Anzahl der Modellparameter, desto besser das Erinnerungsvermögen). Die Ergebnisse der Studie »The Secret Sharer: Evaluating and Testing Unintended Memorization in Neural Networks« (https://oreil.ly/AAhWH) belegen dies, aber auch mehrere andere Forschungskreise konnten diese Beobachtungen zur gleichen Zeit bestätigten.
Carlini et al. konnten mit der Secret-Sharer-Studie zeigen, dass große Modelle dazu neigen, sich zu stark an den Trainingsdatensatz anzupassen, und sich bestimmte Teile der Daten merken. In dem Fall war es ein großes Sprachmodell, das speziell auf den Enron-E-Mail-Datensatz trainiert wurde und sich geheime Tokens, die im Datensatz enthalten waren (wie Kreditkartennummern, Sozialversicherungsnummern usw.), einprägen konnte. Ich gehe davon aus, dass Google dieses Verhalten auch bei anderen, nicht öffentlich zugänglichen und nicht für Forschungszwecke verwendeten Datensätzen feststellen konnte, was wiederum Anlass dazu gab, diese Studie zu veröffentlichen.
Je größer also die Modelle werden – und dem sind offenbar keine Grenzen gesetzt –, desto größer ist die Wahrscheinlichkeit, dass sie sich gewisse Dinge einprägen und sich übermäßig an die Daten anpassen. Dies ist insbesondere bei Ausreißern der Fall, sei es aufgrund ihrer Charakteristika und/oder aufgrund der Häufigkeit, mit der sie im Datensatz vorkommen.
Dieses Verhalten kann auch bei synthetischen GANs beobachtet werden, wie der Forschungsbeitrag This Person (Probably) Exists (https://oreil.ly/F0J8G) eindrucksvoll gezeigt hat. Bei dieser Studie wurde festgestellt, dass bei GANs, die auf personenbezogenen Daten beruhen, in vielen Fällen tatsächlich auf den Ausgangsdatensatz geschlossen werden kann. Dies war zum Beispiel der Fall bei den Gesichtsbildern, die man sich auf der Webseite This Person Does Not Exist (https://thispersondoesnotexist.com) generieren lassen kann. Zudem gab es noch zahlreiche weitere Fälle, bei denen professionelle Models dafür bezahlt wurden, sich ablichten zu lassen. Später musste man feststellen, dass diese Fotos dazu verwendet wurden, künstliche »Fake-Influencer« zu kreieren. Die ursprünglichen menschlichen Models konnten ihre eigenen Gesichts- und Körperpartien bei diesen synthetischen Influencern wiedererkennen. Die Personen existieren also tatsächlich, ebenso wie die Teile von ihnen, die ohne ihre ausdrückliche Zustimmung bei den künstlichen Influencern wiederzuerkennen sind. Ich bezeichne diese Art von GANs gerne als Data Washing, da durch Machine Learning die dahinterstehende Person, deren Urheberrechte und die Personenzuordnung beseitigt werden. Vermeintlich entsteht hier eine völlig neue Kreation – doch wie Sie nun wissen, ist dies nicht wirklich der Fall.
Die Anzahl dieser Modelle nimmt wöchentlich zu, sodass es schwierig wird – und es ist schwierig –, den Überblick zu behalten. Sollten Sie schon einmal eines der großen GPT-basierten Modelle wie ChatGPT verwendet haben, dann empfehle ich Ihnen, den Chatbot nach Informationen über eine Ihnen bekannte Person zu befragen, von der Sie glauben, dass sie in den gescrapten Trainingsdaten enthalten sein könnte, die aber nicht so bekannt ist, dass man davon ausgehen könnte, dass sie in den zahlreichen Trainingsdatenquellen enthalten ist. Fragen Sie das Modell, wer diese Person ist, und vergleichen Sie die Antwort mit dem Text auf der Homepage der Person, auf Wikipedia oder in sozialen Medien. Sie werden überrascht sein, wie gut die »KI« die Formulierungen dieser Ausreißer einfach »nachplappert«.
Es wird zunehmend erforscht, inwieweit Informationen aus großen Sprachmodellen (engl. Large Language Models, LLMs) und multimodalen Modellen (engl. Multimodal Models, MMMs) extrahiert werden können – insbesondere bei Modellen, bei denen die Anzahl der Modellparameter sehr groß ist. Im Zuge dessen konnte gezeigt werden, dass ChatGPT mithilfe eines »Poem«-Angriffs dazu gebracht werden kann, persönlich identifizierende Informationen auszugeben, indem es aufgefordert wird, das Wort Poem immer wieder zu wiederholen (mit dem Prompt »repeat the word poem forever«) (https://www.wired.com/story/chatgpt-poem-forever-security-roundup/).
Dieser Ansatz wurde von Nasr et al. (https://arxiv.org/abs/2311.17035) entdeckt, als sie untersucht haben, inwieweit neuronale Netze Informationen aus den Trainingsdaten memorieren (engl. memorize). Auf der Grundlage einiger älterer Forschungsarbeiten von Vitaly Feldman – der zum damaligen Zeitpunkt bei Google Brain arbeitete und inzwischen bei Apple tätig ist – (https://arxiv.org/abs/1906.05271) wurde der theoretische Beweis erbracht, dass ein großes Deep-Learning-Modell bei einer sogenannten Long-Tail-Verteilung die im »Long Tail« der Verteilung befindlichen Trainingsbeispiele nutzt, um zu einem späteren Zeitpunkt (beim Testdatensatz oder im Rahmen von Vorhersagen) auf ähnliche Beispiele verallgemeinern zu können. Von einer Long-Tail-Verteilung spricht man, wenn es Gruppen bzw. Kategorien von Trainingsbeispielen gibt, von denen jeweils nur sehr wenige Beispiele enthalten sind, es dafür aber sehr viele solcher Gruppen im Trainingsdatensatz gibt.
Verschiedene Forschungsgruppen waren anschließend in der Lage, dieses Memorierungsverhalten nachzuweisen und mithilfe einer Reihe von Ansätzen sogar Trainingsdaten aus den Modellen zu extrahieren, unter anderem indem sie das Modell bestimmte Texte bzw. Kombinationen von Texten, die in den Trainingsdaten enthalten waren, wortwörtlich wiedergeben (https://arxiv.org/abs/2202.07646) und Bilder von Personen reproduzieren ließen, deren Bilder in den Trainingsdaten enthalten waren (https://arxiv.org/abs/2301.13188). Bei Textdaten können derartige Arten von Angriffen mithilfe einer Metrik namens k-eidetic Memorization quantifiziert werden, wobei k die Anzahl der Tokens aus den Trainingsdaten angibt, die ein Modell memoriert hat und die aus diesem extrahiert werden können. Insbesondere bei über- bzw. hyperparametrisierten Modellen, bei denen die Anzahl der Parameter größer ist als die Anzahl an Trainingsbeispielen, ist dieses Memorierungsverhalten besonders stark ausgeprägt.
Die Forschungsergebnisse haben Anlass zur Annahme gegeben, dass große Modelle mindestens zwei Arten von Trainingsdaten memorieren: zum einen Texte bzw. Bilder, die mehrfach in den Trainingsdaten enthalten sind, und zum anderen Beispiele, die aus dem Long Tail einer Datenverteilung stammen, deren Memorierung die Generalisierungsfähigkeit des Modells erhöht, da diese Besipiele einen von nur wenigen Datenpunkten einer bestimmten Gruppe, Kategorie bzw. »Region« im hochdimensionalen Raum darstellen. Neueste Forschungsergebnisse zeigen, dass etwa 30 % der in den Trainingsdaten wiederholt vorkommenden Text- bzw. Multimedia-Daten von diesen großen Modellen (LLMs und MMMs) memoriert werden können. Allerdings wird ein Teil der memorierten Daten eines Sprachmodells möglicherweise nicht von der Metrik k-eidetic Memorization erfasst, da die extrahierte Token-Sequenz nicht identisch mit den Trainingsdaten, aber dennoch sehr ähnlich ist. Dies ist vermutlich auf Unterschiede bei der Suche und Vervollständigung von Tokens zurückzuführen. Wenn in einer Architektur zum Beispiel Beam Search (https://en.wikipedia.org/wiki/Beam_search) (eine Suchstrategie, die auf der Graphentheorie basiert) verwendet wird, um die nächsten Tokens eines Texts (bzw. die nächsten Token-Sequenzen verschiedener Beams, d.h. möglicher Pfade) vorherzusagen, kann dies – je nachdem, welcher Beam bzw. Pfad von dem Modell gewählt wird – zu ähnlichen Texten führen, die sich jedoch insbesondere in der Mitte des Texts leicht vom memorierten Text unterscheiden. Dementsprechend ist es schwierig, Angriffe, bei denen Beam Search zum Einsatz kommt, mit der k-eidetic-Memorization-Metrik nachzuweisen (bzw. solche Angriffe zu reproduzieren), da Beam Search dazu führt, dass sich ein Teil der Tokens von den ursprünglichen Texten, die in den Trainingsdaten enthalten sind, unterscheidet, auch wenn das Modell die Texte in Wirklichkeit memoriert hat. Derartige Angriffe werden auch in Zukunft Gegenstand der Forschung sein und wahrscheinlich noch an Bedeutung gewinnen, da Wissenschaftler im Laufe der nächsten Jahre weiter erforschen werden, welche weiteren potenziellen Angriffsvektoren denkbar sind und wie es zu einer Extraktion von Information kommen kann bzw. wie erkannt werden kann, dass derartige Informationen abgespeichert bzw. memoriert wurden.
Bei derzeit erforschten Angriffen kommen Techniken zum Einsatz, die z.B. auf der Perplexität bzw. der logarithmierten Länge der Tokens eines Prompts (Log-Perple xity) (ähnlich der Secret-Sharer-Angriffsmethode) basieren oder auch darauf, wie stark der »Einfluss« eines in dem Trainingsdatensatz enthaltenen Datenpunkts auf das Modell selbst (https://pluskid.github.io/influence-memorization/) ist. Wie stark der Einfluss eines einzelnen Datenpunkts ist, hängt eng damit zusammen, wie viel das Modell aus diesem lernt, wenn er beim Training verwendet wird, und kann als eine Art Shapley-Wert (aus der Spieltheorie) (https://en.wikipedia.org/wiki/Shapley_value) betrachtet werden. Anders ausgedrückt, können Sie sich dies als die Menge an neuen Informationen vorstellen, die das Modell auf der Grundlage dessen gelernt hat, was es bisher »gesehen« hat (und die daher je nachdem, welche anderen Trainingsdaten genutzt, welche Sampling-Methode gewählt und wie die Trainings-batches gewählt bzw. gesampelt wurden, variiert).
Dieses Phänomen ist auch eng verbunden mit der »Generalization Gap« (https://blog.research.google/2019/07/predicting-generalization-gap-in-deep.html), d.h. damit, wie gut ein Modell auf neuen, zuvor noch unbekannten Daten im Vergleich zu den Trainingsdaten abschneidet (die in dem Forschungsbeitrag mithilfe des Testdatensatzes quantifiziert wird). Eine fortlaufende Studie mehrerer Wissenschaftler, die sich mit der Messung und Schätzung von Rand- bzw. Marginalverteilungen (engl. Margin Distributions) befassen (die sich, vereinfacht ausgedrückt, als Abstand zwischen Datenpunkten und Entscheidungsgrenzen in einem hochdimensionalen Raum definieren lassen), könnte dabei helfen, festzustellen, wie gut ein Modell generalisiert und – was insbesondere für den Datenschutz relevant ist – wie viele Trainingsdaten memoriert worden sind. In diesem Zusammenhang könnten ebenfalls noch Metriken entwickelt werden, mit denen sich beurteilen lässt, wie stark die Memorierfähigkeit eines Modells ausgeprägt ist und wie wahrscheinlich es ist, dass ein bestimmtes Trainingsbeispiel memoriert wird. Wenn Sie sich bereits mit Support Vector Machines (SVMs) beschäftigt haben, dürften Sie sich mit Randverteilungen auskennen und eine gewisse Vorstellung davon haben, wie sich dies auf ein überparametrisiertes Deep-Learning-Modell auswirken könnte.
Wenn es darum geht, die Vertraulichkeit der Trainingsdaten in einem großen Deep-Learning-Modell – insbesondere in Modellen, die stark überparametrisiert sind – zu gewährleisten, verheißt dies jedoch nichts Gutes. Ansätze wie Differential Privacy oder Ausreißer bzw. ungewöhnliche Beispiele zu entfernen, könnten zur Regularisierung von Modellen beitragen und so den Schutz der Privatsphäre verbessern und die Memorierfähigkeit verringern. Bislang (Stand März 2024) haben diese Ansätze jedoch noch nicht zu Modellen geführt, die genauso leistungsfähig sind wie Modelle, bei denen der Schutz der Privatsphäre keine Berücksichtigung findet.
Diese großen Modelle speichern also definitiv einen Teil ihrer Trainingsdaten und sollten daher als potenziell sensibel behandelt werden, wenn sie mit sensiblen Daten trainiert wurden. Angesichts aktueller und vergangener Angriffe, bei denen Daten extrahiert werden konnten, ist bei der Verwendung großer Modelle in Produktionsumgebungen Vorsicht geboten. Die Frage, ob einige der bekannteren Modelle (wie z.B. ChatGPT) aufgrund von Datenschutz- und/oder Urheberrechtsansprüchen bezüglich der im Trainingsdatensatz enthaltenen und gespeicherten Daten komplett neu trainiert werden müssen, ist im Moment noch offen. Derzeit sind mehrere Gerichtsverfahren gegen die Betreiber dieser Modelle anhängig, unter anderem eine Klage der New York Times gegen OpenAI und Microsoft (https://www.nytimes.com/2023/12/27/business/media/new-york-times-open-ai-microsoft-lawsuit.html) aufgrund unlauterer Nutzung ihrer Daten (d.h. Verletzung des Urheberrechts).
Inzwischen dürfte Ihnen bewusst geworden sein, wie wertvoll und zugleich heikel trainierte Modelle sein können. Nun werden wir uns genauer damit befassen, wie es Angreifern gelungen ist, Modelle aus Produktionssystemen zu stehlen.
Modelle werden ein zunehmend wertvolles Gut, und mit zunehmender Integration in Produktionssysteme werden sie mehr und mehr an den Rand der Infrastruktur gebracht. Dort werden sie entweder über das Internet öffentlich zugänglich gemacht oder direkt auf den Endgeräten der Nutzer deployt, wie etwa Laptops, Smartphones und Haushaltsgeräte. Dadurch erhöht sich ebenfalls zunehmend das Risiko einer Model-Stealing Attack. Hierbei ist der Angreifer in der Lage, entweder das Modell selbst oder eine hinreichend genaue Näherung zu erlangen, die er anschließend für eigene Machine-Learning-Anwendungen nutzen oder aus dem er weitere Einzelheiten gewinnen kann.
Warum ist das ein Problem? Nun, wenn das Modell sensible oder urheberrechtlich geschützte Informationen enthält oder als Vermögenswert des Unternehmens angesehen wird, ist diese Art von Angriff genauso schlimm wie ein Geld- oder Datendiebstahl aus Ihrem Unternehmen! Ist das Modell bereits als Open Source verfügbar oder handelt es sich um ein feingetuntes Modell, das auf einem großen Open-Source-Modell aufbaut, ist das Risiko bzw. die Gefahr wesentlich geringer.
Wie funktionieren solche Angriffe? Einer der ersten Artikel, in dem diese Art von Angriffen beschrieben wird, wurde im Jahr 2016 von Florian Tramèr et al. (https://oreil.ly/C9DE0) veröffentlicht. Die Forschungsgruppe war in der Lage, mehrere Modelle mit den damals verfügbaren APIs von Amazon und Google Cloud zu trainieren. Sie konnten einen Datensatz zusammenstellen, der die Daten, mit denen die entsprechenden Modelle trainiert wurden, abbildet. Sie haben eine Reihe von API-Anfragen gestellt und konnten ihre Anfragen so optimieren, dass sie im Rahmen der Suche den Wertebereich auf die Inputdaten eingrenzen konnten. Diese Datenpunkte haben sie gespeichert und einen Trainingssatz erstellt, mit dem sie eine Vielzahl von Modellen entwickelt haben. Anschließend wurde in regelmäßigen Zeitabständen ein Feintuning des Modells vorgenommen, um sicherzustellen, dass das Modell genau mit dem Produktionssystem übereinstimmt.
Vor einiger Zeit habe ich einen O’Reilly-Live-Kurs abgehalten, in dem ich einige dieser Angriffe vorgestellt habe. Die entsprechenden Beispiel-Notebooks (https://oreil.ly/4I_46) (und auch noch weitere (https://oreil.ly/irvSK)) finden Sie online. Wenn Sie einen ganz bestimmten Anwendungsfall ausprobieren möchten, empfehle ich Ihnen, sich zunächst auf GitHub umzusehen. Dort sind zahlreiche Implementierungen verfügbar, die für verschiedene Architekturen bzw. Programmiersprachen aktuell gehalten werden.
Wenn Modelle direkt auf dem Endgerät deployt werden, können die Anwenderinnen und Anwender das Verhalten des Modells noch einfacher überprüfen und Anfragen in einer Umgebung mit geringer Latenz durchführen. Mehrere (https://oreil.ly/50xHz) Forscher (https://oreil.ly/Xhv1w) und auch Enthusiasten (https://oreil.ly/NdMH-) haben sich mit Modellen beschäftigt, die an Android- und iOS-Geräte ausgeliefert werden, und untersucht, wie sich Gewichtung und Architektur des Modells mittels Reverse Engineering rekonstruieren lassen. Solche Modelle zu schützen, ist immer noch ein ungelöstes Problem. Es gibt verschiedene Vorschläge, beispielsweise Differential Privacy im Rahmen des Modelltrainings zu verwenden (siehe Kapitel 5), die Modellarchitektur mithilfe von Transfer Learning und Distillation zu verbergen oder mehrere Modelle als Teil eines Gesamtprozesses zu verwenden und nur die Modelle auszuliefern, die direkt auf dem Endgerät ausgeführt werden müssen. Unter Umständen eignet sich auch das Federated Learning, bei dem das Modell von allen Geräten geteilt wird (siehe Kapitel 6). Da sich auf diesem Forschungsgebiet viel tut, empfehle ich Ihnen, nach neueren Forschungsergebnissen Ausschau zu halten und diese Problematik offen mit den Sicherheits- und Datenschutzexperten in Ihrem Unternehmen zu besprechen, um zu ermitteln, welche Schutzmaßnahmen geeignet sind.
In ähnlicher Weise werden bei Model Inversion Attacks Modelle ausgenutzt, um einen einzelnen Benutzer ins Visier zu nehmen. Im Jahr 2015 gelang es Forscherinnen und Forschern, verrauschte Bilder aus Gesichtserkennungsmodellen zu erhalten (https://oreil.ly/72pkx), auf denen die zugrunde liegende Fotos halbwegs zu erkennen waren. Die einzigen Daten, die für diesen Angriff benötigt wurden, waren die Klasse bzw. Kategorie, die das Modell vorhersagen sollte (engl. Target Class), und ein Zugang zur API, mit der die Vorhersagen des Modells bereitgestellt wurden. Sie haben dabei eine Suchmethode verwendet, die darauf abzielte, die maximal mögliche Aktivierung der Gewichte herbeizuführen, sodass sie näher an die optimalen Inputwerte herankamen – in diesem Fall dem Gesicht einer Person. In Abbildung 4-5 sehen Sie einen Vergleich zwischen dem extrahierten und dem tatsächlichen Bild. Das extrahierte Bild wurde mithilfe eines Open-Source-Repositorys generiert, mit dem der Ansatz des ursprünglichen Forschungsartikels reproduziert werden kann (https://oreil.ly/PLZ5y).
Abbildung 4-5: Ein verrauschtes Gesicht, das im Rahmen einer Model Inversion Attack extrahiert wurde (links), und das Foto des Geschädigten, das im Trainingsdatensatz enthalten war (rechts). Der Angreifer kennt lediglich den Namen der Person, und er hat Zugang zu einem Gesichtserkennungssystem, das einen Konfidenzwert für die jeweilige Kategorie liefert.
Wenn ein Modell mit einem sehr hohen Risiko verbunden ist, sollte es als besonders schützenswert behandelt und durch mehrere Schutzebenen abgesichert werden. Dabei muss die Nutzbarkeit des Systems mit dem Schutz des Modells in Einklang gebracht werden. Dies lässt sich am besten durch den Einsatz bestimmter Datenschutztechnologien erreichen. In Kapitel 6 erfahren Sie mehr darüber, wie Sie Teile Ihrer Modelle direkt auf die Endgeräte bringen und sie dabei stets aktuell und sicher halten können.
Eine weitere Art von Angriffen, die sich als erfolgreich gegenüber LLMs und anderen MMMs erwiesen hat, besteht darin, Informationen aus Prompts sowie aus zusätzlichen Datenquellen und Dokumenten zu extrahieren, die dem LLM entweder über Plug-ins oder über Datenbanken zur Verfügung gestellt bzw. hinterlegt werden, wie dies z.B. bei einer typischen Retrieval-Augmented-Generation-(RAG-)Architektur der Fall ist. Bei einer RAG-Architektur wird ein LLM zusammen mit einem Prompt und einer Abfrage des Anwenders verwendet, um ein Dokument bzw. eine Reihe von Dokumenten zu durchsuchen bzw. abzurufen, in denen relevante Informationen enthalten sind. Diese Dokumente können dann dem Anwender angezeigt oder noch weiter abgefragt werden, um auf Basis des LLM bzw. MMM Informationen aus den Dokumenten zu extrahieren.
Sie haben vielleicht schon Beispiele für diese Art von Angriffen in den sozialen Medien gesehen, bei denen diverse nicht besonders gut gestaltete Chatagenten fröhlich die Anweisungen wiederholen, die als Teil des Prompts gegeben wurden. Diese Art von Angriffen hat sich so weit verbreitet, dass es ein ganzes GitHub-Repository mit Prompts gibt, die geleakt werden konnten (https://github.com/linexjlin/GPTs) – und das Repository listet noch nicht einmal alle Prompts auf, die extrahiert werden konnten.
Darüber hinaus wurden noch weitere Angriffe über Plug-ins und schlecht konzipierte LLM- und MMM-Systeme entwickelt, was größtenteils neugierigen Anwenderinnen und Anwendern sowie Sicherheitsforschern zu verdanken ist. Beispielsweise haben Forscher der University of Washington eine ziemlich umfassende Übersicht verschiedener Arten von Plug-in-Attacks gegen LLM-Systeme (https://arxiv.org/abs/2309.10254) erstellt, in der Angriffe wie Prompt-Hijacking, Manipulation von Anwendern, Diebstahl von Plug-in-Daten und andere mögliche Angriffsvektoren mit Beispielen beschrieben werden. Es gab auch viele dokumentierte Angriffe, bei denen zusätzliche Informationen, die einem LLM- oder MMM-System wie z.B. einer RAG-Architektur vorgegeben wurden, abgegriffen werden konnten. Ein besonders alarmierendes Beispiel im Hinblick auf den Datenschutz war ein Fall, in dem es gelang, konkrete Gehalts-, Personal- und Unternehmensinformationen aus dem Chatbot Levels.fyi zu extrahieren (https://twitter.com/kanateven/status/1722762002475475426), die dem RAG-System als Excel-Dokument zur Verfügung gestellt wurden, ohne dass entsprechende Datenschutzvorkehrungen getroffen wurden.
Es sind noch weitere Formen von Angriffen auf die Privatsphäre denkbar, bei denen die Schnittstelle des RAG ein Risiko darstellt, da es gegebenenfalls schwierig ist, den Zugriff auf sensible Daten zu schützen. Stellen Sie sich beispielsweise einen Chatbot vor, der eine Schnittstelle zu einer Datenbank mit personenbezogenen Informationen hat. Wenn Sie die Informationen in natürlicher Sprache abfragen und eine bestimmte Person (absichtlich oder unabsichtlich) herausfiltern (single out) können, indem Sie Ihre Abfrage auf verschiedene Arten geschickt formulieren, stellt dies für den Dateneigentümer ein erhebliches Risiko dar, und zwar im Hinblick auf die Frage, ob die Person, die die Schnittstelle verwendet, zu deren Verwendung berechtigt ist und wie man sich gegen solche Abfragen schützen kann. Bei der Verwendung eines Chatbots mit einer solchen Schnittstelle ist es schwierig, einen Angriff auf die Privatsphäre im Vergleich zu einer normalen Abfrage zu erkennen (z.B. »Gib mir alle Personen aus Postleitzahl X aus, die in der letzten Woche auch Produkt Y gekauft haben«).
Es gibt bisher noch keine festen oder gar standardisierten Schutzmaßnahmen, mit denen diese Exfiltration Attacks in einem größeren Umfang verhindert werden könnten, und wahrscheinlich werden künftig noch weitere Angriffsvektoren entdeckt. Damit das RAG-System sicher genutzt werden kann und weder die in einem Prompt enthaltenen Informationen noch die im System hinterlegten privaten Informationen in falsche Hände geraten können, sollte sichergestellt werden, dass derartige Informationen in den hinterlegten Dokumenten bzw. Quellen bereits unkenntlich gemacht wurden oder der Zugang zum System auf die entsprechende Zielgruppe beschränkt wurde. Beispielsweise könnten Sie eine Pseudonymisierung Ihrer Textdokumente vornehmen, sodass private Informationen, die das LLM nicht an Nutzerinnen und Nutzer ausgeben soll, entfernt werden. Oder Sie könnten dafür sorgen, dass Ihr Nutzerkreis nur aus einer kleineren Gruppe von Personen besteht, die ohnehin Zugang zu den Dokumenten und allen darin enthaltenen Informationen haben, und dass das RAG-System diesen Nutzern lediglich eine weitere Schnittstelle zu den Datenquellen bietet. Sie sollten auf jeden Fall keine öffentlich zugängliche Schnittstelle zu Informationen anbieten, die Sie auch nur ansatzweise als sensibel einstufen würden, wie z.B. Ihre Prompt-Anweisungen, Ihre Trainingsdaten und alle weiteren Dokumente, auf die das System Zugriff hat.
Wenn also Datenschutztechnologien bzw. Privacy-Mechanismen dabei helfen können, Modelle zu entwickeln, die weniger Informationen preisgeben, ist es dann möglich, diese Mechanismen anzugreifen? Im Folgenden werden wir uns ansehen, wie Forscherinnen und Forscher nachweisen konnten, dass es möglich ist, Privacy-Mechanismen selbst anzugreifen.
In Kapitel 2 habe ich bereits darauf hingewiesen, dass auch Angriffe auf Differential-Privacy-Mechanismen möglich sind. Gehen wir nun etwas eingehender auf verschiedene Arten von Angriffen ein, die durchgeführt wurden, und darauf, wie sich diese Angriffe durch die Verwendung entsprechender Bibliotheken verhindern lassen.
Im Jahr 2012 war Ilya Mironov in der Lage, erstmals einen Angriff auf einen Differential-Privacy-Mechanismus durchzuführen, der die Laplace-Verteilung nutzte (https://oreil.ly/fgZDr). Er basierte auf der Funktionsweise von Gleitkommasystemen. Wenn Werte aus einer Laplace-Verteilung gezogen werden, wird im Grunde versucht, einen stetigen Raum zu modellieren – doch so funktionieren Computer eigentlich nicht. Forscher konnten nachweisen, dass Rechner, die mit Gleitkommaberechnungen arbeiten, dazu neigen, Zufallszahlen auf vorhersehbare Weise zu ziehen bzw. zu generieren. Wenn man bedenkt, dass jemand einen Code schreiben muss, der Entropie erzeugt, ergibt dies durchaus Sinn – im Allgemeinen eignen sich Computer nicht besonders gut als Quelle für echte Entropie.
Bei dieser Art von Angriff beobachtet der Angreifer zunächst mehrere Abfrageergebnisse für einen bestimmten Differential-Privacy-Mechanismus und versucht anschließend, festzustellen, ob sie aus einer Zufallsverteilung stammen oder nicht. Wenn der Angreifer die Art der Verteilung kennt (z.B. Laplace- oder Gauß-Verteilung) und im Rahmen des Mechanismus nicht noch ein zusätzlicher Zufallsprozess berücksichtigt wird, sondern stattdessen auf Built-in-Funktionen von Bibliotheken für Zufallsstichprobenverfahren zurückgreift, kann ein Angriff durchaus zum Erfolg führen.
Diese Art von Angriff lässt sich jedoch verhindern, indem zusätzlich zum zufälligen Rauschen noch ein Nachbearbeitungsschritt (engl. Post-Processing) durchgeführt wird. Dieser Nachbearbeitungsschritt sollte direkt in der Bibliothek integriert sein, einem Peer Review unterzogen und auditiert worden sein sowie Methoden verwenden, die unabhängig von dem verwendeten Computer funktionieren.10
Erfolgreiche Angriffe auf k-Anonymity und auch auf andere wenig wirksame Anonymisierungsmechanismen sind so alltäglich, dass ihnen in der Öffentlichkeit nur wenig Beachtung geschenkt wird. Sie können sich allerdings recht einfach über die neuesten Forschungsergebnisse informieren, indem Sie auf arXiv.org (https://arxiv.org/) als Suchbegriff »re-identification« eingeben. Außerdem empfehle ich Ihnen, nachzuvollziehen, wie es Aloni Cohen gelang, einen mit k-Anonymity »anonymisierten« Datensatz eines Anbieters von Onlinebildungsangeboten (EdX) (https://oreil.ly/t3I3v) erfolgreich anzugreifen.
Darüber hinaus hat sich gezeigt, dass auch sogenannte Timing Attacks erfolgreich gegen Differential-Privacy-Mechanismen eingesetzt werden können. Dabei misst der Angreifer die Zeit, die zur Beantwortung einer Anfrage benötigt wird, und erstellt dann ein statistisches Modell, mit dessen Hilfe er bestimmen kann, aus welchem Bereich der Verteilung, die dem Rauschen zugrunde liegt, gezogen wurde. Timing Attacks sind bei rechenintensiven Operationen, etwa in der Kryptografie, stark verbreitet. Sie sind besonders schwer zu verhindern, wenn das Ziel darin besteht, möglichst kurze Antwortzeiten zu erreichen.
Die bisher beschriebenen Angriffsvektoren decken keinesfalls alle möglichen Angriffsarten, die auf Daten oder Machine-Learning-Systeme abzielen, ab! Aber sie sollten Ihnen dennoch vor Augen geführt haben, dass Sie stets wachsam sein müssen und vorausschauend agieren sollten. Ich hoffe, Sie haben nun eine grundlegende Vorstellung davon, worauf Sie achten müssen und wie Sie die gängigsten Arten von Angriffen einschätzen können.
Sie haben noch nicht einmal angefangen, an der Oberfläche anderer Arten von Angriffen auf Machine-Learning-Modelle zu kratzen, wie z.B. Adversarial Attacks, bei denen versucht wird, das Modell zu einem bestimmten Ergebnis zu »verleiten«, oder Poisoning bzw. Byzantine Attacks, bei denen dafür gesorgt wird, dass Modelle einer gewissen systematischen Veränderung (Drift) unterliegen. Wenn Sie sich einen guten Überblick über diesen Bereich verschaffen möchten, rate ich Ihnen, als Einstieg den Artikel »Wild Patterns« von Battista Biggio et al. (https://oreil.ly/cHZxg) zu lesen und anschließend nach den aktuellsten Veröffentlichungen auf ArXiv zu suchen! Es gibt auch einige interessante Konferenzen, wie z.B. die AI and Security Conference der Association for Computing Machinery (ACM) (https://aisec.cc) und den ML Safety Workshop der NeurIPS-Konferenz (https://oreil.ly/Ajcg0).
Im nächsten Abschnitt lernen Sie die Grundlagen der Datensicherheit kennen, die Ihnen einen Überblick verschaffen sollen, sofern Ihnen das Thema noch nicht so geläufig ist. Sie werden sehen, wie die Zusammenarbeit mit Datensicherheitsexperten dazu beiträgt, Angriffe abzuwehren und damit verbundene Risiken zu handhaben sowie den Datenschutz und die Sicherheit bei Ihrer datenwissenschaftlichen Arbeit zu gewährleisten.
Das Thema Datensicherheit (engl. Data Security) überschneidet sich relativ stark mit den Themen Datenschutz und Data Governance. Sicherheit ist ein wesentlicher Aspekt der Data Governance – sei es, dass der Zugriff auf Daten beschränkt wird, sei es, dass eine unsichere oder fragwürdige Nutzung von Daten verhindert wird, sei es, dass Sicherheitskontrollen für sicherere Daten eingeführt werden, oder sei es, dass im Fall von Problemen (etwa wenn Daten preisgegeben oder gestohlen werden) Hilfe zur Verfügung steht. Wenn Daten an die Öffentlichkeit gelangen, ist natürlich auch der Datenschutz betroffen. Die beiden Bereiche ergänzen sich also, sind aber keineswegs deckungsgleich.
Auch wenn diese Systeme und Prozesse in der Regel nicht in den Zuständigkeitsbereich des Data-Science-Teams fallen, sollten Sie sich mit ihnen auskennen und in Gesprächen darauf eingehen können. Denn wenn Sie sensible Daten verwalten und pflegen, werden Sie unweigerlich mit dem Thema in Berührung kommen. Darüber hinaus kann es Ihnen helfen, potenzielle Angriffe besser zu antizipieren und die von Ihnen verwendeten Daten zu schützen.
Bei Datensicherheit geht es fast immer um die drei Grundsätze der Informationsbzw. Datensicherheit, die auch als CIA-Prinzip (engl. CIA Triad) bezeichnet werden und für Folgendes stehen:
Vertraulichkeit (engl. Confidentiality)
Daten, die als sensibel oder vertraulich einzustufen sind, werden nur den Personen zugänglich gemacht, die auch wirklich Zugriff auf die Daten haben sollten. Andere Personen – sowohl innerhalb als auch außerhalb des Unternehmens – haben keinerlei Zugriff auf diese Daten.
Integrität (engl. Integrity)
Den Daten kann vertraut werden. Sie sind korrekt und wurden weder intern – d.h. durch Nachlässigkeit – noch extern – d.h. durch Manipulation – verfälscht.
Verfügbarkeit (engl. Availability)
Die Daten und die damit verbundenen Dienste stehen in einer für den jeweiligen Zweck geeigneten Form zur Verfügung. Dies ist in der Regel mit Vereinbarungen wie Service Level Agreements (SLAs) oder Service Level Objectives (SLOs) verbunden, in denen Metriken in Bezug auf die Verfügbarkeit festgelegt werden.
Diese Ziele werden natürlich von den meisten Datenteams verfolgt, aber ihr Schwerpunkt liegt auf potenziellen böswilligen Aktivitäten oder Akteuren, die entweder außerhalb oder innerhalb des Unternehmens angesiedelt sind (auch als interne Bedrohungen, engl. Internal Threats, bezeichnet).
Abbildung 4-6 stellt einige der Überschneidungen zwischen diesen Bereichen der Datensicherheit aus der Sicht der Data Science dar. Auch wenn die Darstellung nicht erschöpfend ist, bietet sie doch eine gute Orientierungshilfe und sollte eine Vorstellung davon vermitteln, wie sich diese Bereiche überschneiden.
Abbildung 4-6: Die Grundsätze der Datensicherheit in der Data Science
Datensicherheitsexperten haben verschiedene wichtige Anliegen in Bezug auf die Verwaltung von Daten, die Umsetzung von Data Governance und die Unterstützung von Datenschutzinitiativen. In den folgenden Abschnitten lernen Sie die wichtigsten Komponenten und Technologien kennen, die Ihnen bei der Arbeit mit Sicherheitsexperten an solchen Systemen begegnen werden. Außerdem gebe ich Ihnen Tipps dazu, wie Sie die Zusammenarbeit verbessern können.
Zugriffskontrollsysteme, die oft mit Authentifizierungs- und Identitätsanbietern wie Microsoft Active Directory, Google Single-Sign-On (SSO) und AWS Identity and Access Management (IAM) gekoppelt sind, ermöglichen Administratoren, zu steuern, wer auf welche Daten in welcher Form Zugriff hat. Mit diesen Systemen können Sie Gruppen von Personen und/oder Diensten bilden, die über die erforderlichen Zugangsdaten zur Authentifizierung (engl. Authentication Credentials) verfügen, um auf Daten zuzugreifen, sie zu lesen, zu ändern oder zu ergänzen. Es gibt mehrere Gründe, warum diese Form der Zugriffskontrolle Sinn ergibt. Beispielsweise kann es sinnvoll sein, den Schreibzugriff auf Daten zu sperren, wenn ein Dienst von einem böswilligen Akteur kompromittiert wurde und ihn zur Manipulation von Daten nutzen könnte (z.B. durch Verschlüsselung im Rahmen einer Ransomware Attack). Darüber hinaus kann es ein erhebliches Sicherheitsrisiko darstellen, wenn ein böswilliger Akteur Lesezugriff auf bestimmte Daten erhält.
Beispielsweise könnte ein Dienst eine API für ein Machine-Learning-Modell zum Abrufen von Daten zum Trainieren und Testen sein. Dieser Dienst benötigt nur Lesezugriff, da er die Daten nicht ändern muss und auch nicht sollte.
Oder Sie haben beispielsweise eine Datenbank mit personenbezogenen Daten, die Sie besser schützen möchten als andere Datenbanken. Sie könnten Zugriffskontrollen für eine kleinere Gruppe von Personen einrichten und integrierte Sicherheitsfunktionen verwenden, um sicherzustellen, dass jeder Zugriff protokolliert wird und dass bei allen Abfragen bestimmte Felder mit unkenntlich gemachtem Inhalt zurückgegeben werden. Pseudonymisierungstechniken (siehe Kapitel 1), wie z.B. Maskierung, oder idealerweise die Verwendung von Differential Privacy (siehe Kapitel 2) würden einen zusätzlichen Schutz beim Zugriff bieten und auch einen besseren Audit Trail ermöglichen, wenn ein Datenleck vermutet wird.
Data-Loss-Prevention-Technologien messen ein- und ausgehende Datenströme an System- oder Netzwerkschnittstellen, um festzustellen, ob sensible Daten eine vertrauenswürdige Umgebung verlassen. Sie werden häufig von Datensicherheitsexperten eingesetzt, um einen zusätzlichen Schutz für sensible Daten zu bieten und Angriffe abzuwehren, die auf Datenexfiltration abzielen, was bedeutet, dass jemand versucht, Daten auf nicht autorisierte Weise zu exportieren oder zu übertragen. Ein böswilliger Akteur könnte in das Netzwerk eindringen, um Dateien und Daten zu stehlen. Ebenso gefährlich kann eine interne Bedrohung sein, z.B. wenn ein Mitarbeiter Daten an Dritte oder ein anderes Gerät exportiert und diese dann unbefugt verwendet werden. Die interne Weitergabe von Informationen muss nicht einmal vorsätzlich oder böswillig geschehen, etwa wenn durch »Schatten-IT« die interne Weitergabe sensibler Daten zur Normalität geworden ist (obwohl sie nach wie vor verboten ist!).
Mit Data-Loss-Prevention-Technologien können diese Datenströme häufig durch eine Analyse der Netzwerkaktivitäten und der Header oder Metadaten der Netzwerkpakete erkannt werden. Viele führende Lösungen beinhalten statistische und/oder Machine-Learning-Modelle. Als Data Scientist sind Sie in der Lage, aus einem anormalen Netzwerkverhalten (z.B. Gigabytes an Daten, die an eine neue IP-Adresse geleitet werden, oder Daten, die zu ungewöhnlichen Zeiten übertragen werden) zu schließen, dass etwas nicht stimmt. Je nachdem, wie das Netzwerk aufgebaut ist und verwaltet wird, ist es auch möglich, eine Deep Packet Inspection durchzuführen, die es Netzwerkadministratoren und Data-Loss-Prevention-Technologien ermöglicht, ein besseres Bild davon zu bekommen, was genau über das Netzwerk übertragen wird.
Wenn Ihr Unternehmen Data-Loss-Prevention-Technologien einsetzt, ist es wichtig, dass das Datenteam weiß, wo und wie diese eingesetzt werden, damit neue Datendienste, die Sie entwickeln, nicht als potenziell bösartig eingestuft werden. Wenn Sie sich weiter mit Data Loss Prevention beschäftigen wollen, könnte es auch für Sie interessant sein, mehr über die verwendete Technologie zu erfahren. Möchten Sie im Allgemeinen mehr über Data-Loss-Prevention-Technologien erfahren, empfehle ich Ihnen, sich den entsprechenden Abschnitt in der Dokumentation von Google Cloud (https://cloud.google.com/dlp) durchzulesen.
In den meisten Unternehmen sind heute zusätzliche Sicherheitsvorkehrungen, die über die grundlegenden Zugriffskontrollmechanismen hinausgehen, üblich. Sie reichen von der Verschlüsselung aller Daten während der Speicherung (engl. Encryption at Rest) und der Sicherstellung, dass die Chiffrierschlüssel regelmäßig ausgetauscht werden, über die Änderung von Serverzugriffspunkten bis hin zu Netzwerkbeschränkungen oder Cloud-Identitätsdiensten wie Amazons Identity and Access Management (IAM). Ziel dieser zusätzlichen Schutz- und Abwehrmaßnahmen ist die Verringerung des Risikos eines internen oder externen Angriffs.
Im Fall eines Eindringens in Server, Netzwerk oder System erschweren sie den Zugang zu Daten. Wohlmeinende Akteure wie Entwicklerteams, Data Scientists und Data Analysts beschweren sich jedoch häufig über diese Vorkehrungen, da sie einige zusätzliche Schritte im Rahmen ihrer Arbeit erfordern.
Sie tragen jedoch dazu bei, dass der Zugriff auf die Daten in adäquater Weise erfolgt. Je wertvoller die Daten sind, desto mehr Kontrollmechanismen und Schutzmaßnahmen sollten für sie vorgesehen werden. Gehen Sie mit gutem Beispiel voran und setzen Sie sich für diese Maßnahmen, die auch zu einem verbesserten Datenschutz beitragen, ein. Die meisten Technologen haben diese grundlegenden Datensicherheitsmaßnahmen, wie die Verwendung von Authentifizierungssystemen, Schlüsselmanagement oder die Überprüfung von Zugriffsrechten, bereits angewandt und verinnerlicht – und auch Datenspezialisten müssen lernen, damit umzugehen. Vielleicht werden Sie sich eines Tages auf Datenschutz und -sicherheit spezialisieren und diese Systeme sogar vorschlagen und implementieren.
Sicherheitsexperten verwenden im Rahmen der Bewertung von Sicherheitsrisiken meist Threat Modeling und Incident-Response-Pläne. Dies geschieht in der Regel durch die Teams für Informationssicherheit (Infosec) in Zusammenarbeit mit den zuständigen Compliance-, Audit- oder Rechtsexperten.
Threat Modeling (d.h. die Modellierung möglicher Bedrohungen bzw. Gefährdungen) besteht darin, die aktuellen Prozesse, Datenströme und Abläufe abzubilden und dann zu überlegen, wie böswillige Akteure die Infrastruktur angreifen oder Mitarbeitende dazu bringen könnten, ihnen Zugang zu gewähren oder die Dienste für nicht beabsichtigte Zwecke zu nutzen. Wenn es effektiv durchgeführt wird, ist dies eine fortlaufende und agile Aufgabe, die dazu beiträgt, dass Daten, Anwendungen und Menschen so sicher wie möglich sind.
Ich hatte die Gelegenheit, mit großartigen Sicherheitsexperten zusammenzuarbeiten. Dabei habe ich die Erfahrung gemacht, dass diese bereit waren, mehr über Themen zu lernen, mit denen ich mich auskenne, wie Daten und Machine Learning, und ihr Wissen über Themen wie Threat Modeling mit mir zu teilen. Das Sicherheitsteam in Ihrem Unternehmen weiß wahrscheinlich viel mehr über die Arten von Angriffen, die auf die Systeme in Ihrem Unternehmen abzielen, und ist wahrscheinlich bereit, Ihnen mehr dazu beizubringen. Dieses Wissen wird Ihnen helfen, interne und externe Risiken und Bedrohungen besser einzuschätzen. Um sich einen schnellen Überblick über das agile Threat Modeling zu verschaffen, empfehle ich Ihnen den Beitrag »Agile Threat Modeling« von Jim Gumbley (https://oreil.ly/ygpiU).
Der Begriff Incident Response bezieht sich auf die geplanten Maßnahmen, die zu ergreifen sind, sobald ein Sicherheitsvorfall entdeckt wird, z.B. ein Eindringen in Ihr Netzwerk, ein Datenleck oder auch wenn andere Informationen nach außen gelangt sind. Ein Vorfall kann sehr klein sein, etwa wenn jemand einen Benutzernamen oder eine E-Mail-Adresse in internen Logdateien gespeichert hat. Er kann aber auch sehr groß sein – wie die Veröffentlichung vollständiger Anmeldedaten in einem öffentlich zugänglichen Repository oder der Zugang zu einer Datenbank aufgrund eines unzureichenden oder nicht vorhandenen Passworts! Leider passieren solche Vorfälle immer wieder, was zum Teil daran liegt, dass viele Entwickler und Data Scientists nicht ausreichend über »Sicherheitshygiene« informiert sind – ein Begriff, der von Sicherheitsexperten verwendet wird, um Risikobewusstsein und Best Practices zu umschreiben.
Zwischenfälle passieren. Wenn sie auftreten, sollte Ihr Team bereits mehrere Incident-Response-Pläne ausgearbeitet haben und wissen, was zu tun ist. Diese Pläne werden von Sicherheitsexperten erstellt, oft in Zusammenarbeit mit anderen Teams, die die betroffenen Plattformen und/oder Dienste entwickeln und warten. Datenschutzfachleute erstellen häufig auch einen Plan für den Fall einer Datenpanne (Data Breach Response Plan), der für ihre Arbeit besonders nützlich sein kann und häufig Teil von Incident-Response-Plänen ist.
Wenn Sie einen Vorfall entdecken, holen Sie erst einmal tief Luft – berühren Sie nichts und nehmen Sie Kontakt mit der Sicherheitsabteilung auf. Diese muss möglicherweise forensische Beweise sammeln, um festzustellen, auf welche Dienste und Speicher zugegriffen wurde und welche Auswirkungen dies hatte, und um zu versuchen, den Einstiegspunkt, die Änderung von Berechtigungen und andere zurückgelassene Beweise zu ermitteln. Stellen Sie sich das Ganze wie einen Tatort vor, an dem jeder Fingerabdruck und jeder Fleck zählt! Erst wenn Sie grünes Licht für die Abschaltung von Diensten oder die Behebung des Problems erhalten haben, sollten Sie versuchen, den Vorfall einzudämmen. Möglicherweise müssen Sie ein Passwort aktualisieren, einen Schlüssel austauschen oder die Netzwerkrichtlinien ändern, wenn Daten nach außen gelangt sind. Natürlich möchte niemand von einem Vorfall betroffen sein, aber ein Plan im Voraus kann dazu beitragen, dass solche Vorfälle weniger chaotisch ablaufen und weniger Fehler passieren. Ich empfehle Ihnen, mit Ihrem Sicherheitsteam zusammenzuarbeiten, um einen Incident-Response-Plan auszuarbeiten, der Ihre Bedenken hinsichtlich des Schutzes der von Ihnen verwendeten Daten berücksichtigt.
Mit welchen Ergebnissen können Sie vernünftigerweise rechnen, wenn Sie Ihre Abfragemechanismen, Ihre APIs und Ihre Modelle vor Angriffen schützen wollen? Wie können Sie beurteilen, ob Ihre Daten ausreichend geschützt und gesichert sind?
Genau diese Fragen stellen sich Sicherheitsexperten tagtäglich. Generell wird empfohlen, die Schutzmaßnahmen an der Eintrittswahrscheinlichkeit und den möglichen Auswirkungen der Bedrohungen auszurichten. Lassen Sie uns daher zunächst einen Blick darauf werfen, wie man dieses Problem mithilfe von Wahrscheinlichkeiten (Probabilistic Reasoning) angehen kann.
Gibt es so etwas wie einen durchschnittlichen Angreifer? Nun, gibt es denn in Ihrer Zielgruppe einen »durchschnittlichen Anwender«? Wahrscheinlich nicht!
Sie können Ihre Anwenderinnen und Anwender vielleicht in Gruppen zusammenfassen und einen Durchschnitt für jeden »Typ« von Anwender ermitteln (z.B. Superuser oder Betatester bzw. frühzeitige Anwender). Allerdings entsprechen Menschen nur selten dem Durchschnitt. Daher greift die Idee eines durchschnittlichen Angreifers zu kurz.
Aber könnten Sie gegebenenfalls Daten heranziehen, mit denen Sie ermitteln können, was Sie von einem »typischen« Angreifer erwarten können, und in Ihrem Unternehmen eine auf Wahrscheinlichkeiten basierende Bewertung möglicher Angriffe vornehmen? Auf jeden Fall!
Wenn Sie beim Threat Modeling beteiligt sind, identifizieren und ordnen Sie potenzielle Angriffsvektoren nach ihrem Schadensausmaß (z.B. nach finanziellem Risiko oder Rufschädigung bzw. Imagegewinn) und nach ihrer Eintrittswahrscheinlichkeit. Hierbei kann es hilfreich sein, sich gut mit Wahrscheinlichkeitsrechnung auszukennen. Je nachdem, wie die Daten in Ihrem Unternehmen beschaffen sind, können Sie gegebenenfalls belastbare Informationen aus ihnen ziehen, mit denen Sie Ihre Überlegungen bezüglich anzusetzender Eintrittswahrscheinlichkeiten untermauern können.
Ohne Datengrundlage sind wir Menschen nicht besonders gut darin, Wahrscheinlichkeiten abzuschätzen. In einer Studie konnte sogar nachgewiesen werden, dass selbst Sicherheitsexperten bei der Bewertung von Risiko und Eintrittswahrscheinlichkeit eines bestimmten Szenarios zu unterschiedlichen Ergebnissen kommen, wenn sie dasselbe Szenario erneut bewerten sollen. Abbildung 4-7 zeigt Daten aus einer Studie, in der Douglas Hubbard und sein Forschungsteam Expertinnen und Experten baten, dieselben Szenarien über einen bestimmten Zeitraum hinweg zu beurteilen. Da Experteneinschätzungen oft als einziger Datenpunkt für die Risikobewertung herangezogen werden, wollte die Forschungsgruppe herausfinden, ob die Experten die Szenarien immer ähnlich bewerten. Wäre dies der Fall, würde man eine perfekte Diagonale durch den Ursprung erkennen, d.h., die Werte der x-Achse stimmen immer mit denen der y-Achse überein. Stattdessen ist deutlich zu erkennen, dass die Bewertung im Zeitverlauf häufig variiert, selbst wenn sie von ein und demselben Experten für ein und dasselbe Szenario vorgenommen wird.11 Folglich ist der Ansatz, mit dem Unternehmen derzeit Risiken beurteilen, in wesentlichen Maße inkonsistent.
Abbildung 4-7: Die Ergebnisse von Hubbards Studie, bei der Experten wiederholt das Risiko für ein bestimmtes Szenario beurteilen (und es teils unterschiedlich einschätzen)
Ähnlich problematisch ist die »Durchschnittsbildung« bzw. »Mittelwertbildung« von Risiken. Wenn Sie quantifizieren möchten, wie gut Sie Ihre Daten schützen, und dabei das durchschnittliche Risiko zugrunde legen, werden gefährdete Personengruppen unverhältnismäßig stark exponiert. Sie riskieren, wie in einem Artikel von DifferentialPrivacy.org (https://oreil.ly/HU3YO) treffend beschrieben, dass Ausreißer aufgrund ihrer ohnehin schon vulnerablen Position in der Datenverteilung besonders gefährdet sind, wenn Sie Annahmen über das Datenschutzrisiko treffen, die Sie aus dem durchschnittlichen Risiko ableiten.
Warum sollte man also auf der Grundlage von Wahrscheinlichkeiten über Datenschutz- und Sicherheitsrisiken nachdenken? Schauen wir uns an, wie Risiken heutzutage quantifiziert werden (eben nicht durch Mittelwertbildung) und in welchen Bereichen Data Science nützlich sein kann.
Möglicherweise kennen Sie bereits die altbewährte Risikomatrix, mit der versucht wird, Risiken in verschiedene Niveaus einzuteilen und festzulegen, welche Maßnahmen entsprechend dem ermittelten Risiko ergriffen werden sollten. Die Idee hinter diesem System ist an sich großartig. Allerdings handelt es sich bei den Angaben häufig nicht um Einschätzungen, die konsistent, quantifizierbar und realistisch sind, da sie oftmals mit persönlichen Sichtweisen einhergehen und mit großer Unsicherheit behaftet sind.
Ihre Aufgabe als Data Scientist ist es, durch Beobachtungen, Experimente und wissenschaftliche Analysen die Unsicherheit in der Bewertung zu reduzieren. In manchen Fällen gelingt dies, und Sie entwickeln ein Wahrscheinlichkeitsmodell, das die Realität relativ gut abbildet. In anderen Fällen gelingt es nicht, und man kann nur abschätzen, wie groß die zu erwartende Unsicherheit ist (oder man experimentiert weiter!).
Ihr Data-Science-Toolkit kann bei der Beurteilung von Bedrohungen und der Einschätzung von Risiken helfen, jedoch nur dann, wenn historische Daten zur Verfügung stehen. Sind keine Fachleute vorhanden, die bei der Erstellung von Modellen helfen können, oder ist die Unsicherheit groß und es liegen nur wenige Informationen vor, werden Sie wahrscheinlich keinen wesentlichen Beitrag leisten können.
Allerdings ist in den Sicherheitscommunitys ein wachsender Druck zu verzeichnen, Risikoszenarien zu erstellen, die sich besser quantifizieren lassen. Hierbei können Sie helfen, die Frage so zu modellieren, dass sie beantwortbar ist. Eine Möglichkeit wäre, die abhängigen und unabhängigen Variablen eines Modells, das eine komplexe Fragestellung oder Bedrohung abbildet, durchzugehen und zu ermitteln, welche Variablen sich häufig ändern und welche eher unverändert bleiben. Möglicherweise gibt es auch bereits frei zugängliche oder interne Daten, die dabei helfen könnten, die Verteilung dieser Variablen im Zeitverlauf einzuschätzen.
In der Sicherheitsforschung haben sich Modellierungsversuche als recht nützlich erwiesen. Ein großartiges Beispiel dafür ist der Forschungsbeitrag, in dem erstmals Rowhammer aufgedeckt wurde (https://oreil.ly/oQv9n), eine Möglichkeit, bei der der dynamische Speicher so ausgenutzt wird, dass Daten Ihrer »Nachbarn« in einem großen Rechenzentrum ausgelesen werden können. Dabei hat sich gezeigt, dass dieser Angriffsvektor – von dem man bis dahin annahm, dass er relativ selten vorkommt – bedeutend häufiger auftritt. Dementsprechend kann die Durchführung von datengestützten Sicherheitsexperimenten im Rahmen der Beurteilung von Bedrohungen dazu beitragen, dass diese Modelle realitätsnah sind.
In der Data Science sind die wichtigsten Risiken, die es in die Bewertung einzubeziehen gilt, der Zugriff auf die Daten, die Dateninfrastruktur und die Modelle. Im Folgenden finden Sie einige Maßnahmen, mit denen Sie sicherstellen können, dass Sie über einen angemessenen Schutz verfügen.
Nachdem Sie nun ein besseres Verständnis von Datensicherheit gewonnen haben, können Sie auch besser Entscheidungen dazu treffen, welche Bereiche der Datensicherheit Sie in Ihre Arbeit einbeziehen möchten. In diesem Abschnitt stelle ich Ihnen vor allem die Schutzmaßnahmen vor, die für die Arbeit in den Bereichen Data Science und Machine Learning wichtig sind – aber das Spektrum ist natürlich weitaus größer. Meine Ausführungen sollen Ihnen also einen Anhaltspunkt geben und keine vollumfängliche Auflistung sein.
Da Daten bei der Arbeit mit Daten häufig über Endpunkte und APIs bereitgestellt werden, ist es wichtig, zu verstehen, wie auf diese zugegriffen wird, sich von bereits etablierten Ansätzen inspirieren zu lassen und diese gegebenenfalls zu übernehmen.
Seit vielen Jahrzehnten skizziert das Open Web Application Security Project (OWASP) (https://owasp.org), welche Bedrohungen für Webanwendungen und Webseiten die größten sind. OWASP zeigt auch entsprechende Schutzmaßnahmen (https://oreil.ly/FMgtB) auf, insbesondere wie sich API-Endpunkte durch die Einrichtung von Zugriffskontrollen und Validierung von Inputdaten schützen lassen. Diese Kontrollen sollten von jedem in Betracht gezogen werden, der eine Modell-API erstellt, die direkt oder indirekt den Nutzern zur Verfügung gestellt wird.
Eine weitere nützliche Maßnahme besteht darin, sicherzustellen, dass alle Ihre Endpunkte, über die Modelle oder Daten abgerufen werden, gründlich getestet werden. Überlegen Sie gemeinsam mit den Softwareentwicklern und -entwicklerinnen, welche Arten von Angriffen auf die eingesetzten Modelle denkbar sind, z.B. Adversarial Attacks, Poisoning Attacks oder die in diesem Kapitel beschriebenen Arten von Angriffen.
Wenn Sie ein Modell für die sofortige Nutzung freigeben, sollten Sie die Anzahl der Zugriffe innerhalb eines bestimmten Zeitraums begrenzen (Rate Limiting) und die Identität Ihrer Nutzer überprüfen, indem Sie einen Anmeldevorgang voraussetzen, bei dem die Nutzer zunächst verifizieren müssen, dass es sich bei ihnen um eine reale Person handelt. Wenn es nicht möglich ist, Rate Limiting anzuwenden, sollten Sie sicherstellen, dass Sie die eingegebenen Daten validieren und bei ungültigen Abfragen bzw. Anfragen eine entsprechende Antwort zurücksenden, ohne dass weitere Informationen preisgegeben werden.
Und, wenn möglich, verbinden Sie Ihre Modelle bzw. Ihre Abfrageschnittstellen nie direkt mit dem (öffentlich zugänglichen) Internet. Besser ist es, eine Zugriffskontrolle mit Identitätsprüfung vorzusehen oder Ihr Modell in mehrere Inputprozesse einzubetten, sodass Daten aus dem Internet nur eine von vielen Datenquellen darstellen bzw. niemals direkten Einfluss auf die Inputdaten Ihres Modells haben.
Sie haben in diesem Kapitel bereits erfahren, dass es beim Schutz im Rahmen von Machine Learning nicht nur darum geht, das Modell selbst zu schützen, sondern auch die Infrastruktur, mit deren Hilfe Sie Ihre Modelle erstellen und trainieren.
Halten Sie sich einmal vor Augen, wie Ihre genutzte Software und Dependencies verifiziert werden. Auch im Hinblick auf die Daten, die in Ihre Modelle eingespeist werden, müssen Sie sicherstellen, dass sie angemessen geschützt sind. Daher sollten Sie Ihre Machine-Learning-Systeme und Ihre Datenworkflows so weit wie möglich automatisieren und sicherstellen, dass diese im Hinblick auf Datenschutz und -sicherheit sorgfältig konzipiert und getestet sind.
Die Zielsetzung bei der Nutzung von Daten ist von Unternehmen zu Unternehmen unterschiedlich. Im Folgenden werden einige Fragen erläutert, die bei der Konzeption zu berücksichtigen sind:
Zusätzlich zur Klärung dieser Aspekte sollten Sie auch eine geeignete Versionskontrolle für Ihre Workflows implementieren und feststellen, ob die Versionskontrolle für die resultierenden Datensätze oder Modelle angemessen ist (siehe Kapitel 1). Wenn Sie sicherstellen, dass Ihre Workflows eine selbstdokumentierende Data Lineage und Data Governance unterstützen, ist dies bereits ein großer Schritt in Richtung Data Governance (siehe Kapitel 1). Dies trägt auch dazu bei, dass Maßnahmen, die zur Datensicherheit und zum Datenschutz beitragen, schneller umgesetzt und mitgetragen werden, da die Systeme gut verstanden werden.
Sie haben nun alles getan, was Sie auf Basis Ihres Wissens über die Bedrohungen und das regulatorische Umfeld tun können. Sie sind sich aber sicher bewusst, dass sich diese ständig ändern! Deshalb müssen Sie sich stets über neue Angriffe und Bedrohungen auf dem Laufenden halten. Wie können Sie sich am besten über neue Angriffsmethoden informieren?
Im Bereich des Machine Learning und der Data Science gibt es bekanntermaßen ständig neue Entwicklungen. Es ist unwahrscheinlich, dass Sie die Zeit haben werden, alle Veröffentlichungen zu diesen Themen zu lesen oder jede Konferenz zu besuchen, insbesondere wenn das Interesse an diesen Themen weiter zunimmt. Wie hält man sich also auf dem Laufenden und behält den Überblick?
Zum Thema Sicherheit empfehle ich Ihnen, sich über einige der führenden Konferenzen zu informieren, die mittlerweile auch spezielle Themen im Bereich Datenschutz und Sicherheit anbieten. Zum Beispiel gibt es auf der seit Langem stattfindenden DEFCON-Konferenz inzwischen einen eigenen Schwerpunkt für KI-gestützte Angriffe namens AI Village (https://aivillage.org).
Zudem gibt es mit OpenMined (https://www.openmined.org) eine großartige Community, die sich mit Datenschutztechnologien beschäftigt. Ihre Slack-Gruppen sowie ihre Kurse und Konferenzen sind ausschließlich auf Datenschutzthemen ausgerichtet, die mit Data Science und Machine Learning in Zusammenhang stehen.
Darüber hinaus könnten für Sie auch noch einige Newsletter und Blogs interessant sein, darunter auch meiner! Hier ist eine kurze Liste:
Probably Private (https://probablyprivate.com)
Mein Newsletter rund um das Thema Datenschutz und seine Berührungspunkte mit Data Science, der auch aktuelle Informationen zu den in diesem Buch behandelten und verwandten Themen enthält.
Upturn (http://www.upturn.org)
Ein Newsletter, der sich mit dem Thema Gerechtigkeit und Datenschutz in der IT-Branche beschäftigt.
Bruce Schneier zum Thema Sicherheit (https://www.schneier.com)
Ein Fachblog zum Thema Sicherheit, der eine Vielzahl von Sicherheitsthemen behandelt.
Lukasz Olejnik mit einer kritischen Auseinandersetzung mit Themen aus Cybersicherheits-, Datenschutz- und Digitalpolitik (https://blog.lukaszolejnik.com)
Das Blog umfasst Themen wie Sicherheit, Datenschutz, Webtechnologien und Digitalpolitik.
Das Daily Dashboard von IAPP (https://iapp.org/news/daily-dashboard)
Hier gibt es tägliche Updates von der International Association of Privacy Professionals (IAPP).
Ich würde Ihnen vor allem empfehlen, Ihre Leidenschaft und Nische in der Community zu finden und Forschern und Organisationen zu folgen, die auf diesem Gebiet interessante Arbeit leisten. So bleibt man eher auf dem Laufenden, als wenn man die Arbeit von Freunden verfolgt.
Sollten Sie einmal etwas Wichtiges verpassen, wird es wahrscheinlich im Rahmen Ihrer Arbeit zur Sprache kommen. Wenn es Ihnen gelungen ist, eine Beziehung zu Ihren Infosec-Kollegen aufzubauen, werden diese Sie in der Regel auf dem Laufenden halten, wenn es für Sie von Interesse ist.
In diesem Kapitel haben Sie eine Vielzahl verschiedener Angriffe auf die Privatsphäre kennengelernt – Angriffe, die darauf abzielen, zusätzliche Informationen aus den Daten zu gewinnen, Angriffe auf Machine-Learning-Modelle und Angriffe, die sich gegen Datenschutzmaßnahmen selbst richten. Sie haben auch erfahren, wie wichtig es ist, mit Sicherheitsexperten und -expertinnen zusammenzuarbeiten, wenn es um Datenschutzrisiken und deren Verhütung geht.
Sicherheit ist ein Bereich, der sich ständig weiterentwickelt – bis zur Veröffentlichung dieses Buchs werden neue Angriffsformen entwickelt und durchgeführt worden sein. Betrachten Sie dieses Kapitel als Ausgangspunkt, um Ihr Verständnis von Datenschutz und Sicherheitsrisiken zu vertiefen, während Sie gleichzeitig am wirksamen Schutz Ihrer Daten arbeiten.
Im nächsten Kapitel werden wir uns näher mit der Frage befassen, wie der Schutz der Privatsphäre im Zusammenhang mit Machine Learning und Data Science gewährleistet werden kann.
