Tag 22: Wenn der KI-Assistent zum Sicherheitsvorfall wird

Stefan

Herzlich willkommen zu Tag 22 des AI Business Specialist Trainings. Heute ist Freitag, der 16. Oktober 2026. Um 17:00 Uhr startet die Zoom Session, der Raum ist ab 16:50 offen. Wir sind im sechsten Teil des Lehrgangs, er heisst Legal und Cyber Security und läuft heute und morgen. Heute Abend steht Cyber Security für KI Systeme auf dem Programm, morgen übernimmt Thomas Kuster mit Recht und EU AI Act.

Marc

Und der Gast des Abends ist Marc Ruef. Ich sage bewusst den vollen Namen, damit es keine Verwechslung gibt. Er ist Head of Research und Mitgründer der scip AG in Zürich, und er unterrichtet unter anderem an der ETH Zürich und an der HSLU. Er arbeitet seit den späten Neunzigerjahren in der Informationssicherheit. Er hat damals computec.ch gegründet, und er hat Bücher geschrieben, darunter «Die Kunst des Penetration Testing». Sein Blick ist der des Angreifers. Er zeigt also nicht, wie man ein System baut, sondern wie man es angreift.

Stefan

Bevor wir dorthin gehen, kurz der Rahmen für euch alle. Ihr seid 23 Teilnehmende, Fach und Führungskräfte, und keine Entwicklerinnen oder Entwickler. Das ist wichtig, denn es bestimmt, was von euch erwartet wird. Ihr sollt nicht selbst programmieren. Ihr sollt Bedrohungen erkennen, bewerten und Gegenmassnahmen anordnen können. Von 17:00 bis 20:00 Uhr gibt es Fachinput und Übungen. Von 20:00 bis 21:00 Uhr folgt die Projektwerkstatt, und die gehört euch und eurem eigenen Projekt.

Marc

Dazu die Hausaufgabe, die dahintersteht. Der Projektauftrag lautet, ein Threat Model und eine Security Kontrollmatrix für das eigene KI Projekt zu erstellen. Das ist ein Angebot für die Werkstatt, und Wochenaufgabe 6 vertieft es dann vom 19. bis zum 25. Oktober. Ich würde das Angebot ernst nehmen. Denn der Stoff von heute ist in der Prüfung gleich doppelt relevant.

Stefan

Genau. Tag 22 gehört zur Kompetenz E4, also dem kontinuierlichen Verbessern von KI Lösungen. Geprüft wird das im Prüfungsteil 2, der schriftlichen Fallstudie am 30. Oktober 2026. Und im Prüfungsteil 3, den mündlichen Critical Incidents zu den Handlungsfeldern D, E und F. Ein Sicherheitsvorfall an einem KI System ist ein typischer Critical Incident. Darum nehmen wir uns in dieser Folge zuerst den Ernstfall vor und schauen dann, was Marc Ruef dazu beitragen wird.

Marc

Der Faden führt von den letzten Tagen direkt hierher. An Tag 20 ging es um Monitoring, also darum, dass ihr im Betrieb überhaupt etwas seht. An Tag 21 ging es um den kontinuierlichen Verbesserungsprozess und das Operating Modell. Bei ISA Desk hat Reto Iten dort einen Vorschlag gemacht: Freigegebene Antworten sollen automatisch als Musterantworten in die Wissensbasis wandern. Das klingt effizient. Heute werdet ihr sehen, warum dieser Vorschlag auch ein Einfallstor sein kann.

Stefan

Und noch ein Begriff aus Tag 21 kommt zurück: Jidoka. Das Toyota Prinzip, bei dem jeder am Band die Reissleine ziehen darf, wenn etwas nicht stimmt. Gestern war das ein Qualitätsprinzip. Heute wird es zum Kill Switch im Incident Plan, technisch und organisatorisch. Die Frage des Tages lautet: Was passiert, wenn das Monitoring anschlägt? Wer entscheidet, wer handelt, wer informiert wen?

Marc

Machen wir es konkret, mit ISA Desk. Ihr kennt den Fall seit Anfang September. Ein eingekaufter KI Assistent einer Verbandsgeschäftsstelle. Er schreibt Antwortentwürfe aus einer Wissensbasis, er greift über eine Zwischenschicht auf eine alte Mitgliederdatenbank zu, und ein Mensch gibt jede Antwort frei. Dieses Bild brauchen wir, denn ein Incident Plan ohne ein konkretes System bleibt Papier. Ich sehe in diesem Fall vier typische Vorfälle.

Stefan

Der erste Vorfall ist die indirekte Prompt Injection. Eine Person aus der Mitgliedschaft schickt eine Anfrage mit einem Anhang. Im Dokument steht, für Menschen unsichtbar oder unauffällig, eine Anweisung an das Modell. Zum Beispiel, es solle Datenbankabfragen ausführen oder vertrauliche Vorstandsnotizen offenlegen. Das System liest den Anhang, behandelt die Anweisung aber nicht als Inhalt, sondern als Befehl. Prompt Injection heisst: Eingaben bringen das Modell dazu, anders zu handeln als vorgesehen. Direkt über die Nutzereingabe oder indirekt über Mails, Dokumente und Webseiten, die das System liest.

Marc

Es gibt dafür reale Fälle. EchoLeak aus dem Jahr 2025 hatte einen CVSS Wert von 9.3. Eine präparierte Mail genügte, damit ein Unternehmens Copilot vertrauliche Daten preisgab. Und im Dezember 2023 verkaufte der Chatbot eines Chevrolet Händlers per Prompt Injection einen Neuwagen für 1 US Dollar. Er wurde danach abgeschaltet. Der zweite Fall war lustig, der erste ist es nicht. Und beide zeigen: Wer ein System über Sprache steuern kann, kann es auch über Sprache missbrauchen.

Stefan

Der zweite Vorfall ist weniger spektakulär, aber vielleicht häufiger: die unerwartete Modelländerung. Der Anbieter des Cloud Modells aktualisiert still im Hintergrund. Ein Silent Update. Niemand bei euch hat etwas geändert, und trotzdem nennt das System plötzlich falsche Beitragsstufen oder gibt rechtlich bindende Falschauskünfte. Das ist kein Angriff von aussen. Aber für den Betrieb ist es ein Incident, und der Ablauf ist derselbe: erkennen, eindämmen, klären, informieren.

Marc

Der dritte Vorfall betrifft direkt Reto Itens Vorschlag. Angenommen, er wurde umgesetzt. Jede freigegebene Antwort fliesst automatisch in die Wissensbasis. Jetzt braucht ein Angreifer keinen Zugang zum Modell. Er braucht nur Anfragen, die irgendwann freigegeben werden. Der Kurs nennt dazu eine Studie von Anthropic, dem UK AI Security Institute und dem Turing Institute aus dem Jahr 2025. Bereits 250 vergiftete Dokumente genügten, um eine Hintertür ins Modell einzubauen, und zwar unabhängig von der Modellgrösse. Entscheidend ist also oft die absolute Zahl, nicht der Anteil.

Stefan

Das muss man kurz wirken lassen. Man würde intuitiv denken, ein grosses Modell sei verdünnt genug, um solche Manipulationen zu schlucken. Die Studie sagt: Nein, die absolute Zahl zählt. Für eine kleine Wissensbasis in einer Verbandsgeschäftsstelle heisst das: Der Schutz liegt nicht in der Menge der Daten, sondern in der Kontrolle des Zugangs. Wer darf etwas in die Wissensbasis schreiben, und wer prüft es vorher? Eine automatische Einspeisung ohne Prüfung beantwortet diese Frage mit: niemand.

Marc

Der vierte Vorfall ist Excessive Agency, also zu viele Rechte, verbunden mit Datenabfluss über die Zwischenschicht. Das System darf mehr, als seine Aufgabe verlangt. Es darf Mitgliederdaten abfragen, die für eine Antwort gar nicht nötig sind. Oder es darf Aktionen ausführen, ohne dass jemand sie sieht. In diesem Fall trifft ein Fehler im Modell auf eine Schnittstelle ohne saubere Berechtigungsprüfung. Und hier liegt die häufigste Schwäche in Prüfungen, aber auch in der Praxis.

Stefan

Das ist die Hauptfehlerquelle, die uns die Kursleitung nennt. Viele Teilnehmende schauen nur auf das KI Modell. Sie übersehen die klassischen IT Schwachstellen: offene Ports, fehlende Berechtigungsprüfung in der Middleware, eine mangelhafte Logging Infrastruktur oder fehlende Vertretungsregelungen im Incident Plan. Das Modell ist oft nicht das Einfallstor. Es ist der Teil, der besonders neu und besonders spannend wirkt, und deshalb schauen alle zuerst dorthin.

Marc

Jetzt der Ablauf. Angenommen, Nadia Frei sitzt an der Freigabe Queue und merkt, dass ein Antwortentwurf Informationen enthält, die da nicht hingehören. Zum Beispiel Auszüge aus Vorstandsnotizen. Was nun? Die erste Antwort heisst: Sofortmassnahmen. Man analysiert nicht zuerst, man begrenzt zuerst. Das ist der Jidoka Gedanke. Die Reissleine wird gezogen, bevor die Ursache klar ist.

Stefan

Es gibt drei Sofortmassnahmen. Erstens der technische Kill Switch. Der Assistent wird vom Produktivbetrieb getrennt, oder die Zwischenschicht zur Mitgliederdatenbank wird gesperrt. Zweitens der Fallback Modus. Es gibt einen unterbruchsfreien Übergang auf hundert Prozent manuelle Ticketbearbeitung durch die Sachbearbeitung. Das muss vorher geübt sein, sonst steht am Montag die ganze Geschäftsstelle still. Drittens die Beweissicherung. Die vollständigen Logs werden eingefroren, also Prompts, abgerufene Wissensbausteine und Schnittstellendaten, und zwar bevor jemand das System neu startet. Ein Neustart kann genau die Spuren löschen, die man später braucht.

Marc

Und jetzt kommt der Teil, den ich als nüchterner Mensch am wichtigsten finde: die Rollen mit Namen. Nicht «die IT» und nicht «die Geschäftsleitung», sondern Personen. Beat Hofstetter ist Incident Lead und hat die Gesamtverantwortung. Er entscheidet über die Systemabschaltung und über die Eskalation an die Geschäftsleitung. Nina Brunner ist Incident Coordinator. Sie führt das Incident Log, aktualisiert das Test und Prüfset und steuert die Fehlerkategorien.

Stefan

Tobias Kern ist der technische Lead. Er verantwortet die Schnittstellen, hält den Kontakt zum LLM Anbieter und analysiert Injection Muster. Nadia Frei und Sandra Keller sind Frontline und Triage. Sie erkennen Auffälligkeiten in der Freigabe Queue und aktivieren bei Verdacht den Stopp Trigger. Und Philipp Zemp, der Datenschutzjurist, hat Recht, Governance und Veto. Er prüft die Meldepflichten. Fünf Rollen, fünf Namen. Und dazu gehört ein Punkt, den wir gerne unterschlagen: Vertretungen. Wenn Beat Hofstetter in den Ferien ist, wer entscheidet dann?

Marc

Ich finde den Punkt wichtig, weil er unspektakulär ist. Marc Ruef sagt in einem Interview mit Deloitte vom 16. September 2026 etwas sehr Passendes. Gefragt wurde er nach einer Umfrage von swissVR, laut der mehr als die Hälfte der Unternehmen keine Pläne hat, wie sie wesentliche IT Prozesse nach einem Cyberangriff ohne untragbare Kosten oder Schäden wiederherstellen. Seine Antwort: Man müsse sich Zeit nehmen, Kernprozesse und Massnahmen zur Eindämmung vorab zu identifizieren. Denn wenn die Krise einmal da sei, befinde man sich im Überlebensmodus und habe keine Zeit mehr, Entscheidungen sorgfältig zu treffen.

Stefan

Das ist der Kern eines Incident Plans. Er ersetzt nicht das Denken. Er verlegt das Denken auf einen Zeitpunkt, an dem man noch Ruhe hat. Und dann gibt es die gesetzliche Seite. Nach dem revidierten Schweizer Datenschutzgesetz, Artikel 24, muss eine Verletzung der Datensicherheit so rasch als möglich dem Eidgenössischen Datenschutz und Öffentlichkeitsbeauftragten gemeldet werden, wenn voraussichtlich ein hohes Risiko für die betroffenen Personen besteht. Wie das rechtlich im Detail zu behandeln ist, vertieft morgen Thomas Kuster. Für heute reicht die Konsequenz: Philipp Zemp muss früh am Tisch sitzen, nicht erst nach drei Tagen.

Marc

Dazu kommt die Kommunikation nach innen und aussen. Verbandsmitglieder und Vorstand brauchen eine klare Sprachregelung. Ohne Beschwichtigung und ohne voreilige Schuldzuweisungen. Das ist schwerer, als es klingt. Am ersten Tag weiss man oft noch nicht, was passiert ist. Dann ist die ehrliche Aussage: Das wissen wir, das wissen wir noch nicht, und das tun wir als Nächstes. Wer zu früh beschwichtigt, muss später korrigieren, und das kostet Vertrauen.

Stefan

Und noch eine Verbindung zu Tag 14. Dort ging es um die FMEA, die Fehlermöglichkeits und Einflussanalyse. Sie fragt, wie ein System von innen unbeabsichtigt versagen kann. Ein Threat Model ergänzt sie um die Angreiferperspektive von aussen. Die FMEA fragt: Was kann kaputtgehen? Das Threat Model fragt: Wer will es kaputt machen, und wie? Ein guter Incident Plan braucht beide Sichten.

Stefan

Damit sind wir bei Marc Ruef und seinem Format. Das Programm des Abends sieht vor, dass er die Angreiferperspektive nicht nur erklärt, sondern zeigt. Er führt euch ins Darknet. Im Auftrag stand dafür ein phonetisch notierter Begriff, gemeint ist das Darknet. Dort wird live gezeigt, wie Cybercrime Märkte funktionieren und wie gestohlene Zugangsdaten, API Schlüssel, Unternehmensdaten und Exploits gehandelt werden.

Marc

Was ihr dort genau sehen werdet, hängt vom Abend ab, und das kann ich nicht vorwegnehmen. Aber der Hintergrund ist belegt. Marc Ruef hat 2016 an der Konferenz Swiss Cyber Storm einen Vortrag zu Darknet Investigations gehalten. Laut Beschreibung überwacht und analysiert scip das Darknet fortlaufend und untersucht die Schwarzmärkte für Drogen, Waffen, Daten und Verbrechen auf Bestellung. Es geht also nicht um eine Show mit Gruselfaktor, sondern um Marktbeobachtung. Wer verkauft was, wie organisieren sich die Akteure, wie werden Geschäfte abgewickelt?

Stefan

Und das ist für uns als Entscheider aufschlussreich. Wenn Zugangsdaten und Schlüssel dort als Ware gehandelt werden, ist Cybercrime ein Geschäftsmodell. Marc Ruef sagt das im Deloitte Interview ähnlich: Ransomware Gruppen arbeiten heute wie industrielle Dienstleister, mit klaren Rollen, Arbeitsteilung und Geschäftsmodellen. Das Wettrennen mit den Kriminellen geht weiter. Und er beobachtet erste, aber sehr ernste Auswirkungen von KI auf die Cybersicherheit, bei Unternehmen wie bei Kriminellen.

Marc

Seine Einschätzung der grössten Risiken ist ausgesprochen nüchtern. Der Diebstahl von Zugangsdaten bleibt das grösste Risiko, durch Phishing, Datendiebstahl und kompromittierte Benutzerkonten. Dazu wächst das Risiko durch Drittanbieter und Lieferketten. Das ist keine KI Aussage, das gilt für Unternehmen generell. Aber es passt erstaunlich gut zu den KI Fällen. Aus dem Jahr 2025 stammt das Beispiel eines Rekrutierungs Chatbots, über den 64 Millionen Bewerbungsdatensätze erreichbar waren. Der Grund war ein Standardpasswort. Kein raffinierter Angriff auf das Modell, sondern ein klassisches Passwortproblem.

Stefan

Das ist wirklich das, was in der Prüfung gefragt ist. Der Chatbot wirkt modern, die Schwachstelle ist alt. Ähnlich bei der Lieferkette. Die Firma JFrog meldete 2024 rund 100 bösartige Modelle auf der Plattform Hugging Face. Beim blossen Laden führten sie beliebigen Schadcode auf dem Server aus, Remote Code Execution. Ihr kauft oder ladet ein Modell und holt damit unbemerkt fremden Code ins eigene Netz. Deshalb steht die Lieferkette als eigene Bedrohung auf dem Cheat Sheet: Modelle, Datensätze, Bibliotheken und Plattformen bringen die Schwachstellen ihrer Herkunft mit.

Marc

Insgesamt fasst der Kurs die Bedrohungen in fünf Gruppen. Erstens Prompt Injection, die wir bei ISA Desk gesehen haben. Zweitens Data Poisoning mit den 250 Dokumenten. Drittens Adversarial Attacks, auch Evasion genannt, laut NIST AI 100 2. Das sind minimal veränderte Eingaben zur Laufzeit, die für Menschen unauffällig sind, aber ein Modell bei der Klassifikation von Text oder Bild in die Irre führen. Viertens Model Stealing: Über die Abfrageschnittstelle lässt sich ein Modell nachbauen, besonders wenn sie Konfidenzwerte mitliefert, so die Arbeit von Tramèr und Kollegen aus dem Jahr 2016. Fünftens die Lieferkette.

Stefan

Und dazu drei Risiken, die rund um KI oft übersehen werden. Datenabfluss, bei OWASP Sensitive Information Disclosure: Vertrauliches landet in öffentlichen KI Diensten oder kommt in Antworten wieder heraus. Zu viele Rechte, Excessive Agency: Das System darf mehr, als seine Aufgabe verlangt. Und klassische Lücken wie schwache Passwörter, offene Schnittstellen und ungepatchte Server. Das Cheat Sheet sagt dazu: oft das eigentliche Einfallstor. Dieses Sheet bekommt ihr nach dem Abend, mit den wichtigsten Zahlen und einer Checkliste.

Marc

Wie kommt man nun von dieser Liste zu etwas Brauchbarem für das eigene Projekt? Der Kurs bietet dafür das Threat Modeling an, mit vier Leitfragen von Adam Shostack. Erstens: Was bauen wir? Zweitens: Was kann schiefgehen? Drittens: Was tun wir dagegen? Viertens: Haben wir es gut gemacht? Es sind vier einfache Fragen, die man auch ohne technischen Hintergrund stellen kann.

Stefan

Der Anfang ist bewusst unspektakulär: Ihr zeichnet das System. Ein Datenflussdiagramm mit Komponenten, Datenflüssen und Vertrauensgrenzen, den sogenannten Trust Boundaries. Bei ISA Desk wären das etwa das Postfach der Mitglieder, das Cloud Modell, die Wissensbasis, die Zwischenschicht und die Mitgliederdatenbank. Überall dort, wo Daten eine Vertrauensgrenze überschreiten, stellt sich die Frage: Wer kann hier etwas einschleusen? Wer darf hier etwas lesen?

Marc

Dazu gehört ein Denkmuster von Microsoft: Assume Breach. Man nimmt an, dass es bereits passiert sein kann. Für KI heisst das konkret, davon auszugehen, dass Trainingsdaten und Datenlieferanten manipuliert sein können, und die Herkunft der Daten nachzuverfolgen. Bei ISA Desk bedeutet das: Die Wissensbasis ist keine heilige Quelle. Auch freigegebene Antworten sind nicht automatisch vertrauenswürdig, nur weil ein Mensch auf «Freigeben» geklickt hat. Genau das macht Reto Itens Vorschlag aus Tag 21 so heikel.

Stefan

Damit ihr nichts vergesst, gibt es Kataloge als Checklisten: die OWASP Top 10 für LLM Anwendungen in der Ausgabe 2025, mit zehn Kategorien von Prompt Injection bis Unbounded Consumption. Dazu MITRE ATLAS, eine Wissenssammlung zu Angriffen auf KI Systeme, und NIST AI 100 2. Ihr müsst sie nicht auswendig kennen. Ihr müsst wissen, dass es sie gibt und dass man mit ihnen systematisch durch das System gehen kann, statt sich auf das Bauchgefühl zu verlassen.

Marc

Dann folgt die Kontrollmatrix. Jede Bedrohung, die ihr identifiziert, bekommt drei Reaktionsstufen: verhindern, erkennen, reagieren. Auf Englisch Prevent, Detect, Respond. Und zu jeder Stufe gehören eine verantwortliche Person und der aktuelle Umsetzungsstand. Hier schliesst sich der Kreis zum Incident Plan. Die Spalte «reagieren» ist im Grunde das, was wir vorhin besprochen haben: Kill Switch, Fallback, Beweissicherung, Rollen, Meldung. Die Spalten «verhindern» und «erkennen» sind das, was Tag 20 mit dem Monitoring vorbereitet hat.

Stefan

Und weil man nicht alles gleichzeitig tun kann, wird priorisiert. Risiko ist Wahrscheinlichkeit mal Auswirkung, jeweils eingestuft in tief, mittel oder hoch. Das stammt aus der OWASP Risk Rating Methodology, die ausdrücklich empfiehlt, das Raster an die eigene Organisation anzupassen. Eine Verbandsgeschäftsstelle bewertet die Auswirkung eines Datenabflusses anders als ein Spital oder eine Bank. Das Lernziel des Abends lautet entsprechend: Security Findings priorisieren. Welches zuerst, und nach welchem Kriterium?

Marc

Ein Satz zur Prüfung. Gefragt ist beurteilen, nicht bauen. Ihr benennt Bedrohungen, ordnet Kontrollen zu, ordnet nach Risiko und begründet. Typische Incidents, die das Cheat Sheet nennt: ein Chatbot, der sich umprogrammieren lässt, Vertrauliches in einem öffentlichen KI Dienst und ein Modell aus unsicherer Quelle. Und der häufigste Grund für Punktverluste ist, nur das Modell anzuschauen und die klassischen Lücken rundherum zu vergessen.

Stefan

Fassen wir zusammen, was ihr mitnehmt. KI Systeme erben alle klassischen Sicherheitsrisiken und bringen neue mit. Sie lassen sich über Sprache steuern, über Daten vergiften, über Schnittstellen kopieren und über ihre Lieferkette angreifen. Ein Threat Model macht das sichtbar, eine Kontrollmatrix ordnet Gegenmassnahmen zu, und die Bewertung zeigt, was zuerst dran ist. Und ein Incident Plan mit Namen, Vertretungen und einer Reissleine sorgt dafür, dass ihr im Ernstfall nicht im Überlebensmodus landet.

Marc

Mein Vorschlag für heute Abend: Hört Marc Ruef als Angreifer zu und übersetzt jede Beobachtung in eine Zeile eurer Matrix. Was ist die Bedrohung, wie verhindere, erkenne und beantworte ich sie, und wer ist dafür namentlich zuständig? Wenn ihr um 20:00 Uhr in die Projektwerkstatt geht, habt ihr dann nicht nur Wissen, sondern einen ersten Entwurf für euer eigenes Projekt.

Stefan

Dann bis um 16:50 Uhr im Zoom Raum. Viel Erfolg heute Abend.