LLMs sind auch nur (schützenswerte) Informationen

Kaum ein Thema in der IT erzeugt derzeit mit ähnlicher Taktrate neue Schlagzeilen wie die aktuelle Entwicklung von sogenannten Large Language Models (LLMs). LLMs stellen eine Variante von künstlichen neuronalen Netzen dar, die auf der Transformer-Architektur basieren. Diese wurde im Artikel “Attention is All You Need” von Google vorgestellt.

Wie bei allen (Technologie-)Hypes verbreiten und vermischen sich Fakten und Fiktion nahezu ungebremst, was nicht zuletzt durch die unbestreitbar beeindruckenden Fähigkeiten von ChatGPT und Co verstärkt wird. Auch aus Sicht der Informationssicherheit ist die Entwicklung hochgradig spannend, denn für bösartige Akteure ergeben sich neue Kategorien von Schwachstellen und damit Angriffsmöglichkeiten. Gleichzeitig stehen wir diesen Gefahren und der rasanten Entwicklung jedoch nicht hilflos gegenüber. Mit bekannten methodischen Werkzeugen und einem kühlen Kopf lassen sich Bedrohungen ermitteln und Gegenmaßnahmen ableiten.

Schutzziele gelten auch für LLMs

In der Welt der Informationssicherheit und des Datenschutzes sind drei Schutzziele von zentraler Bedeutung: Vertraulichkeit, Verfügbarkeit und Integrität. Diese gelten für alle Arten von Daten und Informationen. LLMs sind wiederum nichts anderes als Informationen in Form von Zahlen in ziemlich großen Matrizen. Dazu gehören sowohl mit gigantischem Ressourcenaufwand trainierte Foundation Models wie GPT-4 (OpenAI), LLaMA (Meta), Claude (Anthropic) und PaLM (Google) mit reglementiertem Zugriff, als auch eine unaufhörlich wachsende Menge an frei verfügbaren Klonen, nutzbar für jeden mit geeigneter Hardware (mit ausreichend Geduld sind selbst handelsübliche Grafikkarten mittlerweile ausreichend).

Bezogen auf LLMs können die Schutzziele der Informationssicherheit wie folgt beschrieben werden:

  • Vertraulichkeit bezieht sich auf den Schutz von Informationen vor unbefugtem Zugriff. Für LLMs bedeutet das, dass die Modelle gleichermaßen geschützt werden müssen, wie die Daten, mit denen sie trainiert wurden. Dies gilt sowohl für die Modelle an sich, als auch für sämtliche Datenflüsse zum Modell (Training) und ausgehend vom Modell (Inferenz bzw. Abfragen). Vergleichbar ist dies mit personenbezogenen Daten, beispielsweise bei einem System zur Verarbeitung medizinischer Daten zwecks Diagnostik. Diese unterliegen höchsten Vertraulichkeitsansprüchen, was sich auch auf verarbeitende KI-Modelle überträgt. Das betrifft nicht nur lokal betriebene Modelle sondern auch Dienste wie ChatGPT, die sich vorbehalten Benutzereingaben per Opt-Out für weitere Trainingsdaten zu verwenden. Dass die Vertraulichkeit damit eindeutig beeinträchtig ist, schlussfolgerte auch Samsung, nachdem Ingenieure geheime Unternehmensdaten in den Chatbot von OpenAI eingegeben hatten.
  • Verfügbarkeit stellt sicher, dass autorisierte Benutzer in einem angemessenen Zeitrahmen Zugriff auf die benötigten Informationen haben. Im Kontext von LLMs bedeutet das, dass die Modelle immer dann verfügbar sein müssen, wenn sie benötigt werden. Wird ein eigens trainiertes LLM im Rahmen eines wichtigen oder sogar kritischen Prozesses verwendet, sollte sichergestellt sein, dass es Sicherungskopien und Redundanzen gibt. Andernfalls können Ausfälle oder Verzögerungen von mehreren Tagen bis Wochen entstehen, um das Modell von Grund auf neu zu trainieren. Hinzu kommen die teilweise enormen Kosten durch die benötigte Rechenleistung. Auch eine Auslagerung in Cloud-Dienste löst dieses Problem nicht vollständig. Beispielsweise in der Finanzbranche gelten hohe Ansprüche an die Verfügbarkeit.
  • Integrität bezieht sich auf die Richtigkeit und Vollständigkeit von Informationen. An dieser Stelle sei das bekannte Problem von LLMs, Dinge zu “halluzinieren” kurz außer Acht gelassen. Grundlegend ist es wichtig, dass die Modelle und ihre Trainingsdaten vor Manipulationen geschützt sind. Jede Änderung der Daten oder des Modells könnte das Verhalten des LLMs beeinflussen und zu unerwünschten oder sogar schädlichen Ergebnissen führen. Dieses Problem betrifft allerdings nicht nur LLMs oder neuronale Netze, sondern auch die Auswertung von Daten allgemein und ist ein hartnäckiges Problem. Spätestens wenn auf Basis der gelieferten Ergebnisse von KI-Modellen Entscheidungen getroffen werden, die sich auf einzelne Personen oder Personengruppen auswirken, muss die Integrität der involvierten Daten gewährleistet sein.
Halluzinierende LLMs?

Halluzinationen im Kontext von LLMs bezeichnen die Eigenschaft, dass die Modelle Lücken in den Trainingsdaten mit plausibel klingenden aber falschen Aussagen überdecken. Menschen wissen, dass sie vieles nicht wissen und sind in der Lage, Wissenslücken als solche zu identifizieren und mit einem einfachen “weiß ich nicht” zu quittieren. LLMs besitzen nicht die Möglichkeiten für solche kognitiven Tricks und sind darauf trainiert, immer hilfsbereit zu sein und eine positive Antwort zu liefern. Da diese Angewohnheit für viele Anwendungsfälle einer sicheren und zuverlässigen Nutzbarkeit im Weg steht, wird aktiv an dem Problem geforscht. Derzeit ist allerdings unklar, ob und mit welchen Methoden eine Lösung möglich ist. Zumal das Verhalten für kreative Zwecke wiederum nicht unerwünscht ist.

Auf dieser Ebene betrachtet, können und müssen für die Nutzung aber auch Absicherung von LLMs mindestens klassische Sicherheitsmaßnahmen wie Verschlüsselung, Backups und Redundanzen sowie Zugriffskontrollen ergriffen werden. Am einfachsten ist der Vergleich mit typischen Wissens- und Informationsspeichern von Organisationen und Unternehmen, seien es IAM-Systeme, Fileshares, Source-Code-Verwaltung, CRM-Plattformen, Dokumentenverwaltung, Wikis und vieles mehr. Letztlich die gesamte digitale Landschaft, welche zur Erbringung der Geschäftsprozesse benötigt wird. Denn gute Informationssicherheit verfolgt grundlegend einen ganzheitlichen Ansatz.

Typische Bedrohungen in der Informationssicherheit

Um für solche digitalen Landschaften die relevanten Bedrohungen und geeigneten Sicherheitsmaßnahmen zu ermitteln, gibt es verschiedene Wege. Als Grundlage für Risikoanalysen hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) als Teil des IT-Grundschutzes einen Katalog von elementaren Gefährdungen erstellt. Dieser enthält typische Bedrohungen, die von Umweltereignissen über versehentliche Fehlhandlung bis hin zu Schadsoftware reichen. Während nicht alle davon direkt auf LLMs anwendbar sind, können einige jedoch als Ausgangspunkt dienen, beispielsweise der Ausfall von Kommunikationsnetzen, die Manipulation von Informationen oder auch die unberechtigte Nutzung von Systemen. Zur Inspiration sind folgend einige konkrete Beispiele aufgeführt:

Beispielhafte elementare Gefährdungen mit Bezug zu LLMs
  • G0.9 Ausfall von Kommunikationsnetzen: Besteht keine Verbindung, sei es zur Cloud oder dem eigenen Rechenzentrum in dem ein LLM betrieben wird, kann es nicht genutzt werden und die Verfügbarkeit ist beeinträchtigt.
  • G0.11 Ausfall oder Störung von Dienstleistern: Wird der Betrieb einem Dienstleister übertragen, sei es in Form von Rechenzentrumskapazitäten oder SaaS-Produkten, besteht eine Abhängigkeit, die beim Ausfall oder einer Störung zur Beeinträchtigung der Verfügbarkeit führt.
  • G0.14 Ausspähen von Informationen (Spionage): Hier wird eindeutig die Vertraulichkeit beeinträchtigt. Die Bedrohung umfasst explizit auch die Möglichkeit, dass einzelne öffentlich verfügbare unverfängliche Informationen zusammengetragen werden und dadurch erst eine kompromittierende Wirkung entfalten. Genau dies kann bei großen Trainingsdatensätzen der Fall sein.
  • G 0.20 Informationen oder Produkte aus unzuverlässiger Quelle: Die Vielfalt sowohl von Trainingsdatensätzen als auch vortrainierten Modellen ist bereits heute gigantisch. Plattformen wie HuggingFace bieten Möglichkeiten zum Austausch von Datensätzen, Modellen und mehr. Dadurch ergeben sich ähnliche Gefahren, die für verschiedene Arten von Software- und Paket-Quellen in den letzten Jahren zu weitreichenden Auswirkungen geführt haben. Am bekanntesten sind Vorfälle des NodeJS-Paketmanagers NPM oder das Python-Äquivalent PyPI. Angreifer haben dabei Besitz von weitverbreiteten Paketen erlangt und Schadcode eingefügt oder Pakete mit ähnlich klingenden Namen genutzt, um unvorsichtige Benutzer anzugreifen. Je nach Ausprägung des Schadcodes sind demnach alle Schutzziele betroffen: Vertraulichkeit, Verfügbarkeit und Integrität. Diese Angriffe gelten auch aus Supply-Chain-Angriffe und wurden für LLMs bereits erfolgreich demonstriert.
  • G 0.22 Manipulation von Informationen: Wie oben zum Schutzziel der Integrität bereits erläutert, ist die Qualität und Korrektheit von Trainingsdaten eine Grundvoraussetzung für die Zuverlässigkeit der LLMs. Gelingt es Angreifern diese in den Originalquellen oder auch im vorbereiteten Trainingsdatensatz zu manipulieren, kann dies zu falschen oder irreführenden Entscheidungen und Aussagen im Sinne der Angreifer führen. Unabhängig davon, ob es dadurch zu unerwünschten Unternehmensentscheidungen oder der Verbreitung von Desinformationen kommt, ist die Integrität entsprechend beeinträchtigt. Eine weitere konkrete Gefahr ergibt sich durch die Auslagerung des Trainings an externe Dienstleister. Diese können durch Manipulation der Trainingsdaten Hintertüren in den Modellen einschleusen, die sich nach aktuellem Stand nicht zuverlässig entdecken lassen.
  • G 0.28 Software-Schwachstellen oder -Fehler: Die Software-Projekte rund um LLMs sind in der Transitionsphase von Forschungsprojekten zu marktreifen Produkten. Der Drang möglichst schnell fertige Produkte anbieten zu können, führt häufig zu Entwicklungspraktiken, die nicht den Best Practices folgen und Schwachstellen verursachen. Die konkreten Auswirkungen sind abhängig von der Art der Schwachstelle. Gemessen an der potenziellen Angriffsoberfläche (interaktive Benutzereingaben, Verarbeitung von strukturierten und unstrukturierten Inhalten, komplexe Rollen- und Rechtekonzepte für die umliegenden Anwendungen usw.) sind von Informationslecks bis hin zur Übernahme der involvierten Systeme durch Angreifer alle Auswirkungen denkbar. Entsprechend sind auch alle Schutzziele – Vertraulichkeit, Verfügbarkeit und Integrität – betroffen.
  • G 0.29 Verstoß gegen Gesetze oder Regelungen: Zwar fällt der Bezug zu einem einzelnen Schutzziel schwer, jedoch ist die Bedrohung dafür nicht weniger relevant. Viele Aspekte rund um Datenschutz und Urheberrecht sind im Kontext von LLMs derzeit unklar. Einige Unternehmen handeln vorzeitig, in dem große Datenmengen gesammelt und zu Trainingszwecken verarbeitet werden, ohne die konkreten Quellen und etwaige Lizenzhinweise anzugeben bzw. zu beachten. Dies geschieht in der Hoffnung, durch Lobbyarbeit und starke Medienpräsenz ausstehende Gesetzgebungen oder rechtliche Entscheidungen zu beeinflussen. Eine Einstellung, die Meta (ehemals Facebook) in der Vergangenheit teuer zu stehen gekommen ist.

Auf der Basis solch relevanter Bedrohungen kann im Prinzip eine vollständige Risikoanalyse nach IT-Grundschutz durchgeführt werden, welche die Bedrohungslage beim Einsatz von LLMs oder KI-Modellen jeder Art erfasst. Die dafür benötigte Infrastruktur sollte dabei gleich mit betrachtet werden, unabhängig ob Cloud oder On-Premise. Es gilt dabei, sich bewusst Gedanken über das Einsatzumfeld und den Anwendungsfall zu machen. Mit dieser Informationsgrundlage gestaltet sich auch die Ableitung relevanter Sicherheitsmaßnahmen wesentlich einfacher und zielgerichteter.

Spezielle Schwachstellen von LLMs

Der zuvor beschriebene klassische und zum Teil recht abstrakte Ansatz kann mit konkreten Schwachstellenkategorien für LLMs ergänzt bzw. kombiniert werden. Das „Open Web Application Security Project“ (OWASP) stellt eine solche Auflistung von Schwachstellen bereits seit langer Zeit für Web-Applikationen in den OWASP Top 10 zusammen. Ein entsprechendes Pendant speziell für LLMs wurde zum 01.08.2023 veröffentlicht.

Die Top 10 umfassen dabei an erster Stelle Prompt Injections. Die namentliche Ähnlichkeit zur klassischen SQL Injection ist kein Zufall. Um LLMs, insbesondere im Rahmen von interaktiven Chats, daran zu hindern unerwünschte Inhalte von sich zu geben, werden der Benutzereingabe verschiedene Instruktionen vorangestellt. Prompt Injections zielen darauf ab, diese Instruktionen auszuhebeln. Besonders bekannt geworden ist dies bei der Veröffentlichung des Chatbots von Bing. Die Auswirkungen sind in einem lesenswerten Blogbeitrag von Simon Willison dargestellt.

Die konkreten Schwachstellen-Kategorien weisen dabei Ähnlichkeiten bzw. auch direkte Zusammenhänge auf, sowohl zu den OWASP Top 10 Schwachstellen von Web-Anwendungen, als auch zu den weiter oben aufgeführten elementaren Gefährdungen des IT-Grundschutzes. Grund dafür ist schlichtweg, dass LLMs von den gleichen Arten von Schwachstellen betroffen sind wie der Großteil aller informationsverarbeitenden Systeme. Die primären Unterschiede liegen in den konkreten Ausprägungen und entsprechend den zugehörigen Gegenmaßnahmen.

Übersicht der OWASP Top 10 für LLMs
  • LLM01 Prompt Injection: Mittels direkter oder indirekter Manipulation der Eingaben bzw. Prompts werden ungewollte Verhaltensweisen ausgelöst. Exemplarisch dafür ist die Ausgabe von beleidigenden, verleumderischen oder verbotenen Inhalte (Anleitungen zur Herstellung gefährlicher Stoffe o.ä.). Je nach Verwendungszweck der Ausgabe, beispielsweise zur Feststellung von Kreditwürdigkeiten, Auswertung von Anträgen und Verträgen oder anderen automatisierten Entscheidungen können die Konsequenzen entsprechend gravierend ausfallen.
  • LLM02 Insecure Output Handling: Die Ausgaben von LLMs können nicht nur Fließtext, sondern auch strukturierte Daten beinhalten. Werden diese ungefiltert übernommen, können in den nachgelagerten Systemen klassische Schwachstellen wie Cross-Site-Scripting (XSS) oder sogar Remote Code Execution (RCE) ausgelöst werden.
  • LLM03 Training Data Poisoning: Wenn die Trainingsdaten für ein LLM durch Angreifer manipuliert, sprich “vergiftet” werden können, sind ungewollte Verhaltensweisen und Ausgaben die Folge. Die Auswirkungen können ähnlich wie bei Prompt Injection ausfallen. Je nach Ausprägung können Angreifer auch bestimmte Schlüsselwörter in die Trainingsdaten einschleusen, wodurch nur bei Abfrage bestimmter Informationen voreingenommene und unethische Ergebnissen geliefert werden.
  • LLM04 Model Denial of Service: Dies ist das LLM-Gegenstück zu klassischen Denial-of-Service-Angriffen (DoS). Das Training aber auch die Inferenz (die Erzeugung von Ausgaben) sind zumindest aktuell noch sehr ressourcen- und damit kostenintensiv. Hinzu kommt, dass zwischen der Länge der Benutzereingabe und der Ausgabe keine direkte Relation besteht. Angreifer können dies nutzen, um hohe Kosten zu verursachen oder die vorhandenen Kapazitäten so auszulasten, dass eine normale Benutzung beeinträchtigt wird.
  • LLM05 Supply Chain Vulnerabilities: Um LLMs herum entwickelt sich ein umfangreiches und weit verzweigtes Ökosystem von Modellen, Datensätzen, Algorithmen, Ausführungsumgebungen und mehr. Werden die Bezugsquellen nicht geprüft oder sind nicht ohne weiteres überprüfbar, besteht die Gefahr, dass Angreifer in dieses Ökosystem schadhafte Inhalte einbringen, die unbemerkt übernommen werden und weite Verbreitung finden.
  • LLM06 Sensitive Information Disclosure: Durch unzureichend bereinigte Trainingsdaten sowie die Aggregation verschiedenster Datenquellen entsteht die Gefahr, dass vertrauliche Daten preisgegeben werden. Werden beispielsweise interne Code-Repositories und Dokumentationen zum Training genutzt, könnten API-Schlüssel und Zugangsdaten enthalten sein die über das Modell ungewollt abfragbar sind.
  • LLM07 Insecure Plugin Design: Um LLMs mit zusätzlichen Fähigkeiten auszustatten, werden Plugins verwendet. Diese ermöglichen die Suche im Internet, den Aufruf von Programmen bspw. zur Lösung mathematischer Gleichungen, die Interaktion mit APIs und vieles mehr. Die Idee ist, dass die LLMs selbst entscheiden, welche Werkzeuge für die gestellte Aufgabe genutzt werden. Sind die Zugriffsrechte sowie Ein- und Ausgabemöglichkeiten unsauber definiert bzw. abgegrenzt, bestehen indirekte Angriffsmöglichkeiten auf diese Plugins und die Daten, auf welche diese wiederum Zugriff haben. Des Weiteren besteht die Gefahr, dass Plugins auf externe Quellen zugreifen und bösartige Inhalte an das LLM zurückliefern. Werden diese Inhalte nicht genauso stringent geprüft und validiert wie andere Benutzereingaben, sind auch dadurch indirekte Angriffe möglich.
  • LLM08 Excessive Agency: Insbesondere bei der Nutzung von Plugins und anderen potenziell rekursiven Mechanismen – also LLMs die ihre Ausgaben wieder als Eingaben verwenden – müssen sinnvolle Einschränkungen definiert werden. Abhängig von konkreten Einsatzzwecken und Plugins können anderenfalls vielfältige Auswirkungen die Folge sein. Beispielsweise könnte ein LLM das mit APIs oder Datenbanken interagieren kann, zum unbefugten Anlegen, Ändern und Löschen von Daten verleitet werden.
  • LLM09 Overreliance: Werden LLMs übermäßig zur Entscheidungsfindung oder Erstellung von Inhalten genutzt, besteht die Gefahr darüber Falschinformationen zu verbreiten oder falsche Entscheidungen mit gravierenden Folgen zu treffen. Ein konkretes Beispiel ist die Nutzung bei der Software-Entwicklung. Wird der erzeugte Quelltext ungeprüft übernommen, besteht die Gefahr, dass unerkannte Schwachstellen in produktiv genutzten Anwendungen und Web-Applikationen einfließen. Pauschalisiert ausgedrückt: Die Korrektheit der Ergebnisse von LLMs kann nur von Menschen geprüft werden, welche die korrekten Ergebnisse auch selbst erzeugen könnten. Wer zu einem bestimmten Thema nichts weiß, kann Aussagen ohne externe Referenzen nicht validieren.
  • LLM10 Model Theft: Die eigentlichen Date, aus denen das Modell besteht, inklusive Konfigurationsparameter, beinhalten eine Repräsentation der Informationen mit denen es trainiert wurde. Für interne Zwecke auf Unternehmensdaten trainierte LLMs beinhalten demnach eine große Menge vertraulicher Daten. Gelingt es einem Angreifer das Modell zu entwenden, wird entsprechend auch die Vertraulichkeit der Trainingsdaten beeinträchtigt. Demnach muss der Zugriff auf die eigentlichen Modelle sowie die Trainingsdaten und deren Quellen mindestens genauso strikt geregelt werden.

Sicherheitsmaßnahmen

Die bisherigen Schritte liefern ein Fundament zur Ableitung von Sicherheitsmaßnahmen im Umgang mit LLMs. Die genauen Maßnahmen hängen von den konkret ermittelten Bedrohungen und der Ausprägung der Nutzung ab. Ist es “nur” ein SaaS-Dienst, in dem Trainingsdaten hochgeladen werden und im Anschluss eine abstrahierte Modell-Interaktion möglich ist? Wird ein fertiges Produkt On-Premise verwendet? Soll eine interne Informationsplattform oder gar ein kommerzielles Produkt entwickelt werden?

Auch hier gibt es hilfreiche Informationen, die zurate gezogen werden können. Bezogen auf den oben erwähnten IT-Grundschutz bietet das BSI mit dem IT-Grundschutz-Kompendium eine Sammlung von Bausteinen und Sicherheitsanforderungen für organisatorische Prozesse bis hin zu einzelnen Arten von IT-Systemen. Diese können zwar auf die zugrundliegenden Systeme, Infrastrukturen und Prozesse angewendet werden, haben jedoch nicht direkt etwas mit LLMs oder KI-Modellen zu tun.

Spezifischer hingegen ist das oben genannte OWASP-Projekt, welches auch die OWASP Top 10 für LLMs zusammengestellt hat. In einem weiterführenden Dokument werden neben detaillierten Informationen und Beispielen zu den Schwachstellen auch konkrete Gegenmaßnahmen aufgelistet.

Es ist zudem davon auszugehen, dass sich im Laufe der Zeit Muster und Best Practices herauskristallisieren, die es erlauben stärker und genauer auf Sicherheitsaspekte und -maßnahmen einzugehen, als dies aktuell noch möglich ist. Bis dahin erlauben die hier dargestellten Informationen und Grundlagen eine Möglichkeit, dennoch strukturiert und ganzheitlich die Informationssicherheit beim Einsatz von LLMs einzubeziehen.

Fazit

Wir hoffen die obigen Ausführungen vermitteln, dass trotz aller Entwicklungen und atemberaubender Schlagzeilen auch LLMs letztlich „nur“ informationsverarbeitende Systeme sind. Entsprechend gelten grundlegend die gleichen Bedrohungen, die wiederum mit bewährten und bekannten Methoden erfasst, bewertet und behandelt werden können. Gepaart mit der Betrachtung spezieller Schwachstellen ergeben sich Werkzeuge, mit denen sich proaktive Informationssicherheit und Security by Design-Prinzipien auf LLMs und Co anwenden lassen.

All dies soll nicht darüber hinwegtäuschen, dass KI-Technologien sich weiterhin und in absehbarer Zukunft stark weiterentwickeln werden. Entsprechend wird sich auch die Sicherheitslage wandeln, wie es für die gesamte IT-Branche seit jeher der Fall ist. Der Einsatz neuer Technologien ist nicht frei von Risiken. Diese sollten daher sorgsam bewertet und gemeinsam mit entsprechenden Sicherheitsmaßnahmen dem tatsächlichen Nutzen für den eigenen Anwendungsfall gegenüber gestellt werden.

Eines ist allerdings klar, es bleibt spannend!

Race Against The Machine – Will ML Help Or Harm Security?

Vortrag von David Fuhr, Head of Research bei HiSolutions, bei der M³ (Minds Mastering Machines), London, 16.10.2018

Machine Learning is being applied in many use cases of information technology, with varying, but sometimes mind-blowing success. Like any emerging tech, it can be used for better or worse when it comes to “cyber”.

The talk will examine the relations between ML and security:

  • What security risks lie in the use of ML?
  • Where and how can ML help attackers? Where not? And why (not)?
  • Where and how can ML help defenders? Where not? And why (not)?
  • What attack vectors on ML itself exist? Can these be countered with ML?
  • Only understanding the complex interrelation between different aspects of security and ML will allow us to create and use a technology that is beneficial in the end.

Required audience experience: Basic knowledge of ML is helpful as is an interest in cybersecurity.

Objective of the talk

The audience will:

  • Get a notion of the basic objectives of cybersecurity that are linked to ML
  • Develop a deeper understanding of classes of attack (red) and defense (blue) techniques and the way the can or cannot be enhanced with ML
  • Get an insight into security risks of ML itself

PowerPoint Slides