Freigeben über

KI-Risikobewertung für ML-Ingenieure

  • Artikel

Trotz der überzeugenden Gründe für die Sicherung von ML-Systemen fand die Umfrage von Microsoft in über 28 Unternehmen heraus, dass die meisten Branchenpraktiker sich noch nicht an das Adversarial Machine Learning (ML) gewöhnt haben. 25 aus den 28 Unternehmen gaben an, dass sie nicht über die richtigen Werkzeuge verfügen, um ihre ML-Systeme zu sichern. Darüber hinaus suchen sie explizit nach Unterstützung. Wir haben festgestellt, dass der Mangel an Vorbereitung nicht auf kleinere Organisationen beschränkt ist – er reicht von Fortune 500-Unternehmen über Regierungen bis hin zu gemeinnützigen Organisationen. Kunden erkennen an, dass KI-Systeme gesichert werden müssen, aber wissen nicht, wie das geht.

Dieses Dokument ist ein erster Schritt für Organisationen, um den Sicherheitsstatus ihrer KI-Systeme zu bewerten. Anstatt jedoch ein weiteres Framework hinzuzufügen, dem Organisationen folgen sollen, haben wir versucht, den Inhalt auf eine Weise aufzubereiten, die sich an vorhandenen herkömmlichen Frameworks für Sicherheitsrisikobewertung ausrichtet.

Diese Dokumentation hat drei Ziele:

  • Eine umfassende Perspektive für die Sicherheit des KI-Systems zu bieten. Wir haben jedes Element des KI-Systemlebenszyklus in einer Produktionseinstellung betrachtet: Von der Datensammlung, der Datenverarbeitung bis zur Modellimplementierung. Darüber hinaus haben wir die KI-Lieferkette sowie die Kontrollen und Richtlinien in Bezug auf Sicherung, Wiederherstellung und Notfallplanung im Zusammenhang mit KI-Systemen berücksichtigt.
  • Bedrohungen kritischer KI-Ressourcen zu skizzieren und Anleitungen zu geben, um sie zu schützen. Um Technikern und Sicherheitsexperten direkt zu helfen, haben wir die Bedrohungserklärung in jedem Schritt des KI-Systemaufbauprozesses aufgezählt. Als Nächstes stellen wir eine Reihe von Richtlinien bereit, die vorhandene Praktiken im Kontext von KI-Systemen überlagern und verstärken.
  • Es zu ermöglichen, dass Organisationen, KI-Sicherheitsrisikobewertungen durchführen. Das Framework hilft dabei, Informationen über den aktuellen Sicherheitsstatus von KI-Systemen in einer Organisation zu sammeln, eine Gap-Analyse durchzuführen und den Fortschritt des Sicherheitsstatus nachzuverfolgen.

Wir haben es in Verbindung mit den Beteiligten bei Microsoft formuliert, mit Vertretern von Azure Security, Verantwortung für KI-Strategie im Engineering, Microsoft Security Response Center, Azure Security und KI, Ethik und Effekte im Engineering and Research (Aether).

Einführung

Wir empfehlen, dieses Dokument zu verwenden, um die Diskussion über die Sicherung von KI-Systemen zu beginnen, die an laufenden Bemühungen zur Informationssicherheit und an den Geschäftszielen ausgerichtet sind. Das Dokument konzentriert sich auf KI-Systeme und die Einbeziehung herkömmlicher Steuerelemente, da KI-Systeme auf herkömmlichen IT-Infrastrukturen basieren.

Wir behandeln die folgenden Bereiche im Zusammenhang mit KI-Systemen.

Administrative Kontrollmaßnahmen Beschreibung
Sicherheitsrichtlinien für maschinelles Lernen Kontrollen und Richtlinien im Zusammenhang mit den dokumentierten Richtlinien, die maschinelles Lernen, künstliche Intelligenz und Informationssicherheit regeln.
Technische Kontrollen Beschreibung
Datensammlung Kontrollen und Richtlinien im Zusammenhang mit der Sammlung, Speicherung und Klassifizierung von Daten, die für maschinelles Lernen und künstliche Intelligenz verwendet werden.
Datenverarbeitung Kontrollen und Richtlinien im Zusammenhang mit der Verarbeitung und Technik von Daten, die für maschinelles Lernen und künstliche Intelligenz verwendet werden.
Modelltraining Kontrollen und Richtlinien im Zusammenhang mit Design, Training und Validierung von Modellen.
Modellimplementierung Kontrollen und Richtlinien im Zusammenhang mit der Bereitstellung von Modellen und unterstützender Infrastruktur.
Systemüberwachung Kontrollen und Richtlinien im Zusammenhang mit der laufenden Überwachung von maschinellen Lernsystemen.
Incident Management Kontrollen und Richtlinien im Zusammenhang mit der Behandlung von Vorfällen im Zusammenhang mit KI-Systemen.
Business Continuity & Disaster Recovery Kontrollen und Richtlinien im Zusammenhang mit dem Verlust geistigen Eigentums durch Modelldiebstahl, Verschlechterung von Diensten oder anderer KI-spezifischer Sicherheitsrisiken.

Wir haben den bestehenden Rahmen von Kontrollen und Richtlinien aus dem beliebten ISO27001:2013-Standard angepasst und dem KI-Systemaufbauprozess zugeordnet – von der Datensammlungsphase bis hin zur Reaktion auf Bedrohungen für KI-Systeme. Organisationen verfügen möglicherweise über einige oder alle vorhandenen Kontrollen, die aus ISO27001:2013 implementiert wurden oder bereits mit verschiedenen Risikoframeworks (NIST 800-53, PCI-DSS, FedRamp usw.) im Rahmen vorhandener Informationssicherheitsbemühungen übereinstimmen.

Wenn KI-Systeme nicht ausreichend sicher sind, erhöht sich das Risiko nicht nur auf die in dieser Bewertung angesprochenen KI-Systeme, sondern in der Regel auch auf die gesamte Informationstechnologie und Compliance-Umgebung.

Das Ziel dieses Dokuments ist es nicht, diese bestehenden Anstrengungen zu ersetzen, sondern die Sicherung von KI-Systemen aus dem Blickwinkel bestehender Tools und Frameworks zu beschreiben und sie auf alle Teile des KI-Erstellungsprozesses zu erweitern.

Die hier aufgeführten Anleitungen sind nicht präskriptiv, da dies mehr Kontext erfordern würde, wie die zugrunde liegende Plattform, der zugrunde liegenden Datentyp und die Auswahl des Algorithmus. Wenn Sie ein Azure Machine Learning-Kunde sind, lesen Sie den Artikel Enterprise-Sicherheit und -Governance.

Vorgeschlagener Schweregrad, Wahrscheinlichkeit, Auswirkung

Nicht alle Kontrollen sind für die Sicherheit eines KI-Systems von entscheidender Bedeutung. Um die Arbeit ordnungsgemäß zu priorisieren, sollte jede Kontrolle von der Organisation mit einer Schweregradbewertung bewertet werden, die für die geschäftlichen Auswirkungen, eine bestimmte Kontrolle nicht zu implementieren, relevant ist. Eine Organisation kann das Risiko einer kritischen Kontrolle akzeptieren und stattdessen eine ausgleichende Kontrolle implementieren, um das Risiko zu senken. Letztendlich sollen diese Bewertungen dazu beitragen, risikobasierte Entscheidungsfindungen zu leiten, anstatt Aktivitäten zu verschreiben.

Severity

Der Schweregrad eines Kompromisses hängt vom Anwendungsfall des KI-Modells ab. Glücklicherweise sollten die verwendeten Daten oder Systeme, die vor der Integration des maschinellen Lernens von entscheidender Bedeutung waren, es immernoch sein. Wenn das verwendete Modell standardmäßig und ohne weiteren Input ist, hängt es von dem Kontext, in dem Modell verwendet wird, ab. Der Schweregrad einer Kompromittierung ist dann wahrscheinlich niedriger. Techniken wie differenzielle Privatsphäre können die potenziellen Auswirkungen einer Kompromittierung verringern. Dieser Kontext würde jedoch nicht die Wichtigkeit des Systems, der Daten oder des Modells verringern. Es wird empfohlen, Modelle mit einer Defense-in-Depth-Strategie zu schützen, anstatt sich auf eine defensive Implementierung zu verlassen.

Vorgeschlagener Schweregrad

Vorschlag: Kritisch

  • Wenn das KI-Modell trainiert wird mit vertraulichen personenbezogenen Daten, klassifizierten Daten oder Daten, die den Complianceanforderungen wie PCI, HIPAA, GLBA usw. unterliegen, oder diese erfasst
  • Wenn das KI-Modell in einer geschäftskritischen Anwendung oder einem System verwendet wird, sodass bei einer Kompromittierung große negative Auswirkungen auf Geschäftsvorgänge hätte
  • Wenn das KI-Modell in Anwendungen verwendet wird, in denen physische Schäden oder Tod ein mögliches Ergebnis ist
  • Wenn das KI-Modell in einem System verwendet wird, das kritische Infrastruktur unterstützt (z. B. Wasser, Energie, Gesundheit)

Vorschlag: Hoch

  • Wenn das KI-Modell auf vertraulichen personenbezogenen Daten, vertraulichen Informationen oder Daten trainiert, oder sie erfasst, die andernfalls von der Organisation als kritisch eingestuft werden
  • Wenn die Kompromittierung dieses KI-Modells große, aber bereichsbezogene Auswirkungen auf Geschäftsvorgänge hätte
  • Wenn das KI-Modell in geschäftskritischen Anwendungen oder Systemen verwendet wird

Vorschlag: Mittel

  • Wenn das KI-Modell auf eine Teilmenge von Trainingsdaten trainiert wird, die vertrauliche Datentypen enthalten
  • Wenn eine Kompromittierung dieses KI-Modells Auswirkungen auf Modelle haben würde, die in der Produktion bereitgestellt werden
  • Wenn das KI-Modell in nicht kritischen, aber geschäftsorientierten Anwendungen verwendet wird
  • Wenn das KI-Modell nicht in der Produktion verwendet wird, aber Informationen zu Produktionsmodellen enthält

Vorschlag: Niedrig

  • Wenn das KI-Modell auf Daten trainiert wird, die nicht in der Produktion verwendet werden
  • Wenn das KI-Modell nicht in der Produktion verwendet wird und keine Informationen zu Produktionsmodellen enthält

Vorschlag: Als Information

  • Wenn die Daten aus einer überprüften Quelle und nicht klassifiziert sind
  • Wenn das KI-Modell nicht in der Produktion verwendet wird

Wahrscheinlichkeit

Wahrscheinlichkeit hat zwei Hauptkomponenten, die Verfügbarkeit des Modells und die Verfügbarkeit von Methoden. Um die Wahrscheinlichkeit eines Angriffs zu verringern, sollte eine Organisation Kontrollen implementieren, die:

  1. Angriffsfläche entfernen, oder die Aufzählung der Angriffsfläche erschweren.
  2. Stellen Sie sicher, dass die Protokollierung und Warnung so funktionieren, dass sie für eine schnelle Lösung von Problemen geeignet sind.
  3. Stellen Sie sicher, dass alle unterstützenden Systeme mit Sicherheitsanforderungen auf dem neuesten Stand sind.

Kontrollen können Gating-Endpunkte, Netzwerksegmentierung oder Ratenbegrenzung umfassen. Besondere Aufmerksamkeit sollte den Datenverkehrsflüssen und Netzwerk- oder Pipelinediagrammen geschenkt werden, z. B. einem Angreifer, der einen kompromittierenden und externen Endpunkt gefährdet und rückwärts durch eine Pipeline arbeitet.

Auswirkung

Die Auswirkungen beziehen sich auf Auswirkungen auf die Organisation. Wir empfehlen Ihnen, sich mit unterschiedlichen Möglichkeiten vertraut zu machen, wie ML-Systeme angegriffen werden können, und zu überlegen, wie Produktionsmodelle sich auf die Organisation auswirken können. Weitere Informationen finden Sie im Artikel Fehlermodi im Machine Learning. Sobald diese Orientierung abgeschlossen ist, kann sie einer Schweregradmatrix zugeordnet werden.

Schweregradmatrix

Die folgende Tabelle ist eine grundlegende Schweregradmatrix bezogen auf Risiko und Sicherheitsrisiko für Organisationen als Ausgangspunkt. Wir empfehlen, eine ähnliche Kategorisierung durch Konsultierung von Sicherheitsarchitekten, Machine Learning-Ingenieuren und KI Red Team-Mitgliedern zu erstellen.

Angriffstyp Wahrscheinlichkeit Auswirkung Ausnutzbarkeit
Extraktion Hoch Niedrig Hoch
Evasion High Medium High
Rückschluss Medium Medium Medium
Inversion Medium High Medium
Poisoning Niedrig Hoch Niedrig

„Das Entwerfen und Entwickeln sicherer KI ist ein Eckpfeiler der KI-Produktentwicklung bei BCG. Da die gesellschaftliche Notwendigkeit, unsere KI-Systeme zu sichern, immer deutlicher wird, können Ressourcen wie das KI Security Risk Management Framework von Microsoft grundlegende Beiträge liefern. Wir implementieren bereits die bewährten Methoden in diesem Framework in den KI-Systemen, die wir für unsere Kunden entwickeln, und freuen uns, dass Microsoft dieses Framework zum Vorteil der gesamten Branche entwickelt und veröffentlicht hat.“ — Jack Molloy, Senior Security Engineer, Boston Consulting Group

Grundlegende Verwendung

Der Rest des Dokuments folgt dieser Struktur:

  • Eine Risikokontrolle enthält eine Beschreibung, welchen Bereich die Kontrolle behandelt.
  • Das Ziel der Kontrolle und das, was sie erreichen soll.
  • Eine Bedrohungserklärung, die eine Beschreibung des Risikos liefert, das abgemildert wird.
  • Leitfaden für die Implementierung einer Kontrolle. Wir verstehen, dass aus legitimen geschäftlichen Gründen nicht alle Leitfäden umgesetzt werden können. Es wird empfohlen, Anleitungen zu dokumentieren, die nicht implementiert werden können.

In der folgenden Tabelle handelt es sich um eine Kontrolle, die aus der Risikobewertung der KI-Systeme abgerufen wird. Notizen werden hinzugefügt, um jeden Teil einer Risikokategorienstruktur zu beschreiben.

Beispielkontrolle

Lesart

1. Datensammlung

Primäre Kategorie

Kontrollen und Richtlinien im Zusammenhang mit der Erfassung und Speicherung von Daten aus allen Quellen, die für maschinelles Lernen und künstliche Intelligenz verwendet werden.

Beschreibt, welche Kontrollen in dieser Kategorie auf hoher Ebene behandelt werden.

2. Datenquellen

Steuerelementkategorie

Ziel: Die Integrität der gesammelten Daten sicherzustellen, die für trainierte Modelle verwendet werden.

Sollte das Risiko beschreiben, das mit den Kontrollen abgemildert wird.

Bedrohungserklärung: Daten werden aus nicht vertrauenswürdigen Quellen gesammelt, die vertrauliche personenbezogene Daten enthalten können, oder aus anderen unerwünschten Daten, die sich auf die Sicherheit eines Modells auswirken oder Compliancerisiken für die Organisation darstellen könnten.

Eine Anweisung, welche die Folgen beschreibt, wenn die Kontrolle nicht implementiert wird.

Kontrolle: Daten sollten aus vertrauenswürdigen Quellen gesammelt werden. Eine Liste der vertrauenswürdigen Quellen sollte beibehalten und aktualisiert werden. Genehmigungen für die Erfassung nicht vertrauenswürdiger Daten sollten fallweise geprüft werden.

Spezifisches Vokabular, das bewährte Methoden für die Kontrolle beschreibt.

Leitfaden:

  1. Alle angemessenen Anstrengungen sollten unternommen werden, um sicherzustellen, dass Daten vor dem Training eines Modells als vertrauenswürdig eingestuft werden können. Nicht vertrauenswürdige oder unbekannte Daten könnten Sicherheitsrisiken später in der Pipeline einführen.
  2. Daten, die vertrauliche personenbezogene Daten enthalten, unabhängig davon, ob sie für Data Science-Zwecke oder anderweitig verwendet werden, sollten entweder bereinigt oder ordnungsgemäß gespeichert werden und der Zugriff darauf reguliert werden.
  3. Das Sammeln von Daten ohne Berücksichtigung des Kontexts könnte zu Datasets führen, die illegale Daten enthalten. Die Bemühungen bei der Datensammlung sollten sich auf urheberrechtlich geschütztes Material, Datenschutzverletzungen und ungesicherte Endpunkte, die versehentlich Daten lecken, konzentrieren.

Leitlinien sind Empfehlungen zur Erfüllung der oben genannten Kriterien. Wir bieten ihnen eine agnostische Art und Weise, um Organisationen Raum zu geben, um das Problem auf eine Weise zu lösen, die für sie sinnvoll ist.

Sicherheitsbewertung für maschinelles Lernen

Vorbereitende Schritte

Zweck dieser Bewertung ist es, Organisationen dabei zu helfen, Risiken für Geschäftsvorgänge, die von KI-Systemen eingeführt wurden, zu formulieren, nachzuverfolgen und zu beheben. Diese Bewertung sollte verwendet werden, um:

  1. Sammeln Sie Informationen zum aktuellen Status der KI-Sicherheit innerhalb der Organisation.
  2. Führen Sie eine Gap-Analyse durch und erstellen Sie eine Roadmap für die Implementierung von Empfehlungen.
  3. Verfolgen Sie den Sicherheitsfortschritt, indem Sie diese Bewertung jährlich oder halbjährlich durchführen.

Wenn eine Organisation kein Sicherheitsprogramm hat, ist diese Bewertung nicht der richtige Ausgangspunkt. Eine Organisation sollte über ein funktionierendes Programm zur Informationssicherheit verfügen, bevor die Empfehlungen in dieser Bewertung implementiert werden. Weitere Informationen finden Sie im Artikel Azure Security Guidance im Cloud Adoption Framework.

Datensammlung

Kontrollen und Richtlinien im Zusammenhang mit der Erfassung und Speicherung von Daten aus allen Quellen, die für maschinelles Lernen und künstliche Intelligenz verwendet werden.

Ziel: Um die Integrität der in KI-Systemen gesammelten Daten zu gewährleisten.

Datenquellen

Kontrolle: Daten sollten aus vertrauenswürdigen Quellen gesammelt werden. Eine Liste der vertrauenswürdigen Quellen sollte beibehalten und aktualisiert werden. Verwaltungsgenehmigungen für die Erfassung nicht vertrauenswürdiger Daten sollten fallweise berücksichtigt werden. Wenn eine nicht vertrauenswürdige Quelle genehmigt wird, sollte sie dokumentiert werden.

Bedrohungserklärung: Daten, die aus nicht vertrauenswürdigen Quellen gesammelt werden, die vertrauliche personenbezogene Daten und andere unerwünschte Daten enthalten können, die sich auf die Leistung eines Modells auswirken könnten, oder Compliancerisiken für die Organisation darstellen.

Leitfaden:

  1. Eingabedaten sollten über die Genehmigung der Verwaltung überprüft und als vertrauenswürdig eingestuft werden, bevor sie in einem KI-System verwendet werden.
  2. Die für ein KI-System gesammelten Daten sollten vor der Verwendung oder Speicherung überprüft werden.
  3. Gegebenenfalls sollten gesammelte Daten von unerwünschten Einträgen bereinigt werden.
  4. Die Datenquelle sollte dokumentiert und mit den Daten aufbewahrt werden.
  5. Ableitungsdaten, die zum Trainieren eines Modells verwendet wurden, sollten nicht implizit als vertrauenswürdig angesehen werden und als neue Daten behandelt werden.
  6. Die Anstrengungen zur Datensammlung sollten dokumentiert und überwacht werden. Erfasste Daten sollten über einen Besitzer verfügen, der für die Einhaltung dokumentierter Richtlinien verantwortlich ist.

Vertrauliche Datentypen

Kontrolle: Um sicherzustellen, dass gespeicherte Daten für KI-Systeme ordnungsgemäß gesichert, nachverfolgt und gemäß ihrer Vertraulichkeit und ihrem Anwendungsfall klassifiziert werden. Dieses Kontrolle umfasst geeignete Datenklassifizierungsbezeichnungen, Zugriffsrichtlinien, Lizenzinformationen, beschreibende Statistiken, Ursprungsquellen und Datum der Sammlung.

Bedrohungserklärung: Daten, die in KI-Systemen verwendet werden, werden aufgrund fehlender erforderlicher Attribute, Metadaten oder Dokumentation unangemessen verwendet, gespeichert oder auf sie zugegriffen.

Leitfaden:

  1. Entwickeln Sie eine Datenrichtlinie, die den Datenschutz und den Schutz vertraulicher Datentypen umfasst, und kommunizieren Sie die Richtlinie allen Mitarbeitern, die an der Nutzung oder Erstellung von KI-Systemen beteiligt sind.
  2. Implementieren Sie Trainings- und Bereitstellungspipelines, welche die Vertraulichkeit und Integrität der in KI-Systemen verwendeten Daten schützen.

Datenspeicher

Kontrolle: Daten sollten einem dokumentierten Klassifizierungsprozess entsprechend gespeichert werden. Datasets sollten indiziert und als eine Ressource betrachtet werden, die der Bestandsverwaltung und den Zugriffssteuerungsrichtlinien unterliegt.

Bedrohungserklärung: Daten werden unsicher gespeichert und können von unbefugten Parteien oder Systemen manipuliert oder verändert werden. Daten werden nicht ordnungsgemäß klassifiziert, was zur Offenlegung vertraulicher Informationen oder vertraulicher personenbezogener Daten führt.

Leitfaden

  1. Stellen Sie sicher, dass Entwicklungs- oder KI-Forschungssysteme oder -konten keinen Zugriff auf Produktionsdatenbanken haben und umgekehrt.
  2. Daten, die in KI-Systemen verwendet werden, sollten gemäß einer dokumentierten Klassifizierungsrichtlinie klassifiziert und geschützt werden.
  3. Daten, die in KI-Systemen verwendet werden, werden unter einer dokumentierten Bestandsverwaltungsrichtlinie nachverfolgt.
  4. Daten, die für vertrauliche KI-Anwendungsfälle verwendet werden, werden auf genehmigten und verwalteten Systemen gespeichert.
  5. Der Zugriff auf Daten sollte überwacht werden, und Benutzer, die Zugriff anfordern, sollten einen formalen Zugriffskontrollprozess durchlaufen, der die Genehmigung des Managements umfasst.
  6. Daten, die in maschinellen Lernprozessen verwendet werden, sollten nicht im Internet verfügbar gemacht werden.
  7. Daten, die aus dem Internet abgerufen werden (oder aus anderen nicht vertrauenswürdigen Quellen), sollten einen Filterprozess durchlaufen, der die Genehmigung der Verwaltung umfasst.
  8. Datasets sollten mit formalen Änderungskontrollprozessen aktualisiert werden.

Datenzugriff

Kontrolle: Datasets sollten vor der Verwendung entsprechend nachverfolgt und überprüft werden.

Bedrohungserklärung: Datasets werden ohne Autorisierung geändert.

Leitfaden:

  1. Die rollenbasierte Zugriffssteuerung für Datasets sollte erzwungen werden.
  2. Führen Sie regelmäßige Zugriffsprüfungen durch, um sicherzustellen, ob Konten mit Zugriff auf Datasets Zugriff auf diese Datasets haben sollten. Stellen Sie sicher, dass jedes Konto innerhalb normaler Grenzen funktioniert.
  3. Wenn keine zentrale Tracking-Plattform verwendet wird, sollte der Zweck des Zugriffs auf Daten über Raw-Zugriffsprotokolle geprüft werden. Stellen Sie sicher, dass jedes Konto innerhalb normaler Grenzen funktioniert.
  4. Ressourcenanbieter, Auftragnehmer oder andere externe Parteien sollten keinen übermäßigen oder unangemessenen Zugriff auf die Trainings-/Testdatenressourcen eines Unternehmens ohne Verträge haben.

Datenintegrität

Kontrolle: Datasets sollten vertrauenswürdig sein und während des gesamten KI-Systemlebenszyklus vertrauenswürdig bleiben.

Bedrohungserklärung: Datasets werden während des KI-Lebenszyklus geändert, ohne dass Änderungen überwacht oder nachverfolgt werden können.

Leitfaden:

  1. Datasets sollten eindeutig identifiziert werden, sodass nicht autorisierte Änderungen an einem genehmigten Dataset zu einer Überprüfung des Datasets führen.
  2. Datasets und ihre kryptografischen Beschreibungen sollten an einem zentralen Ort nachverfolgt werden. Der Zugriff auf das Dataset sollte überwacht werden.
  3. Änderungen am Dataset sollten eine aktualisierte kryptografische Beschreibung und Verwaltungsgenehmigung enthalten, bevor sie an den zentralen Nachverfolgungsdienst übermittelt werden.

Datenverarbeitung

Kontrollen und Richtlinien im Zusammenhang mit der Verarbeitung von Daten, die für maschinelles Lernen und künstliche Intelligenz verwendet werden.

Ziel:Die sichere Verarbeitung von Daten aus ihrer Rohform in ein Vermittlerformular zu gewährleisten, das für das Training geeignet ist.

Verarbeitungspipelines

Kontrolle: Die Verarbeitung von Pipelines sollte angemessen gesichert werden.

Bedrohungserklärung: Ein Bedrohungsakteur kann nicht autorisierte Änderungen am System vornehmen, indem er die Datenverarbeitungspipelines ändert.

Leitfaden:

  1. Nicht alle Daten, die sich durch ein Produktionssystem bewegen, sind relevant für Data Science-Bemühungen. Es ist wichtig, nur die erforderlichen Daten zu analysieren und sicherzustellen, dass alle Daten, die aus einer sicheren Produktionseinstellung in eine Entwicklungseinstellung verschoben werden, entsprechend nachverfolgt werden. Bedenken Sie, dass bestimmte Datentypen möglicherweise nicht in eine Entwicklungsumgebung verschoben werden können. Data Science muss möglicherweise in einer sicheren zwischengeschalteten Umgebung stattfinden.
  2. Die ordnungsgemäße Überwachung des Datenzugriffs während des gesamten Lebenszyklus der Datenverarbeitung ist wichtig. Ohne separate Konten kann es keine ausreichende Überwachung des Zugriffs geben. Darüber hinaus wäre die Fähigkeit, auf einen Vorfall zu reagieren, ohne potenziell Geschäftsprozesse zu beeinträchtigen, nicht vorhanden. Die Kompromittierung eines einzelnen Kontos würde zu einer Kompromittierung aller Daten führen, welche die sichere Produktionsumgebung verlassen.
  3. Data Science-Prozesse könnten Ressourcen erfordern, die sich außerhalb einer strengen Compliancegrenze befinden.
  4. Data Science-Prozesse sollten immer den bestehenden Anforderungen entsprechen. Dieser Prozess könnte das Verschieben von Data Science-Ressourcen und -Prozessen in eine kompatible Umgebung umfassen.
  5. Daten sollten über den gesamten Lebenszyklus nachverfolgt werden. Diese Nachverfolgung umfasst Teilmengen größerer Datasets. Es sollte erforderlich sein, dass ein Modell auf die Daten zurückgeführt werden kann, auf denen es trainiert wurde. Darüber hinaus sollte eine vollständige Kopie dieser Daten vorhanden sein.

Dataset-Blende

Kontrolle: Um zu gewährleisten, dass Teilmengen (z. B. zeitliche, kategorisierte Segmente) von Daten für die Modellerstellung verwendet werden, und wie dies zu Sicherheitsrisiken führen kann (Datenschutzlecks, Vergiftungen/Integrität über Überausprägung von Feedback usw.).

Bedrohungserklärung: Der Bedrohungsakteur kann Teile der Daten wiederherstellen, indem Teilmengen von Daten rekonstruiert/wiederhergestellt werden.

Leitfaden:

  1. Teilmengen von Daten sind selbst Datasets. Diese Teilmengen müssen dieselben Metadaten wie das übergeordnete Dataset haben und entsprechend auf vertrauliche Datentypen überprüft werden.
  2. Je nach Richtlinien für maschinelles Lernen (SLAs, Bias-Metriken usw.) sollte jedes gegebene Dataset (einschließlich Teilmengen) einen minimal dokumentierten Standard erfüllen, der diese Metriken umgibt, wenn sie im Modellbau verwendet werden sollen. Die Metadaten sollten immer an das Dataset angefügt werden.
  3. Alle Datasets, die gegen vorhandene Richtlinien verstoßen, sollten eine dokumentierte Ausnahme aufweisen, die vom Management genehmigt wurde. Die Ausnahme sollte zusätzlich zu den erforderlichen Metadaten einen dokumentierten Grund für die Ausnahme enthalten.
  4. Alle für das Modellbau verwendeten Daten sollten an einem zentralen Ort nachverfolgt werden. Daten sollten jederzeit überprüfbar sein. Darüber hinaus sollten Modelle, die auf nicht nachverfolgten Daten trainiert wurden, aus der Produktion entfernt werden, bis sie einem bekannten Dataset mit den erforderlichen Metadaten zugeordnet werden können.
  5. Datasets sollten entsprechend versioniert werden, sodass alle Metadaten aktualisiert werden, und Benutzer der Daten den Inhalt und die statistischen Eigenschaften verstehen. Bei Bedarf sollte die Genehmigung des Managements für vertrauliche Anwendungsfälle erforderlich sein.

Modelltraining

Kontrollen und Richtlinien im Zusammenhang mit dem Training von Modellen und Algorithmen.

Modelldesign

Kontrolle: Der Modelltrainingscode wird von einer verantwortlichen Partei überprüft.

Bedrohungserklärung: Fehlerhafter Code oder Sicherheitsrisiken im Modellcode führen zu Verfügbarkeits-, Integritäts- oder Vertraulichkeitsrisiken.

Leitfaden:

  1. Modelldesign und Forschung sollten in einer geeigneten Umgebung stattfinden. Modelldesign und Architektur können einen großen Einfluss auf die Wirksamkeit eines Modells haben. Produktionsumgebungen sind nicht der Ort für die Forschung oder das Testen nicht nachweisbarer Ansprüche an die Wirksamkeit eines Designs.
  2. Die Modellauswahl für ein Produktionssystem sollte vom Management überprüft und genehmigt werden. Dieser Prozess sollte frühzeitig in der Entwicklungsphase erfolgen und sollte über alle verfügbaren Mechanismen (Excel, DevOps, Git usw.) nachverfolgt werden. Ausnahmen sollten dokumentiert werden.
  3. Modelle sind häufig domänenspezifisch, und es sollte eine angemessene Dokumentation vorhanden sein, die das Modell während der gesamten Verwendung in einer Organisation begleitet.
  4. Stellen Sie sicher, dass auf Modellmetadaten für Benutzer zugegriffen werden kann und dass nicht genehmigte Verwendungen von Modellen dokumentiert und nachverfolgt werden. Es ist akzeptabel, dass ein Benutzer ein vorhandenes Modell optimieren kann, solange neue Metadaten ordnungsgemäß angefügt und nachverfolgt werden.

Modelltraining

Kontrolle: Das Modellauswahlkriterium (Metrik- und Aufbewahrungssätze) imitiert natürlichen Drift und alle widrigen Bedingungen, die zur Bereitstellungszeit erwartet werden können.

Bedrohungserklärung: Ein Modell, das unter idealen Bedingungen trainiert wird, ist wahrscheinlich brüchig, wenn es in widrigen Bedingungen bereitgestellt wird.

Leitfaden

  1. Trainings- und Validierungssätze sollten natürliche zeitliche Abhängigkeiten berücksichtigen. Bei Schadsoftwareklassifizierern sollte ein Überprüfungssatz z. B. nur Softwareversionen enthalten, die später im Trainingssatz enthalten sind.
  2. Fügen Sie explizit die Modellfestigkeit hinzu, indem Sie Datasets mit allgemeinen Beschädigungen erweitern, die vernünftigerweise in der Wildbahn entdeckt werden könnten.
  3. Trainieren Sie explizit gegen widrige Bedingungen mit entsprechendem Zusatztraining.
  4. Verfolgen von Experimenten und zugeordneten Metas.

Modellauswahl

Die Modellauswahl besteht aus der Auswahl eines Modells aus einer Reihe von Kandidaten, wobei jeder Kandidat über einen eindeutigen Satz von Modellparametern, Schulungsalgorithmus und Trainingshyperparameter verfügt. Das Auswahlkriterium für das Gewinnermodell basiert häufig auf einer einzigen quantifizierbaren Metrik (z. B. minimaler Verlust, maximale Erkennungsrate), die an einem gemeinsamen Satz zurückgehaltener Daten gemessen wird, oder als Mittelwert für einen K-fache Kreuzvalidierungssatz.

Kontrolle: Der Modellentwurfs- und Trainingsalgorithmus umfasst explizite oder implizite Modellabgrenzung.

Bedrohungserklärung: Modelle sind auf einen Trainings- und/oder einzelnen Validierungsdatensatz überangepasst und anfälliger für Fehlermodi.

Leitfaden:

  1. Wenn rechnerisch machbar, sollte die K-fache Kreuzvalidierung verwendet werden, um zu verhindern, dass die Überanpassung an einen einzelnen zurückgehaltene Datensatz erfolgt.
  2. Überprüfen Sie, dass ausgewählte Modelle mit unterschiedlichen zurückgehaltenen Datensätzen gut funktionieren, um sicherzustellen, dass sie nicht überangepasst sind.
  3. Stellen Sie sicher, dass Prozesse vorhanden sind.

Versionsverwaltung der Modelle

Kontrolle: Modelle werden kontinuierlich neu trainiert, da neue Trainingsdaten in Trainingspipelines fließen.

Bedrohungserklärung: Ein Vorfall tritt auf, aber das betroffene Modell kann nicht für die Untersuchung lokalisiert werden.

Leitfaden:

  1. Versionieren Sie Modelle, sodass jedes Mal, wenn ein Modell trainiert wird, eine neue Version zugewiesen wird. Qualifizierer wie my_model_dev_1.1 oder my_model_prod_1.1 sollten verwendet werden, um die Produktions- von Vorproduktionsmodellen zu unterscheiden. Diese Versionsverwaltung hilft beim Isolieren von Problemen in der Produktion oder Vorproduktion. Verweisen Sie auf vorhandene sichere SDL-Prozesse oder -Richtlinien.

Modellimplementierung

Kontrollen und Richtlinien im Zusammenhang mit der Bereitstellung von Modellen, Algorithmen und unterstützender Infrastruktur.

Sicherheitstests

Kontrolle: Modelle, die in die Produktion aufgenommen werden, sind angemessen gesichert.

Bedrohungserklärung: KI-Systeme werden vor der Bereitstellung nicht angemessen auf Sicherheitsrisiken getestet.

Leitfaden:

  1. Es wurden keine formalen Akzeptanztests für neue KI-Systeme, Upgrades und neue Versionen definiert und dokumentiert.
  2. Neue KI-Systeme, Upgrades oder neue Versionen sollten mit formalen Tests implementiert werden.
  3. Automatisierte Tools sollten zum Testen von Informationssystemen, Upgrades oder neuen Versionen verwendet werden.
  4. Die Testumgebung sollte der endgültigen Produktionsumgebung genau ähneln.
  5. Die Häufigkeit, der Umfang und die Methoden für unabhängige Sicherheitsüberprüfungen sollten dokumentiert werden.

Sicherheits- und Complianceüberprüfung

Kontrolle: Die robuste Verwaltung des zugrunde liegenden Netzwerks ist der Schlüssel zur Sicherung des ML-Systems und der Infrastruktur.

Bedrohungserklärung: Kompromittierung des ML-Systems durch Zugriff auf das ungesicherte Netzwerk.

Leitfaden:

  1. Gatewaygeräte zu ML-Systemen sollten so konfiguriert werden, dass Datenverkehr zwischen Domänen gefiltert und nicht autorisierter Zugriff blockiert wird.
  2. Die einschlägigen gesetzlichen, regulatorischen und vertraglichen Anforderungen sollten explizit definiert und dokumentiert und angegangen werden, neben spezifischen Kontrollen und individuellen Verantwortlichkeiten.
  3. Richtlinien für sichere Konfigurationen sollten auch dokumentiert, implementiert oder überprüft werden.
  4. Das Kriterium für die Trennung von ML-Netzwerken in Domänen sollte mit der Zugriffssteuerungsrichtlinie oder den Zugriffsanforderungen der Organisation übereinstimmen.
  5. Mechanismen wie sicheres Gateways, VPN und Routing für ML-Systeme sollten ausreichend implementiert werden, um eine Stufung von Kontrollen zu ermöglichen.
  6. Benutzer und ML-Techniker sollten Vorschriften für die Implementierung von Kontrollen verwenden oder befolgen, um die Verwendung öffentlich zugänglicher Systeme, interner Netzwerke und kritischer Ressourcen ordnungsgemäß zu trennen und einzuschränken.

Systemüberwachung

Kontrollen und Richtlinien im Zusammenhang mit der laufenden Überwachung von Machine Learning-Systemen und unterstützender Infrastruktur.

Protokolle und Protokollüberprüfung

Kontrolle: Die Protokollierung und Überwachung ist aus Sicherheitsgründen für ML-Systeme von entscheidender Bedeutung.

Bedrohungserklärung: Während einer Untersuchung werden Protokolle für ML-Systeme nicht gefunden.

Leitfaden:

  1. Protokollierung und Überwachung sollten auf allen KI-Systemen und deren Komponenten konsistent erfolgen, einschließlich Speicher, Pipelines, Produktionsserver usw.
  2. Ereignis- und Sicherheitsprotokolle sollten regelmäßig auf ungewöhnliches Verhalten überprüft werden.
  3. Konsolidierte Berichte und Warnungen zu Systemaktivitäten sollten von der Geschäftsleitung oder einem Sicherheitsbeauftragten generiert und überprüft werden.

Incident Management

Rollen und Zuständigkeiten

Kontrolle: Sicherheitsprotokolle sollten an einem zentralen Ort gesammelt werden.

Bedrohungserklärung: Während einer Untersuchung verfügen Sicherheitsanalysten nicht über ein formalisiertes Playbook.

Leitfaden:

  1. Organisationen müssen einen formalen Prozess befolgen, um KI-Systemvorfälle im Zusammenhang mit Serviceverlust, Verlust von Geräten, Verlust von Einrichtungen, Systemstörungen, Systemüberladungen, menschliche Fehler, Nichtkompatibilitäten mit Richtlinien oder Vorgaben, Verstöße gegen physische Sicherheit, unkontrollierte Systemänderungen, Softwarefehler, Hardwarestörungen und Zugriffsverletzungen zu melden.
  2. Formale Verfahren zur Reaktion auf Vorfälle und zur Eskalation sollten entwickelt werden, um Maßnahmen zu dokumentieren, die beim Empfang eines Berichts über ein Informationssicherheitsereignis ergriffen werden.
  3. Verfahren zur Reaktion auf Vorfälle sollten regelmäßig getestet werden, um Reaktionsmetriken nachzuverfolgen.

Geschäftskontinuität planen

Planung, Überprüfung und Ergebnisse

Kontrolle: Stellen Sie sicher, dass ML-Systeme nach einem Vorfall behoben und wiederhergestellt werden können.

Bedrohungserklärung: Vorfälle verursachen dauerhafte Vertraulichkeits-, Integritäts- oder Verfügbarkeitsprobleme bei kritischen ML-Systemen.

Leitfaden:

  1. Kritische KI-Ressourcen sollten identifiziert und inventarisiert werden.
  2. Die Organisation sollte einen Geschäftskontinuitätsplan (Business Continuity Plan, BCP) oder einen DR-Prozess (Disaster Recovery) im Angesicht von Angriffen auf KI-Systeme entwickeln.
  3. Die Organisation muss priorisiert die Risiken identifizieren, die mit den Auswirkungen des Verlusts kritischer KI-Systeme bei Angriffen verbunden sind.
  4. Organisationen müssen über einen wiederholten Zeitplan für kritische KI-Systeme verfügen, um Geschäftskontinuitätstests durchzuführen.

References

Wenn Sie Fragen, Kommentare oder Feedback haben, wenden Sie sich an atml@microsoft.com.

Laden Sie eine PDF-Datei dieses Dokuments aus unserem GitHub-Repository herunter.