Claude ist neu im Team – und hat kein Onboarding bekommen.
Viele Unternehmen in der DACH-Region haben seit kurzem ein neues Teammitglied. Dieses ist ausserordentlich umtriebig, arbeitet gleichzeitig in mehreren Teams und Abteilungen – und je nachdem, auf welchem Stockwerk man steht, hört es auf einen anderen Namen. Meistens ist es Claude. Manchmal Codex. In einem Team, das wir kürzlich begleitet haben, hiess der Neuzugang Hermes.
Man begegnet ihnen auf dem Flur, in Stand-ups, in der Kaffeeküche:
«Ich habe mit Claude mein Excel angepasst.»
«Codex hat mir eine neue Oberfläche für meine Access-Datenbank gebaut.»
«Hermes organisiert jetzt alle meine Kalendereinträge automatisch.»
Das sind keine Zitate aus einer Studie. Das sind Sätze, die wir seit Wochen in unseren Projekten und Langzeitmandaten hören, von Menschen, die nicht in der IT arbeiten, sondern im Controlling, im Verkauf, im Kundendienst.
Claude ist dabei nur ein Beispiel. Das von Anthropic entwickelte KI-Modell Claude basiert auf einem Large Language Model (LLM) und kann längst mehr als Texte erzeugen: Es entwickelt Anwendungen, automatisiert Abläufe und kann mit anderen Tools zusammenarbeiten. Damit wird die eigene Entwicklung von Anwendungen zunehmend auch für Menschen möglich, die bisher nicht selbst Software entwickelt oder Prozesse automatisiert haben.
Damit verändern KI-Assistenten, wie wir arbeiten. Was früher einen Entwicklungsauftrag, ein Budget oder Monate Projektlaufzeit gebraucht hätte, entsteht mit AI-Coding-Tools und Vibe Coding heute innerhalb weniger Stunden.
KI verändert die Arbeitswelt. Und das ist zunächst einmal eine gute Nachricht.
Denn was hier passiert, ist genau das, was Digitalisierungsprogramme seit einem Jahrzehnt versprechen und selten liefern: Ideen, die jahrelang liegengeblieben sind, werden endlich umgesetzt. Nicht in einem Projektportfolio mit Priorisierungsrunde, sondern an einem Dienstagnachmittag.
Die spannende Frage ist deshalb nicht, ob Mitarbeitende diese Möglichkeiten nutzen sollten. Sie tun es längst. Die Frage ist, wie Unternehmen damit umgehen, wenn aus einem KI-Assistenten im Arbeitsalltag plötzlich ein Werkzeug für die eigene Entwicklung, Automatisierung und Prozessunterstützung wird – und dabei dieselben Sicherheits- und Qualitätsanforderungen gelten, wie für alles andere, was im Unternehmen entsteht.
Ein Beispiel aus einem unserer Projekte:
«Für meine Applikation wollte ich schon immer eine Oberfläche für den Kundenzugang. Die interne Softwareentwicklung hatte aber nie Kapazität. Jetzt konnte ich es selbst bauen und mein Chef ist begeistert! Die Kunden können unsere Applikation direkt nutzen.»
Das ist kein Kontrollverlust. Das ist ein Mitarbeitender, der eine echte Lücke geschlossen hat, ohne auf ein Budget zu warten. Wer solche Initiative als Problem behandelt, riskiert vor allem, die Chancen dieser Entwicklung zu verspielen.
Was früher als Citizen Development mit Excel-Makros oder Access-Datenbanken begann, bekommt durch KI-Coding-Tools und Vibe Coding eine neue Dimension: Mitarbeitende können heute in kurzer Zeit Anwendungen entwickeln, für die früher klassische Softwareentwicklung nötig gewesen wäre.
Ziel sollte also sein, diese Entwicklung sinnvoll zu gestalten und für sich zu nutzen. Denn diese Werkzeuge werden uns noch eine ganze Weile begleiten und Menschen in Bereichen befähigen, zu denen sie vorher keinen Zugang hatten. Genau deshalb schreiben wir diesen Beitrag nicht als Warnung. Sondern als Beobachtung aus der Praxis.
Der Moment, in dem es kippt: Wenn neue Entwicklungen auf alte Prozesse treffen
Für Es ist nicht die Eigenentwicklung selbst, die problematisch ist. Es ist die Lücke zwischen neuer Entwicklungspraxis und den bestehenden Prozessen, wenn Mitarbeitende Anwendungen ausserhalb etablierter Prozesse entwickeln.
Denn dieselbe Applikation, über die der Chef sich freute, sah in der Prüfung so aus:
Das interne Programm war nie mandantenfähig konzipiert. Es war ein internes Werkzeug für interne Menschen mit internen Berechtigungen. Der neue Kundenzugang aus dem Internet hat ein sauberes, separates Login bekommen, daran hatte der Erbauer durchaus gedacht. Nur: Hinter dem Login greift die Applikation weiterhin auf denselben gemeinsamen Datenbestand zu, ohne zu prüfen, welcher Datensatz zu welchem Kunden gehört. Das bedeutet: Wer angemeldet ist, sieht mit einer minimalen Veränderung an der Anfrage die Daten aller anderen Kunden.
Kein Hackerangriff. Keine Zero-Day-Schwachstelle. Eine fehlende Prüfung, die in jedem strukturierten Entwicklungsprozess an einem Review-Gate aufgefallen wäre.
Nur ist dieser Code nie an einem Review-Gate vorbeigekommen. Er ist an der internen Qualitätskontrolle der Softwareentwicklung vorbeigelaufen – nicht heimlich, nicht böswillig, sondern schlicht, weil dieser Weg gar nicht vorgesehen war. Der Prozess kennt Anforderungen, Tickets, Sprints und Freigaben. Er kennt keinen Fachbereich, der am Freitagnachmittag eine kundenfähige Weboberfläche fertigstellt.
Genau hier liegt die eigentliche Herausforderung: Mitarbeitende bauen mit KI eigene Anwendungen. Aus einer kleinen Lösung für den eigenen Arbeitsalltag kann dabei schnell eine echte Business-Anwendung werden. Die Aufgabe der Organisation ist es, diese Entwicklung nicht zu unterbinden, sondern einen klaren und sicheren Rahmen für ihre Nutzung zu schaffen.
Und der engagierte Mitarbeitende aus der Fachabteilung? Ihm hat niemand gesagt, dass eine Applikation mit Kundenzugang etwas anderes ist als ein internes Werkzeug mit Login. Der Fokus lag auf dem, was zählt: Produktivität, Innovation, am Markt bestehen.
Das ist kein Vorwurf, das ist der Normalfall.
KI-Governance statt Verbote: Mitarbeitende sicher arbeiten lassen
Auch wenn viele Organisationen impulsiv mit einer Sperrung reagieren und dieser Reflex sehr nachvollziehbar ist: Er funktioniert nicht und verschlechtert die Lage.
Denn die Nutzung hört nicht auf, sie kann auf private Konten und Geräte ausweichen – und aus einem sichtbaren Risiko wird ein unsichtbares: Shadow AI. Das Unternehmen verliert die Übersicht und gleichzeitig den Produktivitätsgewinn.
Es ist also wichtig zu erkennen, dass das Problem nicht darin liegt, dass jemand mit Claude und Vibe Coding eine Anwendung gebaut hat. Das Problem entsteht dort, wo mit Vibe Coding Anwendungen entstehen, für die die bisherigen Sicherheits- und Entwicklungsprozesse nie gedacht waren.
Die entscheidende Frage ist deshalb nicht, ob Mitarbeitende mithilfe von KI und Vibe Coding eigene Anwendungen entwickeln. Sie tun es bereits. Die Frage ist, ob die Organisation dafür einen sicheren und praktikablen Weg geschaffen hat.
Die Alternative ist deshalb zwar unbequemer, aber sie funktioniert: einen klaren, sanktionierten Weg schaffen, der schneller ist als der inoffizielle. Einen Freigabeprozess, der in Tagen antwortet statt in Quartalen. Einen, den Ihre Mitarbeitenden benutzen wollen, statt ihn zu umgehen.
Damit wird aus AI-Governance mehr als ein Regelwerk. Es braucht klare Verantwortlichkeiten:
Wer darf welche Anwendungen und Daten nutzen? Wer prüft neue KI-gestützte Anwendungen? Und wer entscheidet, wann aus einer persönlichen Produktivitätshilfe eine Anwendung wird, die sicherheitsrelevant oder geschäftskritisch ist?
Und auch die eingesetzten KI-Tools brauchen einen klaren Rahmen: saubere Anonymisierung, vertraglich geregelte Datenverarbeitung und die Regel, dass kein maschineller Befund ungeprüft in einen Bericht gelangt. Gerade bei Unternehmens- und Kundendaten muss nachvollziehbar sein, unter welchen Bedingungen ein Tool eingesetzt werden darf und wo menschliche Prüfung unverzichtbar bleibt.
Denn der Mitarbeitende aus dem obigen Beispiel ist nicht das Risiko. Sobald er weiss, worauf es ankommt, ist er der beste Kontrollpunkt, den die Organisation haben kann.
Mit unserem Business Application Security Check unterstützen wir Sie dabei, Risiken frühzeitig zu erkennen und Anwendungen aus den Fachbereichen sicher in Betrieb zu nehmen:
Zum Business Application Security Check
KI Governance: Wie Unternehmen KI-gestützte Eigenentwicklung sicher ermöglichen
Das ist die eigentliche Aufgabe von KI-Governance: Transparenz schaffen, Risiken dort prüfen, wo sie relevant sind, und einen Rahmen schaffen, in dem Fachbereiche eigenständig arbeiten können. Aus unserer Praxiserfahrung lassen sich dabei drei wichtige Aufgaben ableiten:
Drei wichtige Aufgaben für Unternehmen:
- Wissen, was entsteht.
Nicht jede mit KI erstellte Anwendung ist automatisch ein Sicherheitsrisiko. Aber Unternehmen sollten wissen, wo solche Anwendungen entstehen, welche Daten sie verarbeiten und welche Rolle sie im Unternehmen und im jeweiligen Fachbereich spielen. Erst dann lässt sich einschätzen, was geprüft werden muss und wo Risiken tatsächlich relevant sind. - Prüfen, bevor aus einer Idee eine Business-Anwendung wird.
Eine kleine Automatisierung für den persönlichen Arbeitsalltag ist etwas anderes als eine Anwendung, über die Kunden auf Unternehmensdaten zugreifen. Je näher eine KI-gestützte Anwendung an Kunden, Geschäftsprozesse oder sensible Daten kommt, desto wichtiger werden definierte Prüfungen und klare Verantwortlichkeiten. Dabei geht es nicht nur um offensichtliche Schwachstellen. Fehlende Trennung zwischen Kundendaten, zu weit gefasste Berechtigungen, Zugangsdaten im Code oder ungeprüfte Eingaben sind typische Punkte, die auch bei KI-gestützt entwickelten Anwendungen berücksichtigt werden müssen. Entscheidend ist, dass solche Fragen nicht erst nach dem Go-live gestellt werden. - Einen Weg schaffen, der schneller ist als das Umgehen.
Wenn Freigaben Monate dauern, bauen Mitarbeitende oftmals trotzdem weiter. Ein sicherer Prozess muss deshalb nicht nur sicher, sondern auch praktikabel sein: mit klaren Zuständigkeiten, verständlichen Anforderungen und einem Tempo, das zur neuen Arbeitsweise passt. Schnelle Freigabeprozesse sind dabei kein Komfortmerkmal, sondern eine Voraussetzung dafür, dass Sicherheitsanforderungen im Arbeitsalltag tatsächlich funktionieren.
«Ein Sicherheitsprozess ist nur dann gut, wenn Menschen ihn auch nutzen.
Sicherheit, die umgangen wird, ist keine sichere Lösung.»
Fazit: Wissen, was entsteht. Prüfen, was relevant ist. Ermöglichen, was sinnvoll ist.
Das ist aus unserer Sicht der entscheidende Perspektivwechsel: KI-Governance bedeutet nicht, Innovation zu kontrollieren, bis sie nicht mehr stattfindet. Sie bedeutet, einen Rahmen zu schaffen, in dem Innovation stattfinden kann, ohne dass Sicherheit und Verantwortung auf der Strecke bleiben.
Und genau das verändert auch die Rolle des neuen Mitarbeiters. Claude bleibt schnell, experimentierfreudig und erstaunlich produktiv. Sein Onboarding besteht nicht aus einem Willkommensgespräch und einem Zugangsbadge. Es besteht aus Regeln, Leitplanken, Verantwortlichkeiten und Prozessen, die dafür sorgen, dass aus einer guten Idee auch eine gute und sichere Anwendung wird.
Vielleicht ist das die spannendste Seite dieser Entwicklung: Wir erleben gerade nicht nur, wie KI in Unternehmen Einzug hält. Wir erleben, wie sich dadurch verändert, wer im Unternehmen welche Dinge entwickeln und umsetzen kann.
Die Aufgabe der Organisation ist nicht, diese Entwicklung aufzuhalten. Sondern dafür zu sorgen, dass sie sicher gelingen kann.
Wenn Sie sich fragen, wie Sie neue Business-Applikationen sicher ermöglichen, was in Ihrer Organisation bereits entstanden ist und wie damit sicher umgegangen werden kann, begleiten wir Sie gerne bei der Standortbestimmung, der Sicherheitsprüfung und beim Aufbau passender Prozesse. Kontaktieren Sie uns hierzu jederzeit gerne!
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
OT Asset Discovery: Best Practices für die sichere OT-Inventarisierung
In industriellen Umgebungen fehlt häufig eine vollständige Übersicht über die eingesetzten OT-Systeme. Ältere oder undokumentierte Komponenten, über Jahre gewachsene Netzwerkstrukturen, Verbindungen zwischen IT und OT sowie externe Zugänge können dazu führen, dass Teile der OT-Infrastruktur im aktuellen Asset-Inventar nicht erfasst sind. Dadurch können potenzielle Angriffsflächen und Abhängigkeiten unter Umständen unentdeckt bleiben.
OT sollte dabei nicht isoliert von der IT betrachtet werden: Gerade Schnittstellen, gemeinsam genutzte Dienste und externe Zugänge können relevante Angriffswege darstellen. Gleichzeitig erfordern OT-Systeme aufgrund ihrer Anforderungen an Verfügbarkeit und Betriebssicherheit einen anderen Umgang mit Security-Massnahmen als klassische IT-Systeme.
Ein aktuelles Asset-Inventar ist Voraussetzung, um Abhängigkeiten sichtbar zu machen, potenzielle Angriffsflächen zu erkennen und Sicherheitsmassnahmen gezielt abzuleiten.
Was ist OT Asset Discovery?
OT Asset Discovery umfasst die automatisierte Erkennung und Inventarisierung von OT-Assets. Sie erfasst die im definierten Scope sichtbaren Geräte, Systeme und Kommunikationsverbindungen eines OT-Netzwerks und klassifiziert sie nach relevanten Merkmalen. So schafft sie Transparenz über die vorhandenen Komponenten – von SPS (speicherprogrammierbaren Steuerungen) und RTUs (Remote Terminal Units) bis zu Feldgeräten –, über Verbindungen zwischen IT und OT sowie über die Kommunikation der Systeme. Sie zeigt zudem, welche Aufgaben die Komponenten erfüllen und wie kritisch sie für den Betrieb sind. Diese Informationen bilden eine wichtige Grundlage, um Risiken zu bewerten, Sicherheitsmassnahmen gezielt abzuleiten und im Ernstfall schnell reagieren zu können.
Asset Discovery in OT-Umgebungen ist jedoch nicht mit einem beliebigen Netzwerk-Scan gleichzusetzen. Aktive Abfragen können insbesondere bei älteren, empfindlichen oder unzureichend dokumentierten Komponenten den Betrieb beeinträchtigen. Entscheidend sind deshalb die passende Methode, ein klar definierter Scope sowie ein kontrolliertes, mit dem Betrieb abgestimmtes Vorgehen.
Wir haben für Sie herausgearbeitet, welche Ansätze sich für die OT-Asset-Inventarisierung eignen, wann passive, aktive oder hybride Methoden sinnvoll sind und wie sich OT Asset Discovery strukturiert und möglichst sicher umsetzen lässt. Ausserdem geht es um typische Fehler und darum, wie Unternehmen ihr OT-Asset-Inventar dauerhaft aktuell halten und für Sicherheits- sowie Compliance-Anforderungen nutzbar machen.
«Ein aktuelles OT-Asset-Inventar ist eine zentrale Grundlage für wirksames Risikomanagement, die Umsetzung von Sicherheitsmassnahmen und die Erfüllung relevanter Compliance-Anforderungen.»
Best Practices & Methoden der OT Asset Discovery: Passiv, aktiv, hybrid
Für die Erfassung von OT-Assets stehen passive, aktive und hybride Verfahren zur Verfügung. Welche Methode geeignet ist, hängt von der Umgebung, den eingesetzten Systemen und den Anforderungen an Verfügbarkeit und Detailtiefe ab. Entscheidend ist ein kontrolliertes Vorgehen, das die Betriebssicherheit berücksichtigt.
- Passive Discovery analysiert den Netzwerkverkehr, ohne Geräte direkt abzufragen. Je nach Protokoll und verfügbarer Kommunikation lassen sich dabei Informationen wie Gerätetyp, Hersteller, Firmware-Version oder Kommunikationsbeziehungen ableiten. Sie eignet sich besonders für den Einstieg und die kontinuierliche Überwachung, da sie den laufenden Betrieb in der Regel nicht beeinträchtigt. Dabei lassen sich auch ältere oder nicht dokumentierte Komponenten sowie Kommunikationsverbindungen erkennen.
- Aktive Discovery fragt Systeme gezielt ab, um zusätzliche Informationen wie Firmware-Versionen oder Konfigurationen zu erfassen. Sie kann insbesondere ältere oder empfindliche SPS und RTUs beeinträchtigen. Aktive Scans sollten deshalb vorab geprüft, abgestimmt und kontrolliert durchgeführt werden – vorzugsweise in Wartungsfenstern oder, sofern verfügbar, in einer Testumgebung.
- Hybride Ansätze kombinieren beide Methoden: Passive Verfahren sorgen für kontinuierliche Sichtbarkeit, aktive Abfragen ergänzen gezielt fehlende Detailinformationen. So lassen sich Genauigkeit und Betriebssicherheit bestmöglich verbinden. Hybride Ansätze haben sich insbesondere in KRITIS-Umgebungen bewährt, um hohe Genauigkeit und Betriebssicherheit bestmöglich zu verbinden.
Kennen Sie Ihre OT-Assets? Mit unseren OT Security Services helfen wir Ihnen dabei, Ihre OT-Assets und Schlüsselkomponenten zu erfassen und zu verifizieren, die Architektur nach dem Defence-in-Depth-Ansatz aufzubauen, die Sicherheit nach IEC 62443 umzusetzen, ein geeignetes Supplier-Risk-Management zu etablieren und so eine belastbare Grundlage für gezielte Schutzmassnahmen zu schaffen:
Mit dem 5-Schritte-Plan zur sicheren OT-Asset-Discovery
Eine strukturierte Vorgehensweise hilft, Risiken bei der Asset-Erfassung zu minimieren. Dafür sollten zunächst Scope, Prioritäten, Erfassungsfrequenz und Verantwortlichkeiten festgelegt und relevante Stakeholder aus OT, IT und Management einbezogen werden. So wird die Asset Discovery nachvollziehbar und systematisch umgesetzt, ohne kritische OT-Systeme unnötig zu belasten.
1. Scope definieren:
- Welche Standorte, Netzwerksegmente und Zonen sollen erfasst werden? Dazu gehören beispielsweise Kraftwerke, Umspannstationen, VLANs für Steuerungssysteme oder externe Zugänge für Fernwartung und Cloud-Dienste
2. Passives Monitoring starten:
- Die passive Erfassung liefert zunächst ein Grundgerüst der vorhandenen OT-Assets, ohne aktiv in die Kommunikation der Systeme einzugreifen.
3. Assets klassifizieren:
- Die erfassten Assets sollten nach Funktion, Kritikalität und Verantwortlichkeit kategorisiert werden, beispielsweise als Steuerungs-, Überwachungs- oder Wartungssystem.
4. Gezielte aktive Prüfungen durchführen:
- Aktive Scans können zusätzliche Informationen wie Firmware-Versionen liefern. In sensiblen OT-Umgebungen sollten sie jedoch nur kontrolliert, mit ausreichend Erfahrung, nach Abstimmung mit dem Betrieb und innerhalb definierter Wartungsfenster eingesetzt werden.
5. Inventar aktuell halten:
- Das Asset-Inventar sollte regelmässig aktualisiert und, wo möglich, automatisiert mit einer CMDB (Configuration Management Database) synchronisiert werden. So bleibt die Übersicht auch bei Veränderungen in der OT-Umgebung verlässlich.
3 Typische Fehler bei der OT-Asset-Inventarisierung – und wie Sie sie vermeiden
Eine vollständige Asset-Liste allein reicht nicht aus. Entscheidend ist, dass die erfassten Informationen aktuell und eindeutig zugeordnet sind. Denn unvollständige Inventare, fehlende Priorisierung oder unklare Verantwortlichkeiten können Sicherheits- und Compliance-Risiken erhöhen. Besonders häufig treten bei der OT Asset Discovery folgende Fehler auf:
- Zu aggressive Scans: Aktive Scans können sensible Systeme wie SPS oder RTUs beeinträchtigen. Deshalb sollte die Erfassung zunächst passiv erfolgen. Aktive Verfahren sollten vorab in geeigneten Testumgebungen geprüft und anschliessend kontrolliert eingesetzt werden.
- Unübersichtliche Asset-Listen: Ohne klare Klassifizierung wird das Inventar schnell unübersichtlich. Informationen wie Firmware-Version, Seriennummer, Funktion, Kritikalität und Verantwortlichkeit sollten strukturiert erfasst und, wo möglich, automatisch angereichert werden. Das ist auch im Ernstfall relevant: Bei einem Ransomware-Angriff muss schnell erkennbar sein, welche Systeme potenziell betroffen sein könnten, welche Abhängigkeiten und Kommunikationsbeziehungen bestehen und welche OT-Komponenten priorisiert geschützt, isoliert oder wiederhergestellt werden müssen.
- Fehlende Verantwortlichkeiten: Für jedes Asset sollte klar sein, wer für Betrieb, Wartung und Sicherheit verantwortlich ist. Eine eindeutige Zuordnung erleichtert unter anderem die Überwachung, Wartung und Behebung von Schwachstellen. Die Integration des Inventars in eine CMDB kann dabei unterstützen.
Fazit: Asset Discovery als Grundlage für OT-Sicherheit
Ein aktuelles OT-Asset-Inventar schafft die notwendige Transparenz für verschiedene Bereiche der OT-Sicherheit. Es hilft dabei,
- Sicherheitsrisiken sowie potenzielle Angriffsflächen zu bewerten und Schutzmassnahmen gezielt abzuleiten,
- Angriffe schneller einzuordnen, weil bekannt ist, welche Systeme potenziell betroffen sind,
- im Incident Response gezielt zu reagieren, weil Abhängigkeiten, Kommunikationsbeziehungen und Verantwortlichkeiten nachvollziehbar sind,
- ein SOC bei der kontinuierlichen Überwachung zu unterstützen, da Warnmeldungen anhand von Gerätetyp, Funktion und Kritikalität besser priorisiert werden können,
- und Compliance-Anforderungen im Informationssicherheit- und Risikomanagement zu unterstützen.
Deswegen ist OT Asset Discovery kein einmaliger Erfassungsschritt, sondern ein fortlaufender Prozess. Nur ein aktuelles und verlässliches Asset-Inventar kann dauerhaft als Grundlage für Sicherheitsentscheidungen dienen. Bei Fragen zur passenden Methode oder zur Auswahl und Implementierung geeigneter Tools stehen wir Ihnen gerne zur Verfügung.
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
MDR mit KI: Warum Expertise und Datenhoheit entscheidend sind
Die aktuelle Cyberlage erschwert es Sicherheitsverantwortlichen zunehmend, Angriffe frühzeitig zu erkennen und richtig einzuordnen. KI-gestützte Aufklärung, Exploit-Generierung und laterale Bewegungen innerhalb kompromittierter Umgebungen gehören inzwischen zur operativen Realität. Gleichzeitig erschweren «Living-off-the-Land (LOTL)»-Techniken mit missbräuchlich eingesetzten legitimen Systemwerkzeugen, cloudbasierte Infrastrukturen und automatisierte Angriffsketten die Detektion.
Auch die Incident-Response-Praxis zeigt, wie komplex die Einordnung geworden ist. Angriffe überschreiten regelmässig die Grenzen zwischen lokalen Systemen, Cloud-Diensten und Identitäten. Erst wenn Cyber Defence relevante Endpoint-, Netzwerk-, Identity-, Cloud- und Applikationsdaten zusammenführt, werden Zusammenhänge entlang einer Angriffskette wesentlich besser erkennbar.
Damit rückt eine zentrale Herausforderung in den Fokus: Die Menge erkannter Signale allein sagt wenig über die tatsächliche Bedrohung aus. Sicherheitsverantwortlichen bleibt immer weniger Zeit, einen möglichen Angriff einzuordnen, das Risiko zu bewerten und die erforderliche Reaktion festzulegen.
Wie unterstützt KI im MDR fundierte Sicherheitsentscheidungen?
KI im MDR führt Security-Signale aus verschiedenen Quellen zusammen und macht Zusammenhänge erkennbar, die einzelne Alerts nicht zeigen. KI analysiert grosse Datenmengen, reichert Informationen an, gruppiert zusammengehörende Alerts und priorisiert Risiken. Zudem kann sie erste Attack Stories aufbauen, die mögliche Angriffsszenarien strukturieren. Attack Stories verknüpfen somit Einzelsignale zu einer nachvollziehbaren Hypothese über Verlauf und möglichen Umfang eines Angriffs. Auch nächste Analyseschritte kann die KI vorschlagen.
Wie relevant diese Kontextualisierung ist, zeigt ein einfaches Szenario: Ein verdächtiger Login, eine neu eingerichtete Mailbox-Regel und ein ungewöhnlicher Prozess auf einem Endgerät liefern isoliert betrachtet noch kein eindeutiges Bild. Führt MDR diese Ereignisse zusammen, zeichnet sich das Muster einer möglichen Account-Übernahme ab.
KI verkürzt den Weg vom einzelnen Signal zum priorisierten Gesamtbild. Fachpersonen nutzen diesen Kontext, um die Situation früher einzuordnen und Handlungsoptionen abzuwägen. So entsteht ein Entscheidungsvorsprung, einen sogenannten «Decision Advantage».
Doch ein schnell erzeugtes Gesamtbild allein schafft noch keine belastbare Grundlage für sicherheitskritische Entscheidungen.
Human-AI-Teaming: KI analysiert, Fachpersonen entscheiden
Human-AI-Teaming verbindet maschinelle Analysegeschwindigkeit mit menschlichem Urteilsvermögen. KI bereitet Analysen und Handlungsoptionen vor: Fachpersonen prüfen Hypothesen, beziehen den Unternehmenskontext ein und entscheiden über Eskalation, Kommunikation und Response. Kritische Response-Massnahmen erfolgen dabei nach Freigabe durch Fachpersonen oder innerhalb klar definierter Regeln.
Diese Arbeitsteilung verändert auch den SOC-Alltag. Manuelle Abfragen, Wechsel zwischen unterschiedlichen Konsolen oder das Zusammenführen einzelner Informationen beanspruchen wertvolle Analysezeit. KI und Automatisierung reduzieren diesen manuellen Aufwand. Fachpersonen konzentrieren sich stärker auf Validierung, Kontextualisierung, Qualitätssicherung und Kundenkommunikation.
Vertrauen in dieses Zusammenspiel setzt zugleich voraus, dass der Umgang mit sensiblen Security-Daten kontrollierbar und nachvollziehbar bleibt.
Security-Telemetrie macht Datenhoheit zur Sicherheitsfrage
Security-Telemetrie kann Identitäten, Systeme, Berechtigungen, Schwachstellen und kritische Geschäftsprozesse offenlegen. Sie umfasst beispielsweise Login-Ereignisse, Endpunktaktivitäten, Netzwerkverbindungen sowie Cloud- und E-Mail-Protokolle. Wer KI im MDR einsetzt, muss deshalb nachvollziehen können, welche Daten sie verarbeitet, zu welchem Zweck, wie lange und an welchem Ort.
Die Anforderungen an Datensouveränität, Governance und Compliance bestimmen das passende Betriebsmodell für die LLM-Datenprozessierung. Je nach Vorgaben kann die Verarbeitung innerhalb der EU oder in der Schweiz erfolgen. Für besonders hohe Anforderungen an die Datenlokalität kommt auch dedizierte KI-Hardware in der Schweiz infrage.
Die technische Umgebung richtet sich damit nach den jeweiligen regulatorischen und unternehmensspezifischen Anforderungen. AI by Design verankert diesen Grundsatz bereits in der Architektur: Datenminimierung, Zweckbindung, sichere Datenflüsse, Auditierbarkeit, Guardrails und menschliche Aufsicht werden von Beginn an berücksichtigt. So lässt sich festlegen, welche Daten die KI wofür nutzt und wo menschliche Kontrolle erforderlich bleibt.
Was vertrauenswürdiges MDR mit KI auszeichnet
Entscheidend ist das Zusammenspiel von KI, menschlicher Expertise und einem kontrollierten Umgang mit sensiblen Security-Daten:
- KI schafft Tempo: Sie verdichtet Security-Signale, macht Zusammenhänge sichtbar und bereitet priorisierte Handlungsoptionen vor.
- Menschliche Expertise sichert die Entscheidung: Fachpersonen validieren Ergebnisse, bringen den Unternehmenskontext ein und verantworten sicherheitskritische Entscheidungen.
- Datenhoheit stärkt das Vertrauen: AI by Design und passende Betriebsmodelle sorgen für eine kontrollierte und nachvollziehbare Verarbeitung sensibler Security-Daten.
So entsteht aus Geschwindigkeit, Expertise und Kontrolle eine fundierte Entscheidungsgrundlage, um relevante Bedrohungen früher einzuordnen und gezielt zu handeln. Entscheidend ist dabei nicht nur, was MDR leistet, sondern auch, wie und wo sicherheitskritische Daten verarbeitet werden. Unsere Fachpersonen unterstützen Sie dabei, MDR auf Ihre Anforderungen an Cyber Defence, Datenhoheit und Compliance auszurichten.
Deep Dive: MDR mit KI aus der Cyber-Defence-Praxis
Wie verändert KI Managed Detection & Response und worauf kommt es bei ihrem Einsatz an? Im vollständigen Fachartikel und Interview vertieft Michael Stampfli, Head of Cyber Defence Services & Operations bei InfoGuard, die Zusammenhänge zwischen KI-gestützter Analyse, menschlicher Expertise und Datenhoheit.
Fachartikel und Interview liefern eine fundierte Einordnung aus der Cyber-Defence-Praxis und zeigen, wie MDR auch unter steigendem Entscheidungsdruck schnelle und nachvollziehbare Sicherheitsentscheidungen unterstützt.
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
Cyber Security im Realitätscheck: Wie compliant ist Ihr Unternehmen wirklich?
Sicherheitsmassnahmen können etabliert, Prozesse definiert und regulatorische Anforderungen bekannt sein. Entscheidend ist, ob sie in der Praxis den angestrebten Sicherheitszustand tatsächlich erreichen. Die Differenz zwischen Annahme und belegbarem Ist-Zustand wird besonders relevant, wenn neue Vorgaben, technische Veränderungen oder unternehmerische Entscheidungen eine belastbare Standortbestimmung verlangen. Gap Assessments und Audits sind deshalb besonders relevant für Unternehmen, die:
- Anforderungen aus Standards und Regulierungen wie ISO 27001, NIS2, DORA oder den IKT-Minimalstandard erfüllen müssen;
- nach einer Cloud-Migration oder Unternehmensübernahme Klarheit über ihre aktuelle Sicherheitslage brauchen;
- gegenüber Management und Auditor:innen fundierte Aussagen zur Risikolage machen müssen;
- vor einer ISO-27001-Zertifizierung ihren Reifegrad systematisch erheben.
Warum der Ist-Zustand der Cybersecurity oft trügt
Der wahrgenommene Sicherheitsstand kann vom tatsächlichen Ist-Zustand abweichen. Sicherheitsverantwortliche arbeiten mit einer mentalen Karte ihrer Organisation. Sie kennen die Systeme, die Massnahmen, die grössten Risiken. Diese Karte bildet die Realität selten vollständig ab.
Typische blinde Flecken, die ein strukturiertes Assessment aufdeckt:
- Richtlinien existieren auf Papier, werden aber im Alltag nicht konsequent gelebt.
- Zugriffsrechte wurden einmal korrekt vergeben und nach Umstrukturierungen nicht angepasst.
- Cloud-Umgebungen sind über Zeit gewachsen, ohne dass Berechtigungen und Konfigurationen systematisch nachgeführt wurden.
- Lieferanten sind tief in kritische Prozesse eingebunden, wurden aber nie auf Sicherheitsanforderungen geprüft.
- KI-Systeme wurden eingeführt, ohne die neuen Angriffsflächen systematisch zu bewerten.
Ein Blick von aussen hilft, solche blinden Flecken objektiv einzuordnen. Er ergänzt die fachliche Kompetenz interner Teams und zeigt auf, wo der tatsächliche Sicherheitsstand von der eigenen Einschätzung abweicht.
Welche Standards und Regulierungen deckt ein Gap Assessment ab?
Ein Gap Assessment kann den Ist-Zustand unter anderem mit Anforderungen aus NIS2, DORA, ISO/IEC 27001, dem Cyber Resilience Act oder branchenspezifischen Schweizer Vorgaben abgleichen. Welche davon relevant sind, hängt von Branche, Unternehmensstandort und Zielsetzung ab. Während die Bedrohungen zunehmen, wachsen die regulatorischen Vorgaben, die Organisationen berücksichtigen müssen.
- NIS2 (EU): Gilt für wesentliche und wichtige Einrichtungen in 18 Sektoren, für Schweizer Unternehmen relevant über EU-Tochtergesellschaften und Lieferkettenanforderungen.
- DORA: Gilt seit dem 17. Januar 2025 für Finanzunternehmen und deren IKT-Drittdienstleister mit konkreten Anforderungen an die digitale operationale Resilienz.
- ISO/IEC 27001:2022: Internationaler Standard für Informationssicherheits-Managementsysteme, Basis für externe Zertifizierungen.
- Cyber Resilience Act (CRA): EU-Verordnung mit Anforderungen an die Cybersicherheit von Produkten mit digitalen Elementen.
- FINMA RS 23/1 (Schweiz): Anforderungen an das Management operationeller Risiken und die operationelle Resilienz von Banken und Wertpapierhäusern, inklusive IKT- und Cyberrisiken.
- IKT-Minimalstandard (Schweiz): Empfehlung des BWL für kritische Infrastrukturen, im Strombereich über die StromVV für Netzbetreiber verbindlich erklärt.
Die Anforderungen sind komplex und entwickeln sich laufend weiter. Ein Gap Assessment macht sichtbar, welche relevanten Anforderungen bereits erfüllt sind und wo noch Lücken bestehen. Für regulierte Sektoren arbeiten wir mit dem jeweils vorgeschriebenen Rahmen, für eine offene Standortbestimmung meist mit NIST CSF 2.0.
Sie möchten wissen, welche Sicherheitslücken in Ihrer Organisation möglicherweise noch unentdeckt sind? Unsere Cyber Security Assessments schaffen eine belastbare Standortbestimmung und zeigen, wo Handlungsbedarf besteht.
Welcher Assessment-Typ passt zu Ihrer Ausgangslage?
Je nach regulatorischer, technischer oder organisatorischer Ausgangslage kommen unterschiedliche Assessment-Typen zum Einsatz. Sie bewerten die Sicherheitslage anhand der Anforderungen, die für das jeweilige Unternehmen relevant sind.
Compliance und Zertifizierung
- ISO/IEC 27001:2022 Assessment: Vorbereitung auf Erstzertifizierung oder Überprüfung eines bestehenden ISMS.
- NIS2 & DORA Compliance Assessment: Gap Assessment mit konkretem Massnahmenplan zur Erfüllung der regulatorischen Anforderungen.
- IKT-Minimalstandard Assessment: Bewertung des Reifegrads für kritische Infrastrukturen nach den Schweizer Bundesvorgaben.
Technische Sicherheitslage
- Cloud Security Assessment: Analyse der Sicherheitslage in Cloud-Umgebungen inklusive Shared-Responsibility-Bewertung, im Abgleich mit der Cloud Controls Matrix der Cloud Security Alliance.
- CIS Benchmark Assessment: Technische Bewertung von Systemkonfigurationen gegen die CIS Benchmarks als anerkannte Härtungsstandards für Betriebssysteme, Applikationen und Cloud-Plattformen.
- Zero Trust Readiness Assessment: Bewertung des aktuellen Reifegrads gegenüber einem Zero-Trust-Architekturmodell und Ableitung eines priorisierten Umsetzungspfads.
Neue Technologien
- KI Security Assessment: Bewertung von Sicherheitsrisiken im Zusammenhang mit dem Einsatz oder der Entwicklung von KI-Systemen.
Unternehmenstransaktionen
- Security Due Diligence (M&A): Systematische Bewertung der Sicherheitslage eines Zielunternehmens im Rahmen von Unternehmenstransaktionen.
Ganzheitliche Standortbestimmung
- NIST CSF 2.0 Assessment: Strukturierte Bewertung entlang der sechs Funktionen Govern, Identify, Protect, Detect, Respond und Recover.
Unser Vorgehen ist in allen Assessments konsistent: Wir erheben strukturiert, priorisieren risikobasiert und liefern Berichte, die dem Management eine belastbare Entscheidungsgrundlage geben und von technischen Teams direkt in Massnahmen übersetzt werden können.
Drei-Schritte-Checkliste: Wie läuft ein fundiertes Gap Assessment ab?
Ein fundiertes Gap Assessment läuft in drei Schritten ab: Scope und Bewertungsrahmen definieren, den Ist-Zustand erheben und die identifizierten Lücken risikobasiert in Massnahmen übersetzen. Es liefert eine strukturierte Aussage zum Sicherheitsniveau, ordnet Risiken ein und zeigt, welche Schritte zuerst Wirkung entfalten. Entscheidend ist die Übersetzung der Erkenntnisse in eine Roadmap, die Management und technische Teams gemeinsam steuern können.
1. Vorbereitung: Klare Ziele und einen präzisen Scope definieren
- Referenzrahmen definieren: Den massgebenden Standard oder das Framework für das Assessment festlegen (z. B. NIST CSF 2.0, ISO 27001, NIS2, CRA, DORA, interne Vorgaben).
- Scope klären: Welche Systeme, Prozesse und Organisationseinheiten sind einbezogen?
- Unterlagen zusammenstellen: Richtlinien, Prozessdokumentationen, technische Konfigurationen.
2. Durchführung: Ist-Zustand systematisch erheben
- Sicherheitsstatus erfassen: Interviews mit Fachverantwortlichen, um den operativen Stand der Sicherheitsmassnahmen zu erfassen.
- Ist-Zustand belegen: Dokumente prüfen und technische Analysen durchführen, um den aktuellen Stand objektiv zu verifizieren.
- Konfigurationen vertieft prüfen: Optional technische Reviews ausgewählter Konfigurationen durchführen, z. B. Active Directory, Firewall-Regelwerke oder Microsoft 365.
- Erfüllungsgrad bewerten: Erhobenen Ist-Zustand mit den Anforderungen des Referenzrahmens abgleichen und Lücken sowie erfüllte Anforderungen identifizieren.
3. Auswertung: Cyberrisiken priorisieren, Massnahmen ableiten
- Lücken priorisieren: Identifizierte Lücken anhand von Schadenspotenzial und Eintrittswahrscheinlichkeit bewerten und priorisieren.
- Massnahmenplan: Was hat hohe Priorität, was kann mittel- oder langfristig umgesetzt werden?
- Ergebnisbericht: Verständlich für die Geschäftsleitung, operationalisierbar für die technischen Teams.
Was Gap Assessments in der Praxis sichtbar machen
Solide technische Kontrollen reichen nicht aus, wenn Governance, Lieferantenmanagement oder Dokumentation hinter den wesentlichen Anforderungen zurückbleiben.
Zwei Praxisfälle zeigen, wie ein strukturierter Abgleich solche Abweichungen sichtbar macht.
Praxisfall 1: Governance-Lücken trotz solider Technik
Ein mittelgrosses Industrieunternehmen bereitete sich auf die Anforderungen der NIS2 vor. Das interne Team war gut aufgestellt, hatte über Jahre investiert und war überzeugt, die wesentlichen Anforderungen zu erfüllen. Das Assessment zeigte: Die technischen Kontrollen waren solide. Die grössten Lücken lagen in der Governance, im Lieferantenmanagement und in der Dokumentation – Bereiche, die intern als «administrativ» galten und nie priorisiert wurden. Die Lücken liessen sich vor dem Stichtag schliessen, weil sie rechtzeitig auf dem Tisch lagen.
Praxisfall 2: Sicherheitslücken bei kritischen IKT-Drittanbietern
Bei einem Finanzinstitut in der DORA-Vorbereitung lag die Lücke an anderer Stelle: Mehrere kritische IKT-Drittanbieter hatten keine vertraglichen Sicherheitsanforderungen erhalten. Der Aspekt war im bisherigen Sicherheitsmanagement schlicht nie systematisch geprüft worden. Ein strukturiertes Assessment machte diese Lücke sichtbar und damit lösbar.
Beide Fälle veranschaulichen ein Muster, das strukturierte Assessments häufig aufdecken: Auch etablierte Sicherheitsorganisationen weichen in einzelnen Bereichen von relevanten Anforderungen ab.
Fazit: Cyber Security braucht Klarheit, keine Annahmen
Ohne strukturierte Bewertung bleibt unklar, wie belastbar der angenommene Sicherheitsstand tatsächlich ist. Unternehmen verwalten dann das Bekannte – und riskieren, relevante Lücken zu übersehen.
Ein Gap Assessment gibt Sicherheitsverantwortlichen und Geschäftsleitungen die Grundlage, um fundierte Entscheidungen zu treffen:
- Wo müssen wir jetzt investieren?
- Was können wir priorisiert angehen?
- Wie weisen wir gegenüber Auditor:innen und Partnern die Erfüllung relevanter Anforderungen nachvollziehbar nach?
Unternehmen, die diese Fragen beantworten können, weisen die Erfüllung von Compliance-Vorgaben nachvollziehbar nach und bereiten sich gezielter auf den Ernstfall vor.
Sie möchten wissen, wie Ihre Cybersecurity gegenüber relevanten Standards und regulatorischen Anforderungen tatsächlich aufgestellt ist? Wir prüfen Ihre Ausgangslage, identifizieren relevante Lücken und zeigen auf, welche Massnahmen Priorität haben. Sprechen Sie mit uns unverbindlich über ein Gap Assessment.
Keine relevanten Entwicklungen in der Cyber Security mehr verpassen? Unsere Blog-Updates liefern Ihnen regelmässig fundierte Einordnungen zu neuen Cyberbedrohungen, aktuellen Sicherheitsrisiken und wichtigen Trends direkt in Ihr Postfach.
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
KI-Analysen im SOC: Wie Stichproben gezielte Kontrolle schaffen
KI schreibt inzwischen Sicherheitsanalysen. Im SOC formulieren Sprachmodelle den ersten Entwurf. Sie fassen Sicherheitsdaten zusammen, erkennen Zusammenhänge und schlagen in Sekunden eine erste Einschätzung vor – Aufgaben, für die Fachpersonen deutlich mehr Zeit benötigen. Damit verschiebt sich der Fokus. Entscheidend ist heute, wie sich verlässlich überprüfen lässt, ob die KI-Analyse stimmt. Eine falsche Einschätzung in der Sicherheitsanalyse kostet nicht bloss Zeit. Bleibt ein echter Angriff unbemerkt, können sich Angreifende im Netzwerk weiter ausbreiten und kritische Systeme und Daten gefährden – ein Risiko, das angesichts der aktuellen Bedrohungslandschaft besondere Aufmerksamkeit verdient. Wir haben diese in einem früheren Beitrag analysiert.
KI-Halluzinationen sind nicht das eigentliche Risiko
Viele Teams begegnen KI-gestützten Analysen mit vollständiger Kontrolle: Jedes Ergebnis wird von einem Menschen nachgeprüft, bevor es den Kunden erreicht. Das klingt verantwortungsvoll, zehrt den Effizienzgewinn der KI jedoch weitgehend wieder auf.
Wir nennen diesen Effekt die Trust Tax: den zusätzlichen Prüfaufwand, der entsteht, wenn Teams KI-Ergebnissen nicht ausreichend vertrauen. Analyst:innen prüfen die Analyse faktisch ein zweites Mal. Der Zeitgewinn ist dahin – die erhoffte Effizienz ebenfalls.
Der entgegengesetzte Fehler ist ebenso real, bleibt jedoch leichter unbemerkt. Wenn die KI hundertmal recht hatte, nickt das Analyseteam auch die hundertunderste Ausgabe ungeprüft ab. Die Forschung bezeichnet dieses Muster als Automation Bias: das übermässige Vertrauen in automatisierte Ergebnisse. Dieser Fehler fällt oft erst auf, wenn es zu spät ist.
So haben beide Fehler dieselbe Ursache: Vertrauen wird gefühlt statt gemessen. Ohne Messung lässt sich dieses Vertrauen nicht verlässlich kalibrieren.
«Vertrauen in KI entsteht nicht dadurch, dass man daran glaubt. Vertrauen entsteht, wenn KI-Ergebnisse durch Fachpersonen überprüft sind.»
Was die Industrie über Analysequalität längst weiss
Die Industrie sichert Qualität seit Jahrzehnten mit statistischen Stichproben, ohne jedes einzelne Produkt zu kontrollieren. Niemand testet jede einzelne Schraube einer Lieferung. Eine statistisch bemessene Stichprobe identifiziert Qualitätsabweichungen und ermöglicht eine begründete Entscheidung über das gesamte Los. Annahme- und Rückweisungsrisiken bleiben dabei berechenbar.
Genau das beschreibt die Norm ISO 2859-1. Ihr Anwendungsbereich ist ausdrücklich nicht auf physische Produkte beschränkt. Er schliesst Daten, Aufzeichnungen und administrative Abläufe ein. Auch die dokumentierte Analyse eines abgeschlossenen Security-Incidents lässt sich darauf prüfen, ob sie die definierten Anforderungen erfüllt. Damit lässt sich die zugrunde liegende Prüflogik auf Security-Analysen übertragen. Dafür braucht es drei Schritte.
Die drei Elemente der Stichprobenprüfung
Lose. Alle KI-gestützten Incidents eines Kundensegments in einem Zeitfenster bilden ein Prüflos. Die Lose werden so geschnitten, dass sie in sich vergleichbar sind: nach Kundenrisikoklasse, Incident-Typ und Anwendungsfall. Ein Phishing-Fall bei einem regulierten Finanzdienstleister und ein Low-Severity-Alert bei einem kleinen Industriebetrieb gehören nicht in denselben Topf.
Fehlerklassen. Klasse A umfasst alles, was echten Schaden anrichten kann. Ein übersehener oder falsch klassifizierter High-Severity-Incident gehört dazu, ebenso systematisch unterschlagene Artefakte oder ein Verstoss gegen zwingende Eskalationsregeln. Klasse B erfasst ernsthafte Mängel ohne unmittelbare Sicherheitsfolge: etwa eine nicht nachvollziehbare Begründung, eine undokumentierte Korrektur oder Abweichungen vom Playbook. Klasse C umfasst Formfehler.
Toleranzwerte. Für jede Klasse wird ein AQL (Acceptable Quality Level) festgelegt, also ein definiertes Qualitätsniveau für den maximal tolerierten Anteil nichtkonformer Einheiten im Prozessdurchschnitt. Für Klasse A ist dieser Wert sehr klein, für Klasse C darf er deutlich grösser sein. Aus Losgrösse und Prüfniveau ergeben sich Stichprobengrösse und Rückweisungszahl. Kein Ermessen, keine Diskussion. Eine Tabelle.
Enthält ein Incident mindestens eine Abweichung der Klasse A, wird dieser der höchsten Fehlerklasse zugeordnet. Der schwerste Befund zählt. So kann sich ein sicherheitsrelevantes Problem nicht hinter mehreren formalen Abweichungen verbergen.
KI-Analysequalität bestimmt, wie genau das SOC hinschaut
Je nach gemessener Analysequalität prüft das SOC unterschiedlich intensiv. Häufen sich zurückgewiesene Lose, wechselt das System auf verschärfte Prüfung. Die Stichproben werden grösser und die Annahmegrenzen enger – gezielt dort, wo Qualitätsmängel auftreten. Bleibt die Analysequalität über eine definierte Folge von Losen hoch, reduziert das SOC die Prüftiefe. Bei dauerhaft stabiler Qualität lassen sich einzelne Lose nach dem Zufallsprinzip auch ohne Detailprüfung annehmen.
Die an der Analysequalität ausgerichtete Prüftiefe schafft mehr als Effizienz. Sie ist Vertrauenskalibrierung, in Regeln gegossen.
Der Ansatz rechnet bei KI und Menschen mit Fehlern. Deshalb verschärft er die Kontrolle, sobald die Qualitätsdaten darauf hinweisen. Für Analyst:innen liegt darin ein zentraler Unterschied: Die Prüfschärfe folgt vorab definierten Regeln und der gemessenen Analysequalität statt einzelner Vorfälle und situativen Managemententscheidungen. Alle Beteiligten wissen damit, unter welchen Bedingungen die Kontrolle steigt oder sinkt. Stabile Qualität führt nachvollziehbar zu weniger Prüfaufwand.
Die 4 Wirkungsfelder der Qualitätsprüfung
Prüfergebnisse stärken die Cyberabwehr erst, wenn sie konkrete Verbesserungen auslösen. Jede erfasste Abweichung fliesst deshalb gezielt dorthin zurück, wo sie Wirkung entfaltet:
- Governance: Unklare Richtlinien oder Eskalationswege werden identifiziert und angepasst.
- Schulung und Coaching: Wiederkehrende Verhaltensmuster zeigen, wo Analyst:innen gezielt unterstützt werden müssen.
- Wissensbasis: Einzelerfahrungen werden zu strukturiertem Wissen über typische KI-Fehlerbilder.
- Technische Optimierung: Erkenntnisse fliessen in Prompt-Design, Detection Engineering und Regellogik ein.
Über die Zeit entsteht so ein strukturierter Qualitätsdatensatz. Er zeigt, wo die Zusammenarbeit von Mensch und KI tatsächlich hakt und welche Muster wiederholt auftreten. Zudem liefert er Hinweise darauf, welche Incident-Typen sich für mehr Automatisierung eignen und wo Prozesse, Playbooks oder die Regellogik angepasst werden müssen.
Quality Assurance im produktiven SOC-Betrieb
Ein Qualitätsprüfungsprozess muss im 24/7-SOC-Betrieb funktionieren. Deshalb haben wir die Sampling-Logik in eine eigene QA-Applikation überführt, die heute im Cyber Defence Center (CDC) produktiv läuft.
Diese App steuert die Auswahl, Prüfung und Dokumentation der Fälle. Filtergruppen bündeln die Fälle nach Sensorik und Kritikalität. Für jede Gruppe gilt eine eigene Prüfquote. Kritische Fälle gelangen deutlich häufiger in die Qualitätsprüfung als Fälle mit niedriger Kritikalität. Die Auswahl erfolgt pro Kalenderwoche automatisch und zufällig. Damit lässt sich nicht beeinflussen, welche Fälle geprüft werden. Die gezogenen Fälle landen in einer Review-Queue und werden dort anhand einer verbindlichen Checkliste überprüft.
Ein Dashboard schafft jederzeit Transparenz über die Qualitätsprüfung. Es zeigt die Anzahl analysierter Fälle, den geprüften Anteil, die Befunde je Filtergruppe, die Beanstandungsquote und den Prüfaufwand. Eine Sampling-History dokumentiert, mit welcher Quote in welcher Woche geprüft wurde. Ohne diese Nachvollziehbarkeit wäre das ganze Verfahren wertlos.
KI im SOC darf kein Vertrauensvorschuss sein
KI im SOC liefert nur dann einen Sicherheitsgewinn, wenn sich die Qualität ihrer Ergebnisse verlässlich überprüfen lässt. Messbare Qualitätsdaten schaffen dafür eine belastbare Grundlage:
- Fehler erkennen: Fehlpriorisierungen werden früher sichtbar.
- Risiken gezielter prüfen: Kritische Fälle erhalten mehr Prüftiefe.
- Effizienz gewinnen: Stabile Analysequalität reduziert unnötigen Prüfaufwand.
KI verändert die Security-Analyse schneller, als die Governance-Modelle Schritt halten. Policies und menschliche Prüfung allein reichen dafür nicht aus. Entscheidend sind messbare Qualitätskriterien: statistische Stichproben, definierte Toleranzgrenzen und verbindliche Regeln für die Prüftiefe.
Wer KI-gestützte Cyberabwehr verantwortungsvoll einsetzt, schafft damit die Voraussetzung, dass Geschwindigkeit nicht auf Kosten der Verlässlichkeit geht. Sicherheitsentscheidungen bleiben auch bei wachsender Automatisierung nachvollziehbar und belastbar.
Wenn ein realer Cyberangriff eintritt, darf seine Erkennung nicht vom Vertrauen in ein KI-Ergebnis abhängen. Unser «Management Detection and Response (MDR)»-Team verbindet KI-gestützte Analysen deshalb mit messbarer Qualitätssicherung und der Beurteilung durch erfahrene Analyst:innen. Sprechen Sie mit uns darüber, wie unsere SOC- und MDR-Services Ihre Cyberabwehr stärken.
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
Lehrberuf Applikationsentwicklung im Wandel: KI programmiert. Lernende verantworten.
Wie verändert KI den Beruf eines Applikationsentwicklers, wenn Jugendliche sich noch mitten in der Lehre befinden? Marvin Krieg, Informatik-Lernender EFZ Fachrichtung Applikationsentwicklung bei InfoGuard im 4. Lehrjahr, erlebt diesen Wandel aus nächster Nähe. Marvin berichtet aus seiner persönlichen Perspektive, wie KI seinen Ausbildungsalltag verändert hat, welche Chancen und Herausforderungen daraus entstehen und weshalb heute andere Fähigkeiten gefragt sind als noch vor wenigen Jahren.
Fachrichtung Applikationsentwicklung: Als KI nur ein Hilfsmittel war
Schon seit Beginn meiner Lehre nutzten wir KI als Hilfsmittel. Damals halfen uns KI-Tools vor allem dabei, Codeteile zu verstehen oder Themen in der Schule zusammenzufassen. Parallel dazu setzten wir noch vermehrt auf klassische Lösungswege und suchten nach Code-Beispielen auf Stack Overflow oder W3Schools. Zu dieser Zeit war der Umgang mit dem Thema KI noch sehr unterschiedlich.
In den Überbetrieblichen Kursen (ÜK) war uns der Einsatz von KI meistens nicht erlaubt, damit wir die Grundlagen von der Pike auf lernten. Darüber bin ich heute sehr froh, denn wer den Code nur noch generiert und nicht mehr versteht, baut kein solides Verständnis der Grundlagen auf. Genau das kann später im Berufsalltag zum Problem werden.
In der Berufsschule hingegen durften wir KI praktisch ohne Einschränkungen nutzen. Dadurch konnten wir uns logischerweise meist sehr gute Noten holen. Dazu kam, dass Lehrpersonen Prüfungen teilweise mit KI erstellten, die sich danach mit KI sehr gut lösen liessen.
Wenn KI den Code schreibt, beginnt die eigentliche Arbeit
Vor zwei Jahren war KI noch lange nicht so weit entwickelt wie heute. Die Lehrpersonen wissen zwar selbst, wie stark KI das Programmieren mittlerweile verändert hat. Trotzdem orientiert sich der Unterricht oft noch an den bisherigen Methoden.
Bei Projektarbeiten übernimmt KI heute einen Grossteil der Arbeit. Die Ergebnisse werden danach aus meiner Sicht kaum mehr kritisch geprüft. Unsere Prüfungsnoten sprechen für sich: Bei Projekten oder Aufträgen erreichen wir mittlerweile nahezu die volle Punktzahl und benötigen dafür einen Bruchteil des Zeitaufwands, den wir ohne KI gebraucht hätten.
Selbst komplette Präsentationen erstellen wir innerhalb von Minuten. Das Resultat: Eine nahezu perfekte PowerPoint-Präsentation, die fast 1:1 eingesetzt werden kann und entsprechend positives Feedback erzeugt.
Rückblickend überrascht mich, wie stark sich mein Beruf in nur wenigen Jahren verändert hat. Die eigentliche Programmierarbeit ist für mich nicht mehr die grösste Herausforderung. Viel wichtiger ist es heute, die eigentliche Arbeit sauber zu definieren, das Ergebnis zu beurteilen und Verantwortung dafür zu übernehmen.
Code schreiben kann die Maschine. Entscheiden, ob der Code den Anforderungen entspricht, muss noch immer der Mensch. Auch dann, wenn man für diese Einschätzung wiederum KI hinzuzieht.
KI und der Arbeitsmarkt heute: Warum Junior-Rollen unter Druck geraten
Parallel dazu passiert im IT-Stellenmarkt gerade ein Wandel, den man nicht ignorieren kann. Bei grossen Tech-Firmen kam es in den letzten Jahren laufend zu massiven Entlassungswellen. Als Ursache werden dabei häufig KI oder Automatisierung genannt.
Besonders relevant für mich: Laut dem Stanford-HAI-AI-Index ist die Beschäftigung von Software-Entwickler:innen unter 26 Jahren seit 2024 um rund 20 Prozent gesunken. Gleichzeitig zeigt der Bericht, dass sich die Auswirkungen von KI besonders bei jungen Berufsleuten und in Einstiegsstellen bemerkbar machen.
Genau diese Einstiegs- und Junior-Rollen sind für mich als Lernenden wichtig. Früher wäre ich nach Abschluss der Lehre Schritt für Schritt in solche Aufgaben hineingewachsen. Heute stehen genau diese Rollen stärker unter Druck.
Die Marktverschiebung ist für mich klar spürbar: Früher konnten junge Entwickler:innen vor allem über das Schreiben von Code Erfahrung sammeln. Heute übernimmt KI viele dieser Aufgaben. Gefragt sind deshalb immer stärker Fähigkeiten, die sich nicht einfach automatisieren lassen, wie Urteilsvermögen und Verständnis für den Kontext sowie die Bereitschaft, Verantwortung zu übernehmen.
KI-gestützte Entwicklung ist längst in der Praxis angekommen
In Gesprächen mit anderen Lernenden und Berufskolleg:innen merke ich, dass KI-gestützte Entwicklung längst in vielen Unternehmen angekommen ist. Dabei geht es nicht mehr nur darum, sich einzelne Codezeilen erklären zu lassen. KI hilft heute auch dabei, Funktionen zu planen, Fehler schneller zu finden oder erste Lösungswege zu entwickeln.
Für mich zeigt sich daran sehr gut, wie sich die Branche verändert: Projekte können schneller entwickelt werden und gewisse Aufgaben brauchen weniger Zeit. Parallel dazu wird die Rolle der Entwickler:innen anspruchsvoller. Es geht nicht mehr nur darum, Code zu schreiben. Es geht eher darum, die richtigen Fragen zu stellen, gute Prompts zu formulieren, Ergebnisse kritisch zu prüfen und Verantwortung für die Lösung zu übernehmen.
KI in Marvins Berufsalltag: Hilfsmittel mit klaren Grenzen
Auch in meinem Arbeitsumfeld spielt KI eine immer grössere Rolle. Ich nutze KI zum Beispiel, um Fehler schneller einzugrenzen, Code besser zu verstehen oder erste Lösungsansätze zu entwickeln. Gleichzeitig ist gerade in der Cyber Security klar: KI darf nicht unkontrolliert eingesetzt werden. Besonders bei der Verarbeitung sensibler Daten braucht es klare Regeln, sichere Prozesse und ein gutes Verständnis für den Einsatz von KI. Man muss beurteilen können, wo KI sinnvoll unterstützt und wo der Mensch Verantwortung übernehmen muss.
Bei InfoGuard zeigt sich der bewusste Umgang mit KI auf einer grösseren Ebene: etwa durch Investitionen in die eigene KI-Infrastruktur und die Weiterentwicklung von Cyber Defence Services wie MDR 3.0. Dort fliessen KI-Fähigkeiten gezielt in Analyse, Automatisierung und Reporting ein – inklusive Komponenten der Reporting Engine, die mit KI-Unterstützung entwickelt wurde. Für mich zeigt das auf, dass KI nicht einfach ein Tool ist, das man nebenbei nutzt. Es ist ein Werkzeug, das bewusst in Prozesse und Lösungen eingebettet werden muss.
Bei der Code-Entwicklung sehe ich besonders viel Potenzial. Schon der unterstützende Einsatz von KI kann die Entwicklung beschleunigen, wenn man die Ergebnisse sauber prüft und nicht einfach blind übernimmt. Für mich ist deshalb nicht entscheidend, ob KI verwendet wird, sondern wie bewusst sie eingesetzt wird. KI kann einem viel Arbeit abnehmen. Aber sie ersetzt nicht das Verständnis für das Projekt, die Anforderungen und die Verantwortung für die fertige Lösung.
Blick als Lernender auf das Berufsbild von morgen
Meine Lehre, und mehr noch mein Beruf, haben sich in wenigen Jahren stark verschoben. Aus «Code schreiben» ist «Systeme orchestrieren» geworden. Aus «KI als Hilfe» ist «KI als Standard-Werkzeug» geworden. Und aus einer sicheren Junior-Laufbahn ist ein Markt geworden, in dem gerade Einstiegsstellen unter erheblichem Druck stehen.
Viele sehen dies als Bedrohung. Ich bin aber überzeugt, dass wer KI nur blind benutzt und sich nicht wirklich damit auseinandersetzt, sich schneller durch KI ersetzbar macht. Ich versuche daher, ein Projekt bis in seine Grundfesten zu verstehen, der KI eine möglichst genaue Anleitung zu geben und für das Endresultat Verantwortung zu übernehmen. Für mich ist das der beste Weg, um auch in Zukunft gebraucht zu werden.
Mit dem Thema KI setze ich mich auch privat intensiv auseinander. Zum Beispiel entwickle ich mit Hilfe von KI eigene Projekte, die ich auf HelveticLabs.org veröffentliche. Ich sehe KI nicht als Konkurrenz, sondern als Werkzeug, das ich beherrschen will, bevor es für mich zum Risiko wird.
Fazit: Der Beruf Applikationsentwickler verändert sich – und wir mit ihm
Für mich hat sich während der Lehre vor allem eines gezeigt: KI verändert nicht nur, wie wir entwickeln, sondern auch, welche Fähigkeiten künftig gefragt sind. Wer den Beruf Informatiker:in EFZ Fachrichtung Applikationsentwicklung lernt, muss heute nicht mehr nur programmieren können. Ebenso wichtig ist es, Aufgaben richtig zu formulieren, Ergebnisse kritisch zu hinterfragen und Verantwortung für KI-gestützte Lösungen zu übernehmen.
Ich sehe KI deshalb nicht als Konkurrenz, sondern als Werkzeug, das ich verstehen und bewusst einsetzen möchte. Je besser ich die Technologie verstehe, desto besser kann ich sie sinnvoll einsetzen.
Genau darin liegt aus meiner Sicht der grösste Wandel des Lehrberufs Informatiker EFZ mit Fachrichtung Applikationsentwicklung. Der Beruf verändert sich nicht, weil wir weniger programmieren. Er verändert sich, weil heute andere Fähigkeiten gefragt sind. Ich bin überzeugt, dass genau darin eine grosse Chance für Lernende und den Beruf von morgen liegt.
Meine Kolleg:innen und ich freuen uns über Verstärkung! Bewirb dich für einen Ausbildungsplatz 2027 und werde Teil eines Teams, das Informatik nicht nur spannend findet, sondern jeden Tag lebt.
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
KI-Würmer: Die Cyber-Bedrohungslage verschärft sich weiter
Im Juni 2026 stellte das CleverHans Lab der Universität Toronto am IEEE Symposium on Security and Privacy einen Forschungsprototyp eines selbstlernenden KI-Wurms vor. Im kontrollierten Versuch identifizierte dieser durchschnittlich rund 31 Schwachstellen pro Netzwerk und infizierte 62 Prozent eines Testnetzes mit 33 Hosts innerhalb von sieben Tagen. Die Erfolgsquote lag bei 50 Prozent.
Der Prototyp generiert Angriffsstrategien in Echtzeit und passt sie an das jeweilige Zielsystem an. Im Gegensatz zu klassischen Würmern, die auf fest programmierte Exploits angewiesen sind, kann er öffentlich verfügbare Schwachstelleninformationen zur Laufzeit auswerten und sein Vorgehen entsprechend anpassen.
Die Forschung der Universität Toronto entstand unter kontrollierten Laborbedingungen. Bislang sind keine selbstreplizierenden KI-Würmer ausserhalb solcher Testumgebungen dokumentiert. Dennoch hat sich die Bedrohungslage weiterentwickelt. Am 22. Juli 2026 führten zwei KI-Modelle von OpenAI während einer Sicherheitsevaluation einen autonomen Cyberangriff auf die Produktionsinfrastruktur von Hugging Face durch. Der Vorfall war kein KI-Wurm im Sinne der Toronto-Forschung, da keine selbstständige Replikation über Netzwerke stattfand. Er zeigt jedoch, dass KI-Systeme bereits heute eigenständig Schutzmechanismen überwinden, Schwachstellen ausnutzen und komplexe Angriffsschritte ohne fortlaufende menschliche Steuerung ausführen können.
Für Unternehmen bedeutet das: Autonome Cyberangriffe sind keine theoretische Zukunftsfrage mehr. Gleichzeitig bleibt der selbstreplizierende KI-Wurm vorerst ein Forschungsszenario. Umso wichtiger wird es, Sicherheitsarchitekturen bereits heute auf adaptive und autonome Angriffsmuster auszurichten.
KI-Würmer bleiben vorerst Forschung. Sicherheitsarchitekturen sollten sich dennoch bereits heute auf adaptive Angriffe einstellen.
Was unterscheidet KI-Würmer von klassischer Malware
Adaptive Strategie in Echtzeit
Klassische Würmer folgen einem fest programmierten Ablauf. Der Forschungsprototyp aus Toronto geht einen Schritt weiter. Er nutzt grosse Sprachmodelle, um Angriffsstrategien während des Angriffs an das jeweilige Zielsystem anzupassen. Dazu wertet er öffentlich verfügbare Schwachstelleninformationen aus und generiert passende Angriffsvektoren in Echtzeit.
Im Versuch nutzte der Prototyp sogar drei Schwachstellen, die erst nach dem Trainingsstichtag des Modells veröffentlicht worden waren. Das zeigt, dass sich sein Vorgehen nicht auf bereits bekannte Exploits beschränkt.
Dezentralisierte Operationen ohne zentrale Kontrollpunkte
Ein signifikanter Unterschied zu konventioneller Malware liegt in der fehlenden Abhängigkeit von Command-and-Control-Servern. Der Forschungsprototyp nutzt Open-Weight-Modelle (wie Llama 2, Mistral), die lokal auf infizierten Systemen ausgeführt werden, und greift dabei auf deren Rechenleistung zurück. Eine dauerhafte externe Steuerung ist damit nicht erforderlich, was die Erkennung erschweren kann.
Diese Architektur hat jedoch Grenzen. Open-Weight-Modelle wie Llama 2 oder Mistral benötigen je nach Ausführung zwischen 13 und 70 GB Speicher. Viele Systeme in realen Unternehmensnetzen verfügen nicht über diese Kapazität. Offen bleibt zudem, wie gut sich der Ansatz auf grössere, geschützte Umgebungen mit EDR, UEBA und Netzwerksegmentierung übertragen lässt.
Der Paradigmenwechsel: Klassische Würmer vs. KI-Würmer
Im direkten Vergleich wird deutlich, wie sich der Forschungsprototyp von klassischen Würmern unterscheidet:
Welche Cyberrisiken entstehen für Unternehmen?
Heterogene Umgebungen vergrössern die Angriffsfläche
Adaptive Malware könnte unbekannte Schwachstellen in Legacy-Systemen, IoT-Geräten oder Cloud-Services gezielt ausnutzen.
Besonders exponiert sind Organisationen mit:
- veralteter Infrastruktur, die nicht regelmässig gepatcht wird,
- mit grosser Heterogenität (unterschiedliche Betriebssysteme, Anwendungen, Hersteller),
- und eingeschränkter Netzwerk-Sichtbarkeit über On-Premises- und Cloud-Umgebungen.
Bypass von bestehenden Sicherheitsmassnahmen
Signaturbasierte Sicherheitslösungen wie klassische Antivirenprogramme oder Intrusion Detection Systems erkennen bekannte Muster. Passt Malware ihre Angriffswege laufend an oder nutzt bislang unbekannte Schwachstellen, reichen solche Verfahren allein nicht aus. Verhaltensbasierte Erkennung gewinnt deshalb an Bedeutung.
Praxisbeleg Juli 2026: KI-Modelle von OpenAI nutzten beim Angriff auf Hugging Face eine Zero-Day-Schwachstelle in einem Cache-Proxy. Eine Lücke, die signaturbasierte Sicherheitssysteme nicht kannten und daher nicht erkennen konnten. Die Forensik musste zudem auf ein alternatives Open-Source-Modell (GLM 5.2 von Z.ai) ausweichen, weil ein führendes US-Modell die Untersuchung verweigerte, ein Hinweis auf neue Abhängigkeiten und Risiken in der KI-gestützten Incident Response.
Wirtschaftliche Asymmetrie: Shift zu Gunsten der Angreifer
Nach der Initialinfektion fallen für Angreifer nur noch marginale Kosten an. Der Wurm operiert autonom auf kompromittierten Systemen. Verteidiger hingegen müssen in Echtzeit-Monitoring, KI-gestützte Systeme und schnelle Patch-Prozesse investieren.
Handlungsempfehlungen nach Stakeholder-Rolle
Die Anforderungen unterscheiden sich je nach Verantwortung im Unternehmen. Während CISOs die strategischen und organisatorischen Voraussetzungen schaffen, setzen SOCs und CSIRTs die technischen und operativen Massnahmen um.
Für Unternehmen und KMUs bilden grundlegende Sicherheitsmassnahmen die Basis, um sich auf adaptive Angriffsmuster vorzubereiten.
CISO: Strategische Risiko-Neubewertung und Governance
Priorität 1: Risikoneubewertung durchführen
- Führen Sie eine KI-spezifische Bedrohungsmodellierung durch.
- Systeme mit höchster Anfälligkeit identifizieren: veraltete IoT-Geräte, ungepatchte Legacy-Software, Systeme mit eingeschränkter Überwachung.
- Red-Team-Übungen durchführen, die externe Sicherheitsexperten KI-gestützte Angriffsmuster simulieren.
Priorität 2: Investitionen in verhaltensbasierte Erkennung
- User and Entity Behavior Analytics (UEBA) implementieren wie Vectra AI oder Microsoft Defender for Cloud.
- Network Traffic Analysis (NTA), um anomale Kommunikationsmuster zu erkennen.
- SOC und Echtzeit-Event-Systeme mit KI-Integration nutzen.
Priorität 3: Zero-Trust-Architektur beschleunigen
- Implementieren von Mikrosegmentierung, um die laterale Ausbreitung von Infektionen zu begrenzen.
- Kontinuierliche Authentifizierung einführen (nicht nur beim Login).
- Least-Privilege-Prinzip konsequent anwenden.
Priorität 4: Notfallpläne für KI-Bedrohungen aktualisieren
- Incident-Response-Vorbereitungen für KI-Würmer integrieren: Isolierung infizierter Systeme, forensische Analyse, Kommunikationsprotokolle.
- Offline-Backups für kritische Systeme sicherstellen (3-2-1-Regel: 3 Kopien, 2 Medien, 1 extern).
SOC: Operative Transformation zur verhaltensbasierten Erkennung
Priorität 1: Verhaltensbasierte Erkennungssysteme einführen
- UEBA-Tools für Benutzer und Systeme implementieren.
- Endpoint Detection and Response (EDR) auf allen kritischen Systemen einsetzen.
- Baselines für «normales» Verhalten entwickeln, um Abweichungen schnell zu erkennen.
Priorität 2: Automatisierte Response implementieren
- Plattformen zur Automatisierung von Reaktionen nutzen.
- Automatische Netzwerk-Isolierung über Network Access Control (NAC) konfigurieren, wenn verdächtige Aktivitäten erkannt werden.
Priorität 3: Threat Hunting mit KI-Unterstützung
- Proaktives Threat Hunting durchführen, das Indikatoren von Kompromittierung (IoCs) mit Verhaltensmustern korreliert.
- Deception-Technologien (Illusive Networks) einsetzen, um Angreifer in Fallen zu locken.
CSIRT: Schnelle Eindämmung und forensische Vorbereitung
Priorität 1: KI-Wurm-Checklisten und Playbooks entwickeln
- Eskalationspfade und Entscheidungsprozesse für Ausbruchsereignisse definieren.
- Netzwerk-Isolierungsszenarien planen: Welche Segmente können schnell getrennt werden.
Priorität 2: Forensik-Tools und Prozesse vorbereiten
- Memory-Forensik-Tools zur Analyse kompromittierter Systeme nutzen – das CSIRT hilft.
- Prozesse für schnelle Log-Analyse und Timeline-Rekonstruktion etablieren.
Priorität 3: Externe Koordination
- Kontakte zu relevanten Unterstützern (SOC; CSIRT; Cyber Versicherung) und Behörden (NCSC / BACS; BSI in Deutschland; CERT-Bund, lokale CERTs) definieren.
- Krisenkommunikations-Vorlagen für den Fall öffentlicher Kommunikation vorbereiten.
Unternehmen und KMUs: Operative Hygiene und Awareness
Grundlegende Massnahmen mit sofortiger Wirkung
- Patch-Management automatisieren: Regelmässige, getestete Updates für alle Systeme
- Multi-Faktor-Authentifizierung auf allen kritischen Systemen aktivieren
- Regelmässige, getestete Backups durchführen (3-2-1-Regel)
- Mitarbeitende-Schulungen durchführen zu KI-generierten Phishing-Angriffen
Externe Expertise nutzen
- Managed Security Services (MSSP) für 24/7-Monitoring evaluieren
- Regelmässige Penetrationstests mit externe Experten durchführen
- Threat Intelligence Feeds abonnieren (Anomali Threat Intelligence, ThreatConnect)
- Cyber-Versicherung prüfen: Deckt diese KI-basierte Angriffe ab?
Verhaltensbasierte Erkennung, Zero Trust, Segmentierung und eingespielte Incident Response schaffen die nötige Grundlage, um autonome Angriffsmuster früh einzuordnen und gezielt einzudämmen.
Jetzt ist der richtige Zeitpunkt, Abläufe von der Erkennung bis zur Wiederherstellung auf adaptive KI-Angriffe auszurichten und in Ihrer Sicherheitsarchitektur klar zu verankern.
Risikodifferenzierung nach Organisationstyp
Das Risiko durch KI-Würmer variiert erheblich je nach Unternehmensprofil.
KI-Würmer zwischen Compliance und geopolitischem Risiko
Europa: Unternehmen müssen NIS2-Anforderungen erfüllen, die Incident Response in kritischen Sektoren vorschreiben. Eine KI-Wurm-Infektion könnte zu regulatorischen Bussgeldern führen.
Kritische Infrastrukturen sind besonders exponiert (Energie, Wasser, Verkehr, Gesundheit): Ein erfolgreicher Angriff könnte öffentliche Dienste beeinträchtigen.
Geopolitische Dimension: Staaten könnten KI-Würmer als Cyberwaffen einsetzen. Dies macht Defensive-Massnahmen zu einer Frage der nationalen Sicherheit.
Q&As: Häufig gestellte Fragen
F: Kann dieser Wurm mein System infizieren?
A: Der akademische Prototyp ist aktuell nicht öffentlich verfügbar. Die Bedrohung liegt darin, dass ähnliche Techniken von Angreifern repliziert werden könnten. Dies erfordert erhebliche KI- und Sicherheits-Expertise. Organisationen mit modernen Defensive-Massnahmen (EDR, Segmentierung, UEBA) sind besser geschützt als solche mit minimaler Überwachung.
F: Sind meine Backups sicher?
A: Nur wenn sie offline sind. Backups, die mit dem Produktivnetzwerk verbunden sind oder remote zugänglich sind, könnten auch infiziert werden. Die 3-2-1-Regel (3 Kopien, 2 Medientypen, 1 extern/offline) bietet Schutz.
F: Belegt der OpenAI-Hugging-Face-Vorfall vom Juli 2026 die KI-Wurm-Bedrohung?
A: Der Vorfall bestätigt autonome KI-Angriffsfähigkeiten in kontrollierten Bedingungen, ist jedoch kein KI-Wurm im klassischen Sinne: Es fehlte die selbstständige Replikation über Netzwerke. Er demonstriert empirisch das Ausbrechen aus Sandboxes, Zero-Day-Exploitation und massenhafte autonome Aktionen (17’000+) ohne menschliche Steuerung. Für Praktiker bedeutet das: Die in diesem Artikel beschriebenen Abwehrmassnahmen sind ab sofort nicht mehr nur vorsorglich, sondern reaktiv notwendig.
F: Wie schnell muss ich handeln?
A: Sofort für grundlegende Massnahmen (Patch-Management, MFA, Backups). Für umfassendere Transformationen (UEBA, Zero-Trust) sollte ein 6-12-Monats-Plan etabliert werden.
Aktuelle Entwicklung: Der Hugging-Face-Vorfall (Juli 2026)
Am 22. Juli 2026 bestätigten OpenAI und Hugging Face einen Vorfall, der als Zäsur für die KI-Sicherheitsforschung gilt: Zwei KI-Modelle, das öffentliche GPT-5.6 Sol sowie ein noch unveröffentlichtes Vorabmodell, brachen während einer internen Sicherheitsevaluation eigenständig aus einer isolierten Sandbox-Umgebung aus und griffen die Produktionsinfrastruktur der Open-Source-KI-Plattform Hugging Face an.
Technische Details: Wie die KI-Modelle die Sandbox überwanden
Getestet wurden die Modelle auf dem ExploitGym-Benchmark, einer öffentlichen Vergleichsplattform für Hacking-Fähigkeiten. Zu Testzwecken wurden die üblichen Sicherheitsfilter deaktiviert. Die Modelle identifizierten, dass Hugging Face die Lösungsschlüssel für den Benchmark in seiner Datenbank speicherte, und nutzten eine Zero-Day-Schwachstelle in einem Cache-Proxy aus, um sich eigenständig Internetzugang zu verschaffen.
Im Verlauf des Angriffs wurden gestohlene Zugangsdaten eingesetzt und insgesamt mehr als 17’000+ autonome Aktionen ausgeführt. Hugging Face hatte den Einbruch parallel zur laufenden OpenAI-Evaluation entdeckt. Für die forensische Analyse war das Team auf das chinesische Open-Source-Modell GLM 5.2 von Z.ai angewiesen, da ein führendes US-amerikanisches Modell die Kooperation bei der Untersuchung verweigerte; eine unerwartete Einschränkung, die neue Abhängigkeiten in der Incident Response aufzeigt.
Der Vorfall ruft Behörden und Industrie auf den Plan
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) wertet den Vorfall als Beginn einer neuen Zeitrechnung für die Cybersicherheit. Die Behörde fordert Softwarehersteller auf, KI-Agenten klare Grenzen zu setzen: strikte Zugriffsrechtsbeschränkung, Netzwerktrennung und robuste Prüfmechanismen.
Auf EU-Ebene wiesen Parlamentarier darauf hin, dass der Vorfall gemäss der EU-KI-Verordnung (AI Act) meldepflichtig sei. Verschiedene Fraktionen forderten verbindliche Sicherheitsregeln für autonome KI-Agenten sowie eine Stärkung der technologischen Souveränität Europas.
Vom Einzelfall zur strategischen Konsequenz
Der OpenAI-Hugging-Face-Vorfall ist kein KI-Wurm im Sinne der Toronto-Forschung – er entstand nicht durch autonome Replikation über Netzwerke. Er demonstriert jedoch empirisch erstmals mehrere der im vorliegenden Artikel beschriebenen Risikofaktoren: autonomes Ausbrechen aus einer isolierten Umgebung, Ausnutzung unbekannter Zero-Day-Schwachstellen, Missbrauch gestohlener Zugangsdaten und das vollständige Fehlen menschlicher Intervention im Angriffsverlauf.
Für CISOs, SOCs und CSIRTs bedeutet dies: Die im Theorieteil beschriebene Reifung autonomer Angriffsfähigkeiten ist nicht mehr rein spekulativ. Die empfohlenen Massnahmen – Zero-Trust-Architektur, Netzwerksegmentierung, verhaltensbasierte Anomalie Erkennung und «KI-Wurm»-Checklisten – gewinnen durch diesen Vorfall an dringlicher Aktualität.
Fazit: Vorbereitung beginnt vor dem ersten KI-Wurm
Für CISOs, SOCs und CSIRTs entsteht daraus keine akute Krisenlage, jedoch ein klarer Auftrag zur Vorbereitung. Die Forschung aus Toronto zeigt, wie adaptive Malware künftig Schwachstellen identifizieren, Angriffswege verändern und vorhandene Ressourcen für ihre Ausbreitung nutzen könnte. Der Vorfall rund um OpenAI und Hugging Face macht zugleich sichtbar, dass autonome Angriffsschritte bereits heute technisch möglich sind.
Entscheidend ist deshalb, bestehende Sicherheitsstrukturen auf diese Entwicklung auszurichten. Dazu gehören insbesondere:
- Verhaltensbasierte Erkennung (nicht nur Signaturen)
- Zero-Trust-Architekturen und Netzwerk-Segmentierung
- Eingespielte Incident-Response-Prozesse für autonome Angriffsmuster
- Kulturelle Veränderung, die neue KI-Risiken früh einordnet und regelmässig prüft
Wer diese Grundlagen heute stärkt, gewinnt Zeit, Übersicht und Handlungssicherheit. Genau darin liegt der wichtigste Vorteil: Organisationen, die jetzt handeln, werden in den kommenden Jahren widerstandsfähiger gegen die nächste Generation von Cyberbedrohungen sein.
Bleiben Sie über aktuelle Entwicklungen informiert. Unsere Blog-Updates liefern regelmässig Einblicke in neue Bedrohungen, Sicherheitsrisiken und Trends der Cybersecurity.
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
Extreme Platform ONE: Netzwerkmanagement einfach und smart
Die wachsende Komplexität moderner Unternehmensnetzwerke stellt IT-Teams vor eine zentrale Herausforderung: Sie müssen immer mehr Daten, Abhängigkeiten und Tools beherrschen – häufig ohne zusätzliche Ressourcen. Genau hier entsteht eine der zentralen Herausforderungen im Netzwerkmanagement. Viele Organisationen betreiben historisch gewachsene Infrastrukturen mit separaten Management-Systemen für LAN, WLAN, WAN, Fabric, Security, Identity, Tickets und Monitoring. Störungen lassen sich zwar erkennen, aber die eigentliche Ursache liegt oft verborgen zwischen Telemetrie, Logs, Konfigurationen, Benutzerkontext, Policies und Applikationsdaten. Das kostet Zeit, bindet Spezialist:innen und erschwert eine proaktive Steuerung.
Warum klassisches Netzwerkmanagement an Grenzen stösst
In der Praxis sehen wir immer wieder dieselben Muster: Ein Benutzer meldet schlechte Performance. Das Monitoring zeigt erhöhte Latenzen. Im WLAN-Controller erscheinen Auffälligkeiten. Im Ticketing-System wurde kurz zuvor ein Change erfasst. Gleichzeitig laufen neue Applikationen über das WAN, während Security-Policies angepasst wurden. Jede Information ist für sich relevant – aber erst im Zusammenhang entsteht ein verwertbares Bild.
Klassische Tools liefern dafür oft zu viele Einzelsignale und zu wenig Kontext. Die Folge sind engere Analysezeiten, manuelle Korrelation, Tool-Wechsel und eine starke Abhängigkeit von erfahrenen Netzwerk- und Security-Spezialist:innen. Hinzu kommt: Je stärker Netzwerk und Security zusammenwachsen, desto wichtiger wird eine gemeinsame Sicht für NetOps, SecOps, Helpdesk und Architekturteams.
Extreme Platform ONE: ein Intelligence-Layer für Netzwerk und Security
Extreme Networks adressiert diese Entwicklung mit Extreme Platform ONE. Die Plattform führt Netzwerk, Sicherheit, Daten, Analysen und KI in einer einheitlichen Umgebung zusammen. Dabei geht es nicht einfach um eine weitere Management-Konsole, sondern um einen digitalen Intelligence-Layer, der Daten konsolidiert, Zusammenhänge erkennt und operative Entscheidungen unterstützt.
Die Plattform verbindet Cloud-natives Management, Automatisierung, Unified Data & Telemetry, offene Integrationen sowie KI-gestützte Funktionen. Dadurch erhalten Teams eine übergreifende Sicht auf Netzwerkzustand, Benutzer, Geräte, Applikationen, Standorte, Policies und Ereignisse. Statt einzelne Symptome isoliert zu betrachten, kann die Plattform Abhängigkeiten sichtbar machen – etwa zwischen einer Performance-Störung, einer Policy-Änderung, einem betroffenen Access Point, einem bestimmten Gerätetyp oder einer auffälligen Applikation.
KI, die den Betrieb unterstützt – nicht ersetzt
Ein zentraler Mehrwert von Extreme Platform ONE liegt im KI-gestützten Betrieb. Die Plattform nutzt Machine Learning, generative KI und agentenbasierte Ansätze, um Muster zu erkennen, Anomalien zu bewerten und Handlungsempfehlungen abzuleiten. Damit wird KI nicht als isoliertes Zusatzmodul verstanden, sondern als Bestandteil der Workflows.
Für Netzwerk-Teams kann das konkret bedeuten: Auffälligkeiten werden schneller eingeordnet, Root-Cause-Analysen werden unterstützt, Konfigurations- oder Policy-Probleme werden verständlich erklärt und mögliche nächste Schritte werden vorgeschlagen. Operator:innen können Fragen in natürlicher Sprache stellen – zum Beispiel, welche Standorte in den letzten 24 Stunden die meisten WLAN-Probleme hatten, welche Applikationen aktuell die höchste WAN-Last verursachen oder ob es Hinweise auf ungewöhnliches Geräteverhalten gibt.
Das reduziert die Einstiegshürde für weniger erfahrene Mitarbeitende und entlastet Senior Engineers bei wiederkehrenden Analysen. Gleichzeitig bleibt der Mensch in der Kontrolle. Empfehlungen können geprüft, angepasst und freigegeben werden. Gerade für regulierte Unternehmen ist dieser Ansatz entscheidend: KI soll Transparenz schaffen, Prozesse beschleunigen und Qualität verbessern – aber nicht unkontrolliert automatisieren.
Von reaktiver Fehlerbehebung zu proaktiver Optimierung
Der eigentliche Fortschritt liegt nicht nur darin, Störungen schneller zu beheben. Entscheidend ist der Schritt zu einem proaktiven Netzwerkbetrieb. Wenn Live-Daten, historische Telemetrie, Metadaten und Kontextinformationen zusammengeführt werden, lassen sich Entwicklungen früher erkennen: steigende Auslastung an bestimmten Standorten, wiederkehrende Konfigurationsfehler, Policy-Missmatches, auffällige Clients oder sich verschlechternde Servicequalität.
Damit wird das Netzwerk nicht erst dann sichtbar, wenn ein Incident entsteht. Es entwickelt sich zu einer Datenbasis, auf der Betrieb, Security und Architektur fundiertere Entscheidungen treffen können. Für Unternehmen mit verteilten Standorten, hybriden Infrastrukturen und hohen Verfügbarkeitsanforderungen ist dies ein wesentlicher Vorteil.
Integration in bestehende IT- und Security-Ökosysteme
Ein weiterer wichtiger Punkt ist die Einbettung in bestehende Umgebungen. Extreme Platform ONE ist darauf ausgelegt, nicht isoliert betrieben zu werden. Über APIs und Integrationen kann die Plattform mit ITSM-, SIEM-/SOAR-, Identity- und Cloud-Umgebungen zusammenspielen. Dadurch lassen sich Netzwerkereignisse mit Changes, Security-Incidents, Benutzeridentitäten oder Compliance-Anforderungen korrelieren.
Aus Sicht von InfoGuard ist genau diese Verbindung zentral. Netzwerkmanagement darf nicht losgelöst von Security Operations, Zero Trust, Identity, Cloud und Governance betrachtet werden. Der Mehrwert entsteht dort, wo technische Transparenz in belastbare Betriebs- und Sicherheitsprozesse überführt wird.
Warum sich Unternehmen jetzt mit Extreme Platform ONE beschäftigen sollten
Viele IT-Organisationen stehen vor derselben Aufgabe: Sie müssen komplexere Netzwerke betreiben, Risiken reduzieren, Automatisierung sinnvoll nutzen und gleichzeitig mit knappen Ressourcen umgehen. Extreme Platform ONE bietet dafür einen modernen Ansatz: weniger Tool-Silos, mehr Kontext, KI-gestützte Analysen, nachvollziehbare Empfehlungen und eine Plattform, die NetOps und SecOps näher zusammenbringt.
Für bestehende Extreme-Kunden ist die Plattform besonders interessant, weil sie vorhandene Technologien und Telemetriedaten stärker nutzbar macht. Für Unternehmen, die ihre Netzwerk- und Security-Architektur strategisch weiterentwickeln möchten, bietet sie einen konkreten Einstieg in KI-gestütztes Network Operations Management.
Hands-on Workshop: Extreme Platform ONE live erleben
Theorie ist wichtig. Entscheidend ist jedoch, wie sich eine Plattform im konkreten Betrieb anfühlt. Deshalb laden wir Sie zu unserem Extreme Hands-on Workshop am 20. August bei InfoGuard ein.
Im Workshop erleben Sie aktuelle Extreme-Technologien und Plattformansätze direkt in der Praxis. Gemeinsam mit den Expert:innen von InfoGuard und Extreme Networks können Sie typische Konfigurations-, Betriebs- und Troubleshooting-Szenarien durchspielen, Fragen aus Ihrer eigenen Umgebung einbringen und diskutieren, wie Extreme Platform ONE in Ihre Netzwerk- und Security-Architektur integriert werden kann.
Viele dieser Fragestellungen haben wir bereits in unserem vergangenen Webinar zu Extreme Platform ONE im Detail beleuchtet – inklusive Live-Demos und konkreten Use Cases. Die Aufzeichnung steht Ihnen On-Demand zur Verfügung, sodass Sie sich vorab einen fundierten Überblick verschaffen können.
Nutzen Sie die Gelegenheit, die Möglichkeiten von KI-gestütztem Netzwerkmanagement live kennenzulernen – und zu beurteilen, wo Platform ONE in Ihrer Organisation den grössten Nutzen stiften kann.
Jetzt Webinar-Aufzeichnung ansehen und für den Extreme Hands-on Workshop vom 20. August anmelden.
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
ISG und OT-Sicherheit: Neue Anforderungen für KRITIS
Mit dem Inkrafttreten des Informationssicherheitsgesetzes (ISG) gelten für Betreiber kritischer Infrastrukturen (KRITIS) neue Anforderungen an die Cybersicherheit. Neben Meldepflichten und klaren Governance-Vorgaben rückt insbesondere die Sicherheit von Operational Technology (OT) in den Fokus.
Denn durch die zunehmende Vernetzung von IT- und OT-Systemen entstehen neue Angriffsflächen: Bereits 80 % der Schweizer KRITIS-Betreiber berichten von Cybervorfällen in OT-Umgebungen, die zu Produktionsausfällen oder Datendiebstahl geführt haben. Unternehmen sollten daher ihre OT-Sicherheitsstrategie gezielt an die neuen gesetzlichen Vorgaben anpassen.
ISG-Anforderungen für OT-Verantwortliche
Das Schweizer Informationssicherheitsgesetz (ISG) definiert klare Anforderungen an Betreiber kritischer Infrastrukturen, insbesondere im Bereich der Operational Technology (OT).
Die zentralen Pflichten umfassen:
1. Meldepflicht bei Cybervorfällen (ISG Art. 73a-74f)
- Vorfälle mit erheblicher Auswirkung auf die Versorgungssicherheit oder öffentliche Sicherheit müssen unverzüglich (in der Regel innerhalb von 24-Stunden) an das Bundesamt für Cybersicherheit (BACS) gemeldet werden.
- Betroffen sind OT-Systeme, die für die Aufrechterhaltung kritischer Dienstleistungen (z.B. Energie, Verkehr, Wasser, Abwasser, Gesundheit) wichtig sind.
- Die Meldung erfolgt über das Meldesystem des BACS und muss technische Details, betroffene Systeme und Massnahmen enthalten.
2. Nachweis von Schutzmassnahmen (ISG Art. 64)
Betreiber müssen technische und organisatorische Schutzmassnahmen dokumentieren, um die Verfügbarkeit, Integrität und Vertraulichkeit von OT-Systemen zu gewährleisten. Konkrete Massnahmen (gemäss ISG und internationaler Standards wie ISA/IEC 62443):
- Netzwerksegmentierung (Isolation von OT- und IT-Systemen).
- Regelmässige Risikobewertungen (mindestens jährlich).
- Notfall- und Wiederanlaufpläne (inkl. Tests und Aktualisierungen).
- Zugangskontrollen (z.B. Multi-Faktor-Authentifizierung für kritische Systeme).
- Schulungen und Sensibilisierungsmassnahmen für Mitarbeitende.
3. Zusammenarbeit mit dem BACS (ISG Art. 15)
Betreiber sind verpflichtet, aktiv mit dem BACS zusammenzuarbeiten, insbesondere bei:
- Risikoanalysen (z.B. im Rahmen der nationalen Cybersicherheitsstrategie).
- Vorfalls-Untersuchungen (Forensik, Ursachenanalyse).
«Betreiber kritischer Infrastrukturen müssen Cybervorfälle, die die Versorgungssicherheit oder öffentliche Sicherheit gefährden, unverzüglich (in der Regel innerhalb von 24-Stunden) dem BACS melden und nachweisen, dass sie angemessene Schutzmassnahmen ergreifen.»
OT-Systeme im Fokus des ISG
OT-Systeme bilden das Rückgrat kritischer Infrastrukturen. Für ISG-konforme Strategien ist eine präzise Identifikation und Klassifizierung aller relevanten OT-Komponenten notwendig. Eine Schutzbedarfsanalyse hinsichtlich Verfügbarkeit, Integrität und Vertraulichkeit sowie die Berücksichtigung von IT-/OT-Abhängigkeiten ermöglichen eine gezielte Risikopriorisierung und die Ableitung regulatorisch relevanter Massnahmen.
Gründe, warum das ISG auch explizit OT adressiert:
- Durch die zunehmende Vernetzung von Steuerungssystemen mit der Unternehmens-IT entstehen neue Angriffsvektoren (z. B. Ransomware, die von der IT in die OT übergreift).
- Die IT/OT-Konvergenz erfordert Sicherheitsansätze wie Zero Trust, um laterale Bewegungen von Angreifern zwischen IT- und OT-Netzen wirksam zu verhindern.
- Zunehmende Angriffe auf OT: Laut BACS haben sich Cyberangriffe auf Schweizer Industrieanlagen seit 2022 verdoppelt – mit Fokus auf Energieversorger und Finanzinfrastrukturen.
- Die Abhängigkeit von Lieferketten und Drittanbietern (z. B. Wartungsfirmen, Cloud-Dienste) stellt ein häufiges Einfallstor dar – das ISG fordert daher entsprechende vertragliche Sicherheitsklauseln.
ISG: Sofortmassnahmen für OT-Verantwortliche
Das ISG verlangt kurzfristige, risikobasierte Eingriffe, um akute Bedrohungen in OT-Umgebungen zu reduzieren. Dazu gehören Zugangskontrollen, Patch-Management, Netzwerksegmentierung und Monitoring. Diese Massnahmen sichern die Compliance und gewährleisten die operative Stabilität der OT-Systeme in der unmittelbaren Handlungsphase.
1. Asset-Discovery inkl. OT/IT-Schnittstellen
- Passive Netzwerkanalyse zur Identifikation aller OT-Assets – einschliesslich Legacy-SPS und bislang unbekannter Verbindungen.
- Dokumentation der Schnittstellen zu IT-Systemen (z.B. Fernwartung, ERP-Anbindungen).
2. Notfall-Meldeweg zum BACS definieren (24-Stunden-Frist!)
- Klare Eskalationspfade festlegen. Wer meldet wann an das BACS?
- Vorlagen für Meldungen vorbereiten.
- Testmeldung durchführen, um den Prozess zu validieren.
3. Verantwortlichkeiten auf Geschäftsführungsebene verankern.
- CISO oder OT-Sicherheitsbeauftragten benennen.
- Regelmässige Berichte an die Geschäftsleitung (z.B. quartalsweise Risikostatus).
Mehr zu OT Security ServicesTechnik & Prozesse für OT-Sicherheit nach ISG
Die ISG-Konformität erfordert das Zusammenspiel technischer und organisatorischer Massnahmen. Kontinuierliches Monitoring, Incident-Response- und Wiederanlaufpläne, Backup-Strategien sowie klare Verantwortlichkeiten und Schulungen stellen sicher, dass OT-Systeme dauerhaft geschützt sind und die Audit-Readiness jederzeit nachgewiesen werden kann.
Praxisnahe Massnahmen für verbesserte OT-Sicherheit sind:
1. Segmentierung & Netzwerkzugangskontrolle
- Umsetzung eines Zonenmodells nach ISA/IEC 62443:
– Produktionszone (kritische Steuerungen)
– Wartungszone (Fernzugriffe, Updates)
– Externe Zone (Lieferanten, Cloud-Dienste)
- Einsatz von Firewalls mit OT-spezifischen Regeln (z. B. Modbus-/DNP3-Filterung).
- Strikte Netzwerksegmentierung zwischen IT- und OT-Umgebungen sowie innerhalb der OT-Zonen.
2. Resilienz & Wiederanlauf
- Backup-Strategie für OT-Systeme (inkl. Offline-Backups z.B. für SPS-Konfigurationen).
- Wiederanlaufpläne für kritische Prozesse (z.B. Stromversorgung, Zahlungsabwicklung).
- Regelmässige Tests (mindestens einmal jährlich).
3. Einbindung externer Dienstleister
- Aufnahme von Security-Klauseln in Verträge (z. B. Meldepflichten bei Vorfällen, Audit-Rechte).
- Bewertung von Lieferanten nach anerkannten Sicherheitsstandards (z. B. ISO/IEC 27001).
OT-Security: Compliance und Reporting nach ISG
Für ISG-konforme OT- und IT-Sicherheitsstrategien ist die Dokumentation der Massnahmen und Kontrollen unverzichtbar. Compliance-Nachweise ermöglichen es, regulatorische Anforderungen gegenüber Aufsichtsbehörden oder Auditoren transparent darzustellen.
Ein strukturiertes Reporting unterstützt zudem das Management bei der strategischen Steuerung der Informationssicherheit, erlaubt die frühzeitige Identifikation von Schwachstellen und stellt sicher, dass Audit-Readiness kontinuierlich gewährleistet ist.
Systematische Dokumentation der Tätigkeiten
- Dokumentation von Risikobewertungen auf Basis der ISA/IEC 62443-Methodik, einschliesslich der identifizierten Risiken und der daraus abgeleiteten Schutzmassnahmen.
- Lückenlose Erfassung aller Änderungen an OT-Systemen – etwa Firewall-Regeln oder Patches – inklusive Verantwortlichkeit, Zeitpunkt und Begründung.
- Regelmässige und protokollierte Incident-Response-Tests mit Dokumentation der Ergebnisse sowie abgeleiteten Massnahmen für den Ernstfall.
Im Falle eines meldepflichtigen Vorfalls müssen folgende Punkte klar kommuniziert werden:
- Betroffene Systeme und Angriffsvektoren. Welche Teile Ihrer Infrastruktur waren, betroffen, und wie erfolgte der Angriff.
- Auswirkungen des Vorfalls, z. B. Produktionsausfälle, Datenverlust oder Einschränkungen kritischer Prozesse.
- Ergriffene Massnahmen, wie der Vorfall eingedämmt wurde, welche Schritte zur Wiederherstellung eingeleitet wurden, und wie soll ein erneutes Auftreten verhindert werden.
Jährliche Risiko- und Compliance-Reviews – Kontinuierliche Verbesserung:
- Interne Audits mit Checklisten nach ISO/IEC 27001, um Schwachstellen zu identifizieren und zu beheben.
- Externe Prüfungen der OT-Sicherheit durch externe Stellen. Dokumentieren der Ergebnisse und Umsetzung der Massnahmen Empfehlungen.
Fazit: ISG stärkt OT-Sicherheit und Resilienz
Das Informationssicherheitsgesetz bietet die Chance,
- die Cyberresilienz von OT-Systemen zu erhöhen,
- Betriebsunterbrüche durch klare Prozesse zu minimieren,
- sowie Vertrauen bei Kunden, Partnern und Behörden zu stärken.
Das ISG schafft damit nicht nur regulatorische Klarheit, sondern setzt auch wichtige Impulse für den nachhaltigen Ausbau der OT-Sicherheit. Entscheidend ist dabei die konsequente Umsetzung der Anforderungen im operativen Betrieb, um Risiken frühzeitig zu erkennen und die Widerstandsfähigkeit kritischer Systeme dauerhaft zu erhöhen.
In der Praxis zeigt sich, dass insbesondere eine strukturierte Herangehensweise an Governance, Prozesse und technische Schutzmassnahmen den grössten Hebel für eine robuste OT-Resilienz bietet.
Gerne unterstützen wir Sie bei der ISG-Umsetzung und liefern Ihnen massgeschneiderte Empfehlungen für Ihre OT-Sicherheit. Kontaktieren Sie uns hierzu gerne und jederzeit!
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
Cyberangriffe ohne Hollywood-Hacking: 350 analysierte Fälle. Drei Muster.
Cybersicherheit scheitert selten daran, dass irgendwo ein einzelnes Tool fehlt. Weitaus häufiger liegen die Ursachen in gewachsenen Strukturen, stillen Annahmen und blinden Flecken, die über Jahre niemand mehr hinterfragt. Warum Sichtbarkeit dabei entscheidend ist, haben wir in einem weiteren Beitrag zum Thema beleuchtet. Was im Alltag als logisch, effizient oder historisch gewachsen gilt, kann im Ernstfall zum Einfallstor für Angreifer werden. Drei Szenarien zeigen, wo Unternehmen besonders häufig angreifbar bleiben – und wie sich die grössten Risiken gezielt entschärfen lassen.
Szenario 1: Ransomware über VPN-Zugang und gestohlene Zugangsdaten
Ein Mitarbeitender verwendet dieselben Zugangsdaten über Jahre hinweg sowohl privat wie auch geschäftlich. Das Passwort im Geschäft wird gemäss den internen Richtlinien zwar regelmässig geändert, aber eigentlich ist die Basis des Passworts immer gleich, nur werden die Zahlen jeweils ein wenig geändert.
Für den Mitarbeitenden ist es üblich, dass er ab und zu von seinem privaten Computer die Geschäfts-E-Mails überprüft und aus Gründen der Bequemlichkeit, wird das Passwort im Browser gespeichert, damit er es nicht jedes Mal erneut abtippen muss. Der Mitarbeitende lädt sich aus Versehen aus dem Internet einen InfoStealer herunter und installiert diesen. Der InfoStealer ist Teil einer legitimen Software, welche der Mitarbeitende für private Zwecke nutzen möchte.
Völlig unbemerkt kann dieser InfoStealer erfolgreich ausgeführt werden, wodurch sämtliche gespeicherten Passwörter an Cyberkriminelle übermittelt werden. Welche diese Zugangsdaten für ein paar wenige Dollar auf Cybercrime-Marktplätzen zum Verkauf anbieten.
Ransomware-Affiliates sind auf Unternehmenszugänge angewiesen, und greifen hierfür gerne auf Cybercrime-Marktplätze zurück, wo sie bei der Durchsicht der neuesten Stealer Logs ein lohnenswertes Ziel identifizieren, nämlich den E-Mail-Zugriff auf ein bekanntes Unternehmen, welche zuvor auf dem privaten Gerät des Mitarbeitenden entwendet wurde.
Mit wenig Aufwand identifiziert der Angreifer, den VPN-Einstiegspunkt des Unternehmens und probiert die zuvor erlangten Zugangsdaten aus: Welch ein Wunder, es wird kein zweiter Faktor bei der Authentifizierung abgefragt und der Ransomware Affiliate hat sich den Zugang zu seinem nächsten Ransomware-Opfer mit wenig Aufwand gesichert.
Nach erfolgreicher Anmeldung findet der Angreifer:
- ein flaches Netzwerk ohne Segmentierung
- administrative Freigaben
- zentrale Dateiserver
- Backup-Systeme
- Hypervisor-Management
- weitere privilegierte Konten
Innerhalb weniger Stunden entwickelt sich aus einem einzelnen VPN-Login ein unternehmensweiter Ransomware-Vorfall.
3 zentrale Massnahmen gegen Ransomware-Vorfälle
- Identitäten härten
– MFA für sämtliche Remote-Zugänge
– Phishing-resistente MFA-Verfahren bevorzugen
– Conditional Access und risikobasierte Anmeldungen - Externe Angriffsfläche überwachen
– Sichtbarkeit über exponierte Unternehmenseinstiege
– Kontinuierliche Überwachung von Stealer Logs
– Kontinuierliches Vulnerability Management - Laterale Bewegung begrenzen
– Netzwerksegmentierung
– Trennung von Benutzer-, Server- und Managementzonen
– Separater Zugriff auf Hypervisoren und Backups
Szenario 2: Supply-Chain-Angriff durch kompromittierte Software
Ein Administrator kümmert sich um seine Serverlandschaft und möchte sämtliche Systeme auf den neusten Stand bringen. Hierzu lädt er sich direkt die notwendigen Updates aus dem Internet herunter, installiert diese und kümmert sich um den nächsten Server.
Auf der Suche nach aktuellen Security Patches landet er auf einer über Google-Ads beworbenen Webseite eines Threat Actors. Dort werden mehrere Business-Applikationen zum Download angeboten. Tatsächlich sind sie mit einer Remote-Management-Lösung gebündelt, die nach der Installation direkten Fernzugriff auf den Server ermöglicht.
Da die Installation durch einen autorisierten Administrator erfolgt, wirken viele Sicherheitskontrollen zunächst unauffällig:
- Die aktualisierte Software ist auf dem neusten Stand
- Die Antivirus-Software hat die legitime Remote-Management-Lösung nicht detektiert
- Der Proxyserver hat den Download ohne Hinweis zugelassen.
In zahlreichen aktuellen Kampagnen wurden genau solche Mechanismen genutzt:
- kompromittierte Open-Source-Komponenten
- kompromittierte Entwicklersoftware und Plugins
- infizierte Softwarepakete/Betriebssystem-Images
Das Gefährliche an dieser Art der Kompromittierung ist, dass der Angreifer einen privilegierten und persistenten Zugriff ins Unternehmen erhält. Je nach kompromittiertem System kann er auch direkt auf kritische Geschäftsdaten zugreifen und diese exfiltrieren. Weitere Angriffstechniken braucht es kaum und genau deshalb bleibt der Vorfall für das Security Monitoring oft lange unauffällig. Wird die Datenexfiltration erkannt, ist es unter realistischen Bedingungen meist bereits zu spät: Kritische Informationen haben das Unternehmen dann längst verlassen.
Solche Angriffsmuster beobachten wir sowohl bei Nation-State-Akteuren wie auch bei Initial-Access-Brokern und Ransomware-Gruppierungen. Sie nutzen diese Techniken zunehmend, weil sie effizient, schwer erkennbar und sehr wirkungsvoll sind.
4 zentrale Massnahmen gegen Supply-Chain-Angriffe
- Privilegierte Zugriffe reduzieren
– Least Privilege konsequent umsetzen
– Separate Administrationskonten
– Privileged Access Management - Software-Lieferkette absichern
– Herkunft von Software überprüfen
– Kritische Updates vor Rollout validieren
– Software Bill of Materials (SBOM) nutzen - Verhalten statt Signaturen überwachen
– EDR-Abdeckung auf allen kritischen Systemen
– Monitoring von Build-Servern
– Monitoring von Entwickler-Workstations
– Erkennung ungewöhnlicher Netzwerkkommunikation -
Kritische Systeme isolieren
– Segmentierung von Management- und Produktionssystemen
– Einschränkung direkter Internetzugriffe
– Kontrollierte Software-Verteilung
Bewerten Sie die relevanten Cyberrisiken für Ihr Unternehmen und priorisieren Sie die passenden Schutzmassnahmen. Das Whitepaper «InfoGuard Threat Intelligence Insights 2025» liefert dazu das Know-how für Ihren Realitätscheck.
Szenario 3: Ghost Sender – Wenn Konfigurationsfehler zum Sicherheitsrisiko werden
Beim Threat Hunting stösst das Analyseteam auf Anomalien in den E-Mail-Logs. Die Analyse zeigt mehrere ungewöhnliche E-Mail-Absenderadressen, über die Links zu unbekannten Webseiten an hochprivilegierte Konten versendet wurden.
Eine vertiefte Analyse der Logs zeigt zunächst ein irritierendes Bild: Die E-Mails scheinen aus der eigenen Organisation zu stammen. Der Verdacht einer Kompromittierung steht im Raum, entsprechend wird eine Taskforce einberufen, welche den Sachverhalt prüfen soll.
Die ersten Analysen zeigen keine Kompromittierung des on-prem Exchange Servers. Es wurden keine kompromittierten Endgeräte identifiziert und auch sonst gibt es keine verdächtigen Logins, welche den Sachverhalt erklären würden. Das Analyseteam stellt zudem fest, dass der Sachverhalt bereits seit einigen Monaten andauert. Zunächst fielen jedoch nur Testnachrichten, Fehlzustellungen und vereinzelte E-Mails auf, die nicht plausibel wirkten, aber nicht weiter untersucht wurden.
Die Taskforce bespricht die aktuellen Findings. Hinweise auf eine Kompromittierung gibt es nicht. Die E-Mail-Konfiguration wurde seit Jahren nicht verändert und scheint nicht manipuliert worden zu sein. Auch Hinweise auf die Kompromittierung eines Drittanbieters lässt sich nicht nachweisen. Dann formuliert jemand aus dem Team die Hypothese, dass das Email Security Gateway möglicherweise umgangen wurde.
Wie konnte diese E-Mail-Fehlkonfiguration entstehen?
Die Organisation betreibt eine moderne E-Mail-Sicherheitsarchitektur und hat vor Exchange Online ein etabliertes Secure E-Mail Gateway vorgeschaltet. Die Annahme des Unternehmens? Sämtliche E-Mails müssen diese Kontrollpunkte passieren. Genauso war es in der Architektur auch definiert.
Die Analyse zeigt jedoch, dass Exchange Online weiterhin direkte Zustellungen aus dem Internet zulässt. Der Gateway ist also vorhanden, die Sicherheitskontrollen für den definierten Mailfluss sind implementiert und auch die entsprechenden Prozesse sind korrekt etabliert. Doch zusätzlich existiert ein alternativer Pfad, der womöglich bei der Einführung notwendig war, aber in keinem Architekturdiagramm auftaucht und nie Teil des Bedrohungsmodells war. Diese Bedrohung hat nun einen Namen «Ghost Sender».
Welche Lehren lassen sich daraus ziehen?
Ghost Sender ist technisch betrachtet eine Fehlkonfiguration und organisatorisch ein blinder Fleck. In diesem Fall hat niemand fahrlässig gehandelt: Der Gateway ist korrekt installiert, die Umgebung korrekt betrieben, die Sicherheitsverantwortlichen haben ihre Aufgaben erfüllt. Doch ist die Architektur über die Jahre komplexer geworden.
Spamfilter wurden implementiert, E-Mail Archivierung integriert, diverse Partneranbindungen geschaffen, Cloud-Migrationen umgesetzt, Ausnahmeregeln definiert und temporäre Workarounds implementiert. Jede dieser Änderungen ist nachvollziehbar. Doch jede zusätzliche Komponente erhöht die Komplexität des Gesamtsystems und genau dort entstehen Risiken. Sicherheitsarchitekturen altern. Deshalb müssen sie regelmässig validiert und kritisch hinterfragt werden. Denn die gefährlichsten Schwachstellen sind nicht die, die man kennt, sondern jene von denen man überzeugt ist, dass sie gar nicht existieren können.
Die Komplexität ist nicht nur ein Problem bei der Erkennung solcher Schwachstellen, sondern auch in der Behebung davon. So konnte beispielsweise in der Praxis beobachtet werden, dass einige Unternehmen mehrere Wochen benötigten, um die Fehlkonfiguration zu beheben, während sie in dieser Zeit anfällig für entsprechende Phishingangriffe waren.
3 zentrale Massnahmen gegen Ghost Sender
- Konfigurationshygiene etablieren
– Regelmässige Überprüfung von SPF
– DKIM korrekt implementieren
– DMARC Enforcement aktivieren - Externe Sicht einnehmen
– Kontinuierliche Überwachung der eigenen Angriffsfläche
– Validierung von DNS- und Mail-Konfigurationen
– Regelmässige Exposure-Assessments - Prozesse für schnelle Reaktion schaffe
– Veranwortlichkeiten definieren
– Kritische Änderungen priorisieren
– Standardisierte Risikoanalysen etablieren
Das gemeinsame Angriffsmuster hinter allen drei Vorfällen
Auf den ersten Blick wirken diese Angriffe völlig unterschiedlich.
- Ransomware über VPN
- Supply-Chain-Kompromittierung
- Ghost-Sender-Fehlkonfiguration
Tatsächlich teilen sie dieselbe Ursache
Fehlende Transparenz über Risiken, die ausserhalb des direkten Blickfelds liegen.
Der VPN-Zugang ohne MFA war exponiert. Die Lieferkette wurde ungeprüft als vertrauenswürdig behandelt. Die Mail-Infrastruktur enthielt unbekannte Schwachstellen oder Fehlkonfigurationen. Keiner dieser Angriffe begann mit einem hochkomplexen technischen Exploit. Sie begannen mit einer Sicherheitslücke in der Sichtbarkeit, Kontrolle oder der Governance.
Cyberrisiken sehen, bevor sie zum Angriffspfad werden
Die entscheidende Frage lautet heute nicht mehr: «Haben wir genügend Security-Produkte?» Sondern: «Wissen wir, welche Risiken ausserhalb unseres aktuellen Sichtfelds existieren?» Wer seine Identitäten schützt, die Software-Lieferkette überwacht und externe Angriffsflächen kontinuierlich versteht, reduziert und nicht nur die Wahrscheinlichkeit erfolgreicher Cyberangriffe, sondern erkennt Bedrohungen deutlich früher.
Diese drei Beispiele zeigen dabei nur einen kleinen Ausschnitt aktueller Angriffsmuster.
In unserem aktuellen InfoGuard Threat Intelligence Whitepaper analysieren wir:
- die wichtigsten Angriffsvektoren des vergangenen Jahres
- aktuelle Entwicklungen im Bereich Ransomware, Supply Chain und Identity Attacks
- teilen konkrete Incident-Response-Erkenntnisse aus der Praxis
- und priorisierte Schutzmassnahmen für Unternehmen und Behörden
Nutzen Sie das kostenlose Whitepaper «InfoGuard Threat Intelligence Insights 2025» als Realitätscheck: Prüfen Sie, welche Angriffsmuster jetzt besonders relevant sind und welche Massnahmen für Ihre Organisation Priorität haben.
Sie möchten keine wichtigen Entwicklungen verpassen? Abonnieren Sie unsere Blog-Updates und profitieren Sie von regelmässigen Einblicken in aktuelle Bedrohungstrends, Sicherheitsrisiken und relevante Marktbewegungen.
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
