- Advertisement -spot_img
HomeKünstliche IntelligenzLässt sich KI zertifizieren? Herausforderungen beim Einsatz von KI in sicherheitskritischen Produkten

Lässt sich KI zertifizieren? Herausforderungen beim Einsatz von KI in sicherheitskritischen Produkten

- Advertisement -spot_img

Autor: Martin A Schneider

Künstliche Intelligenz und Maschinelles Lernen haben in den letzten zehn Jahren bedeutende Erfolge erzielt und sind Teil von verschiedensten Produkten geworden. Maschinelles Lernen (ML) sorgt für effiziente Lösungen, zum Beispiel bei der Vorhersage des nächsten Wortes, das ein Nutzer auf seinem Smartphone eingeben möchte.

Autonomes Fahren und Fliegen sind ohne ML nicht denkbar. In diesen sicherheitskritischen Domänen sind besondere Vorkehrungen zu treffen, um sowohl Nutzer als auch Menschen im Umfeld vor Schäden zu bewahren. Anforderungen an die Sicherheit solcher Systeme sind sehr hoch. Damit Aufsichtsbehörden diese Sicherheit überwachen können, sind entsprechende Standards entwickelt worden. Diese Standards sind spezifisch auf die Entwicklung klassischer (Software-) Systeme zugeschnitten. Künstliche Intelligenz (KI) und vor allem ML unterscheiden sich jedoch erheblich in Entwicklung und Funktionsweise von klassischer Software.

Während bei klassischer Softwareentwicklung Probleme in ihre Teile zerlegt, einzeln gelöst und dann wieder zu einer Lösung für das Gesamtsystem zusammengeführt werden, ist der Weg für KI und ML häufig umgekehrt: Probleme werden nicht zerlegt, sondern in ihrer Gesamtheit gelöst. Dabei helfen verschiedene Lernverfahren (überwachtes, nicht überwachtes und verstärkendes Lernen), die ein MLModell, zum Beispiel ein neuronales Netz, dahingehend optimieren, dass es ein gegebenes Problem löst. In der klassischen Softwareentwicklung wird das Problem dabei in Anforderungen beschrieben, für die Entwickler dann Lösungswege bzw. Algorithmen entwerfen, implementieren und gemäß den Anforderungen auf ihre Korrektheit prüfen.

Der Einsatz von Machine Learning

Beim Einsatz von ML wird das Problem und dessen Lösung in Datensätzen beschrieben, für die die korrekte Lösung (zum Beispiel beim überwachten Lernen), aber nicht der Lösungsweg bekannt ist. Ein ML-Modell wird dann nach Optimierungsverfahren unter Zuhilfenahme einer Kostenfunktion für die vorliegenden Daten optimiert, um für möglichst alle diese Trainingsdaten die korrekte Lösung zu liefern.

Mit einem zweiten Datensatz, dem Testdatensatz, wird dann geprüft, wie gut die Lösungen des optimierten ML-Modells für im Training nicht bekannte Datensätze sind, wie gut also das Modell im Generalisieren ist. ML-Modelle arbeiten im Gegensatz zu klassischer Software also statistisch. Die starke Relevanz der Daten und deren Qualität und Verteilung steuern die Qualität des damit trainierten Modells. Eine Gleichverteilung zwischen den Datensätzen, die für das Lernen und das Testen verwendet werden sowie die Betriebsdaten bilden die Grundlage für den erfolgreichen, sicheren Einsatz von ML.

Im Gegensatz zur traditionellen Softwareentwicklung haben Konfigurationsdaten einen erheblich größeren Einfluss auf die Qualität des resultierenden Modells. Zu den Konfigurationsdaten zählen die Hyperparameter, die u. a die Anzahl der Schichten, die Architektur und die verwendeten Aktivierungsfunktionen im Fall von neuronalen Netzen bestimmen, aber auch die Kostenfunktion, die verwendeten Datensätze und die Struktur des Lernens (Anzahl der Wiederholungen, Größe der Batches, etc.). Aus diesen Eigenschaften von ML ergeben sich spezifische Risiken für den Betrieb von ML-basierten Systemen. Diese Risiken beeinflussen unmittelbar die funktionale Sicherheit dieser Systeme, IT-Sicherheitsrisiken mittelbar.

Safety-Risiken beim Einsatz von Machine Learning

Beim Einsatz von ML in sicherheitskritischen Systemen sind spezifische Sicherheitsrisiken bei Training und Betrieb zu beachten, von denen hier einige erläutert werden sollen. Overfitting und Underfitting sind Effekte, die beim maschinellen Lernen auftreten, wenn der Umfang des Datensatzes für das Training und die Leistungsfähigkeit des ML-Modells nicht zueinanderpassen. Nehmen wir das Beispiel von Verkehrszeichen und ihrer Symbole. Beim Overfitting ist das ML-Modell so leistungsfähig, dass es nicht nur die wesentlichen Aspekte des Datensatzes lernt – also die Bedeutung der Symbole.

Das Modell lernt auch irrelevante Aspekte wie beispielsweise Daten zur Umgebung, in denen sich das Verkehrszeichen befindet. Das führt zu einer verringerten Generalisierungsleistung. Beim Underfitting ist der Trainingsdatensatz zu komplex für das ML-Modell, sodass es nicht in der Lage ist, eine zufriedenstellende Leistung zu erzielen. Ein Bias liegt vor, wenn sich die Verteilung von Trainingsdaten, Testdaten und Betriebsdaten unterscheidet. Zum Beispiel, weil die Trainingsdaten nicht repräsentativ für die Betriebsdaten sind. Wenn sich die Betriebsdaten über die Nutzungsdauer des Systems verändern, weil beispielsweise die Verkehrszeichen modernisiert werden, spricht man von einem sog. Distributional Shift.

Ein System muss für einen sicheren Betrieb in der Lage sein, mit solchen Veränderungen umzugehen. Negative Seiteneffekte treten auf, wenn ein System zwar seine Aufgaben korrekt durchführt, dadurch aber Störungen in seiner Umgebung hervorruft. So könnte ein autonomes Fahrzeug durch ständiges Beschleunigen und Abbremsen im Rahmen der zulässigen Geschwindigkeitsbeschränkungen den fließenden Verkehr stören. Ist ein System nicht hinsichtlich seiner Lösungen beschränkt, können einiger dieser unerwarteten Lösungen zu Problemen führen – ein autonom parkendes Fahrzeug könnte lernen, einen Standstreifen als Parkplatz zu nutzen. Die sichere Exploration des Lösungsraums ist daher eine wichtige Sicherheitsanforderung beim Einsatz von ML. Beim Reward Hacking nutzt ein System nicht geplante Abkürzungen, um das erwünschte Ziel vermeintlich zu erreichen. Eine solche Abkürzung wäre ein autonom fahrendes Fahrzeug, das sich angewöhnt, derart neben Lastkraftwagen zu fahren, dass es die Tafeln für Geschwindigkeitsbeschränkungen nicht erfasst, und so die Geschwindigkeitsbeschränkungen umgeht, um schneller ans Ziel zu gelangen.

Security-Risiken beim EInsatz von Machine Learning

Aus der statistischen Funktionsweise von ML und der starken Relevanz von Daten ergeben sich neben spezifischen Safety-Risiken aber auch ganz neue Arten von Cybersecurity-Angriffen. Die große Bedeutung von Daten für das Verhalten eines ML-Modells macht sogenannte Poisoning- Angriffe interessant. Dazu werden die Daten, mit denen ein ML-Modell angelernt wird, manipuliert. Das passiert zum Beispiel dadurch, dass bestehende Datenpunkte verschoben oder neue Datenpunkte hinzugefügt werden. Damit kann die Verteilung von Trainingsdaten verändert und letztendlich das Verhalten des mit diesen Daten angelernten ML-Modells manipuliert werden.

Zudem können durch manipulierte Trainingsdaten auch gezielt Hintertüren eingebaut werden, die von einem Angreifer dann im Betrieb aktiviert werden können. Beispielsweise kann ein Trainingsdatensatz, der u. a. ein Stoppschild mit dem korrekten Label „Stoppschild“ enthält, von einem Angreifer um ein Stoppschild mit einem gelben Aufkleber mit dem Label „Vorfahrtsschild“ erweitert werden (siehe Abbildung). Auch sogenannte Adversarial Attacks im Betrieb von ML-Modellen spielen eine erhebliche Rolle. Ein Angreifer manipuliert die Eingabedaten und täuscht ein ML-Modell mit einem mit spezifischem Rauschen versehenen Bild. Derartiges Rauschen ist für den menschlichen Betrachter nicht wahrnehmbar. Adversarial Attacks werden erleichtert, wenn Trainingsdatensätze öffentlich verfügbar sind. Das ist häufig der Fall, da die für das Training notwendigen umfangreichen Datensätze frei oder kommerziell weitergegeben werden. Der Angreifer erstellt dazu ein eigenes ML-Modell und trainiert es mithilfe eines solchen Trainingsdatensatzes.

In einem nächsten Schritt untersucht er das ML-Modell mit verschiedene Adversarial Attacks, bis er solche mit der gewünschten Falschklassifikation und nicht wahrnehmbaren Rauschen identifiziert hat. In einem dritten Schritt werden diese Angriffe gegen das eigentliche Ziel Während erste Ansätze zu Adversarial Attacks spezifisch für einzelne Bilder sind, haben neuere Ansätze universelle Methoden entwickelt, die eine gezielte Falschklassifikation unabhängig vom ursprünglichen Eingabebild erreichen. Einen Schritt weiter gehen Ansätze, die mit generativen Modellen neue Bilder ohne jegliches Rauschen generieren. Dieser Ansatz ist nicht darauf beschränkt, das Rauschen, das zu bestehenden Datenpunkten hinzugefügt wird, so zu begrenzen, dass es unentdeckt bleibt. Das erschwert die Entdeckung solcher Angriffe erheblich. Viele Angriffe zielen auf Klassifizierungsaufgaben mit überwachtem Lernen ab. Angriffe können sich jedoch auch gegen auf ML-Techniken, die auf verstärkendem Lernen basieren, richten. Hier führt spezifisches Verhalten von Agenten in der Umgebung zu unerwünschten Reaktionen der ML-Komponente.

HERAUSFORDERUNGEN FÜR DIE ZERTIFIZIERUNG VON ML

Daraus ergeben sich eine Reihe von Herausforderungen für die Zertifizierung von sicherheitskritischen Systemen mit ML (siehe Kasten).

ANSÄTZE FÜR DIE ZERTIFIZIERUNG VON ML

Overarching Properties (OPs), zu Deutsch etwa übergreifende Eigenschaften, sind ein alternativer Ansatz zu streng spezifizierten Verifizierungsund Validierungsprozessen. OPs zielen darauf ab, den Zertifizierungsprozess effizienter zu machen und den Herstellern mehr Freiheit bei der Wahl der Technologie zu geben, die sie für die Entwicklung eines Produkts verwenden möchten. OPs benennen daher lediglich die Eigenschaften eines Systems, auf die die aktuellen Verifikations- und Validierungsprozesse abzielen, aber nicht die Anforderungen an ihre Prüfung. Das Konzept der OPs wurde bei der NASA entwickelt und basiert auf der Annahme, dass ein ausreichender Satz solcher Eigenschaften für die Zertifizierung eines Produktes geeignet wäre, wenn gezeigt werden kann, dass ein Produkt all diese Eigenschaften besitzt. Die Arbeitsgruppe bei der NASA hat drei übergreifende Eigenschaften identifiziert: Intent, Correctness und Innocuity:

  • Intent: Das definiert beabsichtigte Verhalten ist korrekt und vollständig in Bezug auf das gewünschte Verhalten.
  • Correctness: Die Implementierung ist korrekt in Bezug auf das definiert beabsichtigte Verhalten, unter den vorhersehbaren Betriebsbedingungen.
  • Innocuity: Jeder Teil der Implementierung, der nicht für das definiert beabsichtigte Verhalten erforderlich ist, hat keine inakzeptablen Auswirkungen

Bisher gibt es jedoch lediglich eine prototypische Anwendung von OPs zur Zertifizierung. High-Level-Eigenschaften beschreiben im Gegensatz zu OPs nicht die geforderten Eigenschaften eines Systems, sondern einer ML-Technik. Wenn bei der Entwicklung eines Systems eine ML-Technik verwendet wird, die bestimmte High-Level- Eigenschaften besitzt, ist das darauf aufbauende System für die Zertifizierung geeignet. Dieser Ansatz würde es erlauben, bereits beim Design eines Systems dessen Zertifizierbarkeit sicherzustellen. Derartige Eigenschaften können zum Beispiel sein, die Qualität der verwendeten Daten, die Robustheit bei unbekannten oder anomalen Eingaben, oder dass sich die Entscheidungen des ML-Algorithmus erklären lassen.

Ähnlichkeitsanalyse und Rückwärtsanalyse sind Ansätze, die versuchen, erfolgreich zertifizierte Techniken als Ausgangspunkt für die Entwicklung einer neuen Lösung zu finden. Die Ähnlichkeitsanalyse ist ein Ansatz, der Nicht-ML-Systeme, die bereits zertifiziert wurden, hinsichtlich gemeinsamer Merkmale mit ML-Techniken analysiert. Kalman-Filter sind ein Beispiel für ein solches Nicht-ML-Verfahren. Damit lässt sich die Position eines Flugzeugs berechnen. Kalman-Filter implementieren ein statistisches Schätzverfahren und sind von empirischen Daten abhängig.

Daher teilen sie viele Eigenschaften mit ML-Techniken. Die Verwendung von Kalman- Filtern in Flugzeugen wird durch die DO-229 abgedeckt, die detaillierte Empfehlungen gibt, wie solche Algorithmen validiert werden müssen. Die Rückwärtsanalyse geht im Vergleich zur traditionellen Zertifizierung von Systemen in die entgegengesetzte Richtung. Anstatt ein Produkt zu entwickeln und anschließend die Eigenschaften zu zertifizieren, wird eine bestehende Technik mit schon zertifizierten Eigenschaften als Ausgangspunkt verwendet. Vor dort aus wird die Lösung für ein neues Problem entwickelt. Da die gewählte Technik bereits die für die Zertifizierung erforderlichen Eigenschaften besitzt, ist sichergestellt, dass die neue Lösung auch zertifizierbar ist.

  • Das Spezifikationsproblem: Algorithmen des Maschinellen Lernens sind gut darin, Probleme zu lösen, die schwer vollständig zu spezifizieren sind. Aktuelle Zertifizierungsansätze verlangen jedoch eine vollständige Spezifikation. Dieser Widerspruch macht insbesondere subsymbolische Ansätze, also statistische Verfahren, schwer zertifizierbar.
  • Das Datensatzproblem: ML-Modelle sind in hohem Maße auf Daten und dessen gleichmäßiger Verteilung bei Training, Test und im Betrieb angewiesen. Das Datensatzproblem resultiert aus der Schwierigkeit, zu bewerten, ob ein gegebener Datensatz in Bezug auf die beabsichtigte Funktion ausreichend ist. Es ist aktuell schwierig zu zeigen, dass ein Datensatz die vorhersehbaren Betriebsbedingungen eines sicherheitskritischen Systems hinreichend abdeckt.
  • Das Lernproblem: Für die Zertifizierung von ML ist es notwendig, entweder das aus dem Training resultierende Modell in Bezug auf die beabsichtigte Funktion oder den Trainingsprozess selbst zu verifizieren.

Dies ist aufgrund der statistischen Funktionsweise von ML bereits schwierig genug. Erschwert wird dies weiter durch den Umstand, dass die interne Funktionsweise eines ML-Modells bisher kaum nachvollziehbar ist und eine Erklärung der ML-Modelle sowie der von ihnen erzeugten Ergebnisse damit schwierig ist. Man spricht daher auch von Black-Box-Ansätzen.

Artikel teilen
Redaktion
Redaktion
Die SQ-Magazin Redaktion ist Ihr Ansprechpartner für alle Fragen, Anregungen und Ideen rund um das SQ-Magazin. Kontaktieren Sie uns gern unter redaktion@sq-magazin.de Wir freuen uns auf Ihre Nachricht!
- Advertisement -Certified DevOps Portfolio
Neueste Artikel
Weitere interessante Artikel
- Advertisement -spot_img
[js-disqus]