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
AI Trust statt Bauchgefühl: Warum KI verifizierbare Trust-Architekturen braucht
Durch die wachsende Autonomie von KI-Systemen darf Vertrauen kein Bauchgefühl bleiben. Unternehmen müssen wissen, welche KI-Systeme aktiv sind, welche Rechte sie besitzen und ob ihre Ergebnisse nachvollziehbar bleiben. Klassische Security- und Governance-Modelle stossen hier an Grenzen. Sie wurden vor allem für Menschen, Geräte, Applikationen und bekannte Softwareprozesse entwickelt.
KI-Systeme verhalten sich jedoch dynamischer. Sie können Daten verarbeiten, Aktionen auslösen, externe Tools einbinden und über Systemgrenzen hinweg agieren. Unternehmen brauchen deshalb eine neue Vertrauensarchitektur: AI Trust. Gemeint ist ein Ansatz, der Identität, Berechtigungen, Integrität und Herkunft von KI-Systemen und KI-generierten Inhalten technisch überprüfbar macht.
Von Digital Trust zu AI Trust
Digital Trust basiert seit Jahren auf bewährten Prinzipien wie Public Key Infrastructure, Zertifikaten, DNS und Verschlüsselung. Diese Mechanismen sorgen dafür, dass digitale Kommunikation geschützt, Identitäten überprüft und Systeme authentifiziert werden können.
Mit KI erweitert sich dieser Vertrauensraum. Unternehmen müssen künftig nicht nur wissen, wer auf ein System zugreift, sondern auch:
- Welche KI-Agenten aktiv sind
- Welche Daten sie verarbeiten
- Welche Berechtigungen sie besitzen
- Ob ein Inhalt echt, verändert oder KI-generiert wurde
AI Trust überträgt bewährte Vertrauensmechanismen auf KI. Ziel ist es, KI-Agenten, Modelle und Inhalte nicht nur zu regulieren, sondern technisch kontrollierbar zu machen.
Shadow AI: Wenn KI der Governance davonläuft
Viele Unternehmen nutzen KI bereits produktiv – teils offiziell, teils informell. Besonders kritisch ist sogenannte Shadow AI: der Einsatz von KI-Tools oder Agenten ausserhalb freigegebener Prozesse.
Dadurch entstehen blinde Flecken. Sensible Daten können unkontrolliert verarbeitet werden. Agenten erhalten möglicherweise zu weitreichende Rechte. Und Security-Teams wissen nicht immer, welche KI-Systeme tatsächlich im Einsatz sind.
Für CISOs wird Shadow AI damit zum Transparenztest. Entscheidend sind fünf Fragen:
- Welche KI-Agenten werden im Unternehmen genutzt?
- Welche Daten fliessen an diese Systeme?
- Welche Agenten besitzen Zugriff auf interne Systeme?
- Können kompromittierte Agenten sofort gestoppt werden?
- Lässt sich ein Vorfall nachvollziehbar dokumentieren?
Die Antwort darauf kann nicht allein in Richtlinien liegen. KI-Governance muss technisch durchsetzbar werden.
Drei Bereiche, in denen Vertrauen neu gedacht werden muss
AI Trust betrifft vor allem drei Ebenen: Agenten, Modelle und Inhalte.
- Vertrauen in KI-Agenten – AI Agent Passport
KI-Agenten sind keine menschlichen Benutzer. Passwörter oder klassische Login-Prozesse greifen hier zu kurz. Agenten benötigen eindeutige, kurzlebige und überprüfbare Identitäten. So lässt sich kontrollieren, welche Aktionen sie ausführen dürfen, auf welche Daten sie zugreifen können und wann ein Zugriff beendet werden muss.
Ein Ansatz dafür ist der AI Agent Passport. Er verbindet die Identität eines Agenten kryptographisch mit seinen Berechtigungen. Damit wird nachvollziehbar, was ein Agent tun darf, in welcher Umgebung er aktiv ist und wer dafür verantwortlich ist. - Vertrauen in KI-Modelle – Confidential Computing
KI-Modelle werden zunehmend zu kritischen Unternehmensressourcen. Sie unterstützen Diagnosen, erkennen Betrug, automatisieren Compliance-Prozesse oder beeinflussen geschäftsrelevante Entscheidungen.
Deshalb müssen Unternehmen sicherstellen, dass Modelle nicht manipuliert, unerlaubt verändert oder in unsicheren Umgebungen ausgeführt werden. Dazu braucht es unter anderem kryptographisches Signieren, Integritätsprüfungen und nachvollziehbare Modellherkunft. Besonders relevant ist Confidential Computing. Dabei werden Modelle in geschützten Ausführungsumgebungen betrieben. So bleiben Daten und Modellinformationen auch während der Verarbeitung geschützt. - Vertrauen in KI-generierte Inhalte – C2PA
KI kann heute Texte, Bilder, Videos und strukturierte Daten in hoher Qualität erzeugen oder verändern. Für Unternehmen wird deshalb die Frage zentral: Woher stammt ein Inhalt? Wurde er verändert? Und kann seine Echtheit unabhängig geprüft werden? Metadaten oder Plattformhinweise reichen dafür nicht aus. Sie können entfernt oder verändert werden. Standards wie C2PA schaffen eine Grundlage, um digitale Inhalte mit signierten Herkunftsnachweisen zu versehen. So wird überprüfbar, wer einen Inhalt erstellt hat und ob er seitdem verändert wurde.
Identität, Kryptographie und DNS als Vertrauensanker
Eine tragfähige AI-Trust-Architektur braucht technische Kontrollpunkte. Dazu gehören DNS-basierte Richtlinien, kryptographische Identitäten, kurzlebige Credentials, Attestation und Integritätsnachweise.
Ein Beispiel: Bevor ein KI-Agent eine externe Verbindung aufbaut, kann geprüft werden, ob die Ziel-Domain erlaubt ist. Ist sie nicht freigegeben, wird die Verbindung blockiert, bevor Daten abfliessen oder unerlaubte Aktionen ausgelöst werden.
Solche Mechanismen machen aus abstrakter Governance konkrete Kontrolle. Unternehmen können festlegen, welche Agenten was tun dürfen – und diese Regeln technisch durchsetzen.
Von Transparenz zu Kontrolle: 5 Schritte für AI Trust
Am Anfang steht die Bestandesaufnahme. Unternehmen sollten erfassen, welche KI-Tools, Agenten und Modelle bereits genutzt werden und welche Datenflüsse damit verbunden sind.
Darauf aufbauend sollten sie definieren:
- Welche KI-Systeme erlaubt sind
- Welche Daten verarbeitet werden dürfen
- Welche Identitäten und Berechtigungen erforderlich sind
- Wie Modelle geschützt und überprüft werden
- Wie KI-generierte Inhalte gekennzeichnet und verifiziert werden können
So wird AI Trust zu einem praktischen Sicherheits- und Governance-Thema – nicht zu einem theoretischen Konzept.
DigiCert als Leader für Intelligent Trust
Moderne Ansätze für Digital Trust setzen genau hier an. DigiCert positioniert sich als globaler Leader für Intelligent Trust und erweitert bewährte Prinzipien wie PKI, DNS, Certificate Lifecycle Management, Attestation und kryptographische Identität auf die Anforderungen moderner KI-Umgebungen.
Die Plattform DigiCert ONE vereint zentrale Trust-Funktionen in einer integrierten Architektur und unterstützt Unternehmen dabei, digitale Vertrauensanker sichtbar, steuerbar und automatisierbar zu machen. Dazu gehören unter anderem PKI, DNS, Zertifikatsmanagement, Software Trust, Device Trust und Content Trust.
Für AI Trust entsteht daraus eine technische Grundlage, mit der Organisationen KI-Systeme nicht nur nutzen, sondern kontrolliert, nachvollziehbar und verantwortungsvoll betreiben können.
InfoGuard & DigiCert – Vertrauen für die nächste KI-Ära
Mit DigiCert erweitert InfoGuard bewährte Digital-Trust-Prinzipien auf die Anforderungen moderner KI-Umgebungen. Bereits beim automatisierten Zertifikatsmanagement zeigt sich, wie wichtig Transparenz, Automatisierung und Krypto-Agilität für stabile und sichere digitale Infrastrukturen sind. Im KI-Kontext gewinnen dieselben Prinzipien zusätzlich an Bedeutung: Identitäten müssen überprüfbar, Berechtigungen kontrollierbar und Integrität kontinuierlich nachweisbar sein.
So entsteht die Grundlage, um KI nicht nur produktiv einzusetzen, sondern sicher, nachvollziehbar und kontrollierbar zu betreiben. Erfahren Sie im Whitepaper, wie die «Trust Architecture for AI» von DigiCert Unternehmen dabei unterstützt, Vertrauen in KI-Systeme technisch überprüfbar zu machen.
InfoGuard begleitet Unternehmen, ihre AI Trust von Anfang an als Sicherheits- und Architekturthema zu denken – von Governance-Fragestellungen über technische Integration bis zur Absicherung von Identitäten, Daten, Cloud- und KI-Umgebungen. Unsere Expert:innen freuen sich auf den unverbindlichen Austausch!
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
API-Security: So schützen Sie Schnittstellen effektiv vor KI-Angriffen
Wenn zentrale Schnittstellen zur Schwachstelle werden
Die Anzahl der API-Angriffe steigt signifikant. Der Einsatz von KI fungiert dabei als Beschleuniger für Angriffe und erschwert zugleich die Erkennung von Sicherheitslücken. Laut Akamais State of the Internet Report 2026 stieg die durchschnittliche Anzahl täglicher API-Angriffe pro Unternehmen von 121 (2024) auf 258 im Jahr 2025, was einem Anstieg von 113 % entspricht. Betroffen sind auch Finanzdienstleister, E-Commerce-Plattformen sowie KMU, die häufig veraltete oder undokumentierte APIs betreiben.
API-Security ist damit kein technisches Spezialthema mehr, sondern ein geschäftskritischer Faktor für Verfügbarkeit, Datenschutz und Compliance.
APIs verbinden zentrale Prozesse, Daten und Systeme, bei häufig fehlender Transparenz und Kontrolle. Genau daraus entstehen neue Angriffsflächen.
Drei Risikobereiche sind dabei besonders relevant: Shadow APIs, Business Logic Abuse und KI-gestützte Angriffe auf APIs.
Drei Risikobereiche, die API-Security unverzichtbar machen
1. Shadow APIs: Das unsichtbare Risik
Viele Unternehmen betreiben mehr APIs als dokumentiert. Undokumentierte oder vergessene Schnittstellen („Shadow APIs“) entziehen sich oft der Sicherheitsüberwachung und werden gezielt angegriffen. Die Folgen reichen von unkontrollierten Datenzugriffen und Compliance-Verstössen bis hin zu einer erheblich vergrösserten Angriffsfläche.
Handlungsempfehlungen:
- Regelmässige API-Discovery-Scans durchführen
- Ein zentrales API-Inventar mit klaren Verantwortlichkeiten etablieren
- APIs in regelmässige Sicherheitsprüfungen und Penetrationstests einbeziehen
Zentrale Erkenntnis für Unternehmen:
Fehlende API-Transparenz ist kein technisches Randproblem, sondern vor allem ein Governance-Thema. Was nicht bekannt ist, kann weder bewertet noch geschützt werden. Der erste Schritt wirksamer API-Security besteht deshalb darin, Transparenz über die eigene API-Landschaft zu schaffen.
2. Business Logic Abuse: Wenn legitime APIs missbraucht werden
Beim Business Logic Abuse greifen Angreifer nicht technische Schwachstellen an, sondern missbrauchen die Geschäftslogik einer API selbst. Typische Szenarien sind Preismanipulationen im E-Commerce durch manipulierte Rabattcodes, das Umgehen von Zahlungsprozessen durch veränderte Parameter, automatisiertes Daten-Scraping für Wettbewerbsanalysen oder Identitätsmissbrauch durch variierte Anfragen.
Handlungsempfehlungen:
- Validierung von API-Schemas und Geschäftsregeln
- Systematische Tests der Business Logic (inkl. Missbrauchsszenarien)
- Durchgängiges Rate Limiting und Throttling
Zentrale Erkenntnis für Unternehmen:
Business Logic Abuse ist primär ein Anwendungs- und Prozessrisiko. Angriffe erfolgen über legitime Funktionen, ohne dass klassische Schwachstellen notwendig sind. Entscheidend ist daher nicht nur die Absicherung der API, sondern das Verständnis und die kontinuierliche Überwachung der zugrunde liegenden Geschäftslogik.
3. KI-gestützte Angriffe auf APIs: Wenn Angriffe skalierbar und adaptiv werden
Künstliche Intelligenz verändert die Angriffslandschaft grundlegend. Angreifer setzen zunehmend KI-gestützte Tools ein, um Schwachstellen automatisiert zu identifizieren, Angriffe zu skalieren und ihr Verhalten dynamisch an legitimen API-Traffic anzupassen.
Dadurch steigt das Tempo der Angriffe, während ihre Erkennbarkeit sinkt. Klassische, regelbasierte Sicherheitsmechanismen stossen dabei zunehmend an ihre Grenzen.
Handlungsempfehlungen:
- Einsatz KI-basierter Anomalieerkennung
- Integration von API-Monitoring ins Security Operations Center (SOC)
- Stärkung von Credential- und Token-Sicherheit
Zentrale Erkenntnis für Unternehmen:
KI-gestützte Angriffe stellen ein dynamisches Bedrohungsrisiko dar. Sie erhöhen Geschwindigkeit, Skalierung und Tarnfähigkeit von Angriffen erheblich. Wirksam begegnen lässt sich dieser Entwicklung nur durch eine innovative Sicherheitsarchitektur sowie verhaltensbasierte Erkennung und kontinuierliches Monitoring von API-Aktivitäten.
Security Architecture & Design entdecken
API-Sicherheit: Schritt-für-Schritt Anleitung
Mit zunehmender Komplexität moderner API-Landschaften reicht punktuelle Absicherung nicht mehr aus. Professionelle API-Security ist weit mehr als die reine Absicherung einzelner Schnittstellen. Sie muss entlang des gesamten API-Lifecycles gedacht werden. Somit ist sie kein Einzelprojekt, sondern ein kontinuierlicher Prozess, der Technologie, Entwicklung und Governance verbindet.
Der folgende Leitfaden zeigt, wie Unternehmen ihre API-Sicherheit strukturiert verbessern und Risiken nachhaltig reduzieren können.
1. API-Discovery & Inventory
Transparenz ist die Grundlage jeder wirksamen API-Sicherheit. Nur wer alle APIs kennt, kann sie schützen.
- Automatisierte Erkennung aller APIs
- Aufbau eines zentralen, gepflegten API-Inventars
- Klare Verantwortlichkeiten für jede API (z. B. Product Owner)
2. Moderne Authentifizierung & Autorisierung
Veraltete Authentifizierungsverfahren erhöhen das Risiko unnötig. Moderne Standards schaffen hier deutlich mehr Sicherheit und Kontrolle.
- Ablösung einfacher API-Keys und Basic Auth
- Einsatz von OAuth 2.0 und OpenID Connect
- Granulare Zugriffskontrollen (ABAC) auf Objektebene
- Vermeidung von Broken Object Level Authorization (BOLA)
3. Schutz durch Rate Limiting & Schema Validation
Viele Angriffe auf APIs sind automatisiert – und damit hochskalierbar.
Entsprechende Schutzmechanismen reduzieren diese Risiken deutlich.
- Rate Limiting für alle APIs aktivieren (z. B. 100 Requests/Minute pro Benutzer)
- Nutzung von OpenAPI-Spezifikationen als „Positive Security Model“
- Integration von Schema-Validierung in CI/CD-Pipelines
4. KI-basierte Abwehr & SOC-Integration
Die Angriffsgeschwindigkeit steigt – klassische Reaktionsmodelle reichen oft nicht mehr aus. Daher gewinnen automatisierte Erkennung und SOC-Integration an Bedeutung.
- API-spezifische Use Cases im SOC etablieren
- Dedizierte Alerts für API-Missbrauch definieren
- Security-Teams im Umgang mit KI-gestützten Angriffen schulen
5. DevSecOps & automatisierte Compliance
API-Security muss früh im Entwicklungsprozess verankert sein – nicht erst im Betrieb.
- Security-Kontrollen früh in der Entwicklung integrieren
- Automatisierte Compliance-Checks implementieren
- Entwickler gezielt in API-Security schulen
Tokens und Verifiable Credentials als strategische Ergänzung
Die Kombination aus Tokens und Verifiable Credentials (VCs) entwickelt sich zunehmend zu einer wichtigen Erweiterung moderner API-Sicherheitsarchitekturen.
Während Tokens (z. B. JWT) für die Echtzeit-Authentifizierung und -Autorisierung von API-Zugriffen eingesetzt werden, ermöglichen VCs die Verifikation von Identitäts- oder Qualifikationsnachweisen.
Zusammenspiel in der Praxis:
- API-Keys durch Token-basierte Verfahren (z. B. JWT) ersetzen
- Verifiable Credentials für Identitäts- und Mitarbeiternachweise nutzen
- API-Gateways zur Validierung von VCs integrieren
- Kunden-APIs durch Kombination aus Token und VC absichern
Warum die Kombination aus Tokens & VCs entscheidend ist
Tokens allein bestätigen lediglich eine Zugriffsberechtigung – nicht jedoch die dahinterliegende Identität oder deren Eigenschaften. Verifiable Credentials hingegen sind nicht für die dynamische Echtzeit-Autorisierung von API-Requests ausgelegt.
Erst die Kombination beider Ansätze schafft eine moderne Sicherheitsarchitektur:
- kryptografisch abgesicherte Identität (VCs)
- kurzlebige, dynamische Zugriffsrechte (Tokens)
- datensparsame Authentifizierung im Sinne von Datenschutz und DSGVO
API-Security: Strategischer Mehrwert für Unternehmen
API-Security ist eine grundlegende Voraussetzung für skalierbare digitale Geschäftsmodelle. Richtig umgesetzt, entsteht daraus klarer geschäftlicher Mehrwert:
- Schutz sensibler Daten und kritischer Geschäftsprozesse
- Reduktion von Betriebsunterbrüchen und Sicherheitsvorfällen
- Erfüllung regulatorischer Anforderungen
- Stärkung von Vertrauen bei Kunden und Partnern
API-Security entwickelt sich damit vom technischen Detail zu einem strategischen Enabler moderner Digitalisierung.
Fazit & Ausblick: API-Sicherheit als strategische Daueraufgabe
API-Security ist kein einmaliges Projekt, sondern ein kontinuierlicher Prozess entlang des gesamten API-Lifecycles. Entscheidend ist die konsequente Verankerung in Entwicklung, Betrieb und Governance. Zentrale Grundlage ist dabei eine API-Security-Roadmap, die Security frühzeitig in den Entwicklungs- und Betriebsprozess integriert (DevSecOps) und Sicherheit nicht nachgelagert, sondern systematisch verankert. Ergänzend gewinnen Automatisierung und Zero-Trust-Prinzipien zunehmend an Bedeutung.
Wer API-Security strategisch denkt, schafft nicht nur mehr Sicherheit, sondern auch die Grundlage für skalierbare digitale Innovation.
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
Email Spoofing: Weit verbreitete Fehlkonfiguration in Exchange Online
Phishing, Business Email Compromise (BEC), CEO-Fraud, Ransomware – nahezu jede grössere Cyberkampagne beginnt mit einer E-Mail. Entsprechend hoch sind die Investitionen von Unternehmen in Mail-Gateways, Spamfilter und Protokolle wie SPF, DKIM und DMARC.
Im Rahmen aktueller Sicherheitsanalysen hat das InfoGuard Red Team jedoch eine weit verbreitete Fehlkonfiguration bei Microsoft Exchange Online identifiziert. Unter bestimmten Voraussetzungen können Angreifende E-Mails direkt an den Tenant zustellen, ohne die vorgelagerte E-Mail-Sicherheitslösung zu durchlaufen. Dadurch lassen sich etablierte Schutzmechanismen umgehen und E-Mails mit beliebigen internen oder externen Absenderadressen zustellen.
Die Folgen können gravierend sein: Gezielte Phishing-Angriffe lassen sich dadurch über die eigene Maildomäne des Unternehmens durchführen. So könnten sich Angreifende beispielsweise als CEO ausgeben und Mitarbeitende mit täuschend echten internen E-Mails zur Preisgabe von Informationen oder zur Ausführung von Aktionen verleiten.
Ghost-Sender in Exchange Online: Was passiert konkret?
Bei bestimmten Exchange-Online-Konfigurationen können E-Mails unter Umständen direkt an den Tenant zugestellt werden, ohne dass sie die vorgelagerte E-Mail-Sicherheitslösung durchlaufen. Dadurch werden etablierte Schutzmechanismen wie SPF, DKIM, DMARC und Spamfilter umgangen und externe Angreifer können wahlweise interne und externe Absender impersonieren.
Nach Einschätzung von Microsoft handelt es sich nicht um eine Produktschwachstelle, sondern um eine Konfigurationssituation im Zusammenspiel von Exchange Online und vorgelagerten Mail-Gateways.
Wer ist betroffen von Ghost-Sendern?
Typischerweise betroffen sind Organisationen, die:
- Exchange Online (auch im Hybrid-Modus mit Exchange On-Premises) einsetzen, und
- eingehende E-Mails über ein externes Mail-Gateway oder eine Drittanbieter-Sicherheitslösung führen.
Nach unseren Beobachtungen betrifft dies eine Vielzahl von Umgebungen, inklusive grosser und sicherheitstechnisch gut aufgestellter Organisationen.
Ghost-Sender-Risiken: So schliessen Sie blinde Flecken in Exchange Online
E-Mail-Sicherheit endet nicht beim Produktkauf, sondern beginnt bei der präzisen Konfiguration und dem kontinuierlichen Monitoring. Das Ghost-Sender-Szenario zeigt exemplarisch, wie schnell sich blinde Flecken in komplexen Architekturen einschleichen – selbst in Organisationen mit hohen Security-Ansprüchen.
Wer jetzt handelt, kann:
- kritische Konfigurationslücken schliessen,
- Impersonation-Angriffe wirksam erschweren
- und die eigene Cyberresilienz nachhaltig stärken.
Um eine schnelle Erstprüfung zu ermöglichen, hat InfoGuard ghost-sender.com entwickelt.
Ghost-Sender-Test: Mail-Domänen in drei Schritten prüfen
Unsere eigens für dieses Szenario entwickelte Plattform erlaubt es, Mail-Domänen gezielt auf mögliche Ghost-Sender-Risiken zu testen. Zusätzlich steht ein ausführlicher technischer Artikel im InfoGuard-Labs-Blog zur Verfügung.
Wir empfehlen folgende 3 Schritte:
- Domänenprüfung
Prüfen Sie Ihre Mail-Domänen auf ghost-sender.com. - Fachstellen einbinden
Wird eine Betroffenheit festgestellt, wenden Sie sich an Ihren Microsoft-Partner, E-Mail-Provider oder den Betreiber Ihrer Mail-Infrastruktur, um die empfohlenen Schutzmassnahmen zu prüfen und umzusetzen. - Verantwortliche informieren
Informieren Sie die für Ihre E-Mail-Infrastruktur verantwortlichen Personen innerhalb Ihrer Organisation über die Ergebnisse.
Wichtig: Beachten Sie, dass die notwendigen Konfigurationsanpassungen von Ihrer individuellen Exchange-Online- und Mail-Gateway-Umgebung abhängen und nicht zentral durch InfoGuard vorgenommen werden können.
Prüfen Sie jetzt Ihre Mail-Domänen. So verschaffen Sie sich umgehend Klarheit darüber, ob Ihre Organisation von der beschriebenen Konfigurationssituation betroffen ist, erkennen frühzeitig Handlungsbedarf und leiten gemeinsam mit Ihren verantwortlichen Fachstellen gezielt die nächsten Schritte ein.
Deep Dive: Ghost-Sender in Exchange Online verstehen
Im InfoGuard Labs Blog beleuchten wir die technischen Hintergründe des Ghost-Sender-Szenarios im Detail: von den relevanten Exchange-Online- und Mail-Gateway-Konfigurationen bis zu den konkreten Angriffspfaden und Schutzmassnahmen.
Der technische Deep Dive liefert eine fundierte Einordnung der beschriebenen Cyberrisiken und zeigt auf, welche Massnahmen Sie in Ihrer Umgebung prüfen sollten.
Quellen & Referenzen
• Ghost-Sender
• InfoGuard LABS: Universal Email Spoofing against Exchange Online
• NCSC, Cyber Security Hub (CSH): [Advisory] Microsoft Exchange: Arbitrary Email Spoofing
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
