Autor: Firma InfoGuard

API-Security: So schützen Sie Schnittstellen effektiv vor KI-Angriffen

API-Security: So schützen Sie Schnittstellen effektiv vor KI-Angriffen

APIs bilden das digitale Nervensystem moderner Unternehmen. Sie verbinden Cloud-Dienste, KI-Anwendungen, Partnerplattformen und IoT-Systeme und sind damit geschäftskritisch für Verfügbarkeit und Datenflüsse. Als Schnittstelle zwischen Systemen, Daten und Geschäftsprozessen sind sie häufig nur unzureichend sichtbar und kontrolliert. Mit ihrer wachsenden Bedeutung wächst also auch die Angriffsfläche, beschleunigt durch KI. Dieser Artikel zeigt Ihnen die wichtigsten Risiken moderner APIs, inklusive eines praxisnahen Leitfadens zur strukturierten Verbesserung Ihrer API-Sicherheit.

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.

Security Architecture & Design entdecken

Firmenkontakt und Herausgeber der Meldung:

InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch

Ansprechpartner:
Estelle Ouhassi
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

Email Spoofing: Weit verbreitete Fehlkonfiguration in Exchange Online

Email Spoofing: Weit verbreitete Fehlkonfiguration in Exchange Online

Vertrauen Sie darauf, dass eingehende E-Mails immer Ihr Mail-Gateway durchlaufen? Das InfoGuard Red Team hat eine weit verbreitete Fehlkonfiguration bei Exchange Online identifiziert, bei der E-Mails unter bestimmten Voraussetzungen direkt im Tenant landen – vorbei an SPF, DKIM, DMARC und Spamfiltern. Mit der eigens entwickelten Plattform ghost-sender.com können Sie Ihre Mail-Domänen jetzt gezielt auf diese Problematik prüfen und innert Kürze feststellen, ob Handlungsbedarf besteht.

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:

  1. Domänenprüfung
    Prüfen Sie Ihre Mail-Domänen auf ghost-sender.com.
  2. 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.
  3. 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.

Mail-Domänen testen

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.

Zum Deep Dive

Quellen & Referenzen
• Ghost-Sender
• InfoGuard LABS: Universal Email Spoofing against Exchange Online
• NCSC, Cyber Security Hub (CSH): [Advisory] Microsoft Exchange: Arbitrary Email Spoofing

Firmenkontakt und Herausgeber der Meldung:

InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch

Ansprechpartner:
Estelle Ouhassi
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

InfoGuard Threat Intelligence Report Q2/26: Europas Cyberrisiko, Salt Typhoon & Irans Rückkehr

InfoGuard Threat Intelligence Report Q2/26: Europas Cyberrisiko, Salt Typhoon & Irans Rückkehr

Drei Monate nach dem Q1-Report hat die digitale Bedrohungslage Europas eine neue Qualität erreicht: Iran ist nach 47 Tagen digitaler Isolation wieder operativ, Salt Typhoon wurde erstmals offiziell in Skandinavien bestätigt und Russland testet destruktive OT-Angriffe unterhalb der NATO-Schwelle. Parallel entsteht eine neue Eskalationsstufe: Vollautonome Angriffssysteme ohne menschliche Aufsicht sind keine Prognose mehr, sondern operative Realität. Auch die Rolle der USA muss nüchtern eingeordnet werden: Sie agieren als Weltmacht im eigenen Interesse – normal und legitim, aber für europäische Organisationen eine strategische Variable. Der Artikel ordnet die geopolitische Lage ein, liefert konkrete Takeaways und kommt zu einem klaren Befund: Cyberabwehr entscheidet sich heute im frühzeitigen Erkennen realer Risikoexposition.

Die geopolitische Cyberlage hat im zweiten Quartal gegenüber dem Bericht zum ersten Quartal 2026 deutlich an Schärfe gewonnen. Iran, Salt Typhoon, destruktive OT-Angriffe und autonome KI-Systeme machen deutlich: Europas Cyberrisiko entsteht nicht nur durch neue Angriffe, sondern durch immer schwerer sichtbare Abhängigkeiten, Exponierungen und Detektionslücken. Eine Analyse der wichtigsten Verschiebungen zeigt, wo und inwiefern sich die Lage seit Q1/26 verändert hat.

Seit Q1/2026 verschiebt sich Europas Cyberrisiko

Die Übersicht zeigt die Veränderungen auf einen Blick. Anschliessend ordnen wir die fünf Entwicklungen ein und leiten konkrete Takeaways für die Cyberabwehr ab.

1. Iran nach Epic Fury: Vom Hacktivismus zu APT-Operationen1.1  Weshalb ist Irans digitale Rückkehr ein Cyberrisiko für Europa?

Iran ist seit dem 17. April 2026 nach 47 Tagen digitaler Isolation wieder schrittweise vernetzt – und damit können auch hochspezialisierte APT-Einheiten wieder koordinierter agieren. Im Q1-Report haben wir den 28. Februar 2026 als Zäsur beschrieben: Operation Epic Fury löste sofort eine mehrstufige iranische Cyber-Vergeltungswelle aus, koordiniert durch den neu gegründeten Electronic Operations Room mit über 60 aktiven Gruppen. Was die Situation damals vorübergehend technisch entschärfte: Israel und die USA führten gleichzeitig die grösste Cyberoperation gegen Iran durch, die je dokumentiert wurde. Sie reduzierten damit Irans Internetkonnektivität auf 1-4 %. Auch Akteure hochspezialisierter APT-Einheiten waren damit de facto vom Rest der Welt abgeschnitten.

Das hat sich geändert. Was im Q1 noch als chaotischer, dezentraler Hacktivismus sichtbar wurde, droht nun in koordinierte Cyberoperationen überzugehen. Die Reconnection Irans ist deshalb kein Entwarnungssignal. Sie markiert weit mehr den Beginn der gefährlicheren Phase.

1.2 Warum zielen iranische Akteure auf Rockwell Automation?

Iranisch-affiliierte Gruppen verschieben ihren Fokus von Unitronics-PLCs auf Rockwell Automation FactoryTalk – und damit auf eine grössere Angriffsfläche in Industrie, Energieversorgung und Wasserinfrastruktur. Ende März 2026 identifizierte Unit 42 einen neuen Angriffscluster (CL-STA-1128 / CyberAv3ngers), der diese Zielverschiebung sichtbar macht. Bisher hatten die Gruppen primär Unitronics-PLCs angegriffen – israelische Fabrikate, die vergleichsweise begrenzt eingesetzt werden. Nun rückt mit Rockwell Automation FactoryTalk eine OT-Plattform in den Fokus, die deutlich weiter verbreitet ist.

Aus europäischer Sicht ist das relevant: Denn Rockwell-Systeme sind in der Industrieautomation weltweit flächendeckend im Einsatz – in Produktionsanlagen, Energieversorgung und Wasserinfrastruktur, auch in der DACH-Region. Die Angreifer wählen damit eine Angriffsoberfläche, die grösser und potenziell weniger gehärtet ist als die bisher fokussierten Unitronics-Systeme.

Für Unternehmen mit Rockwell-Umgebungen ist das keine abstrakte Warnung. CyberAv3ngers hat bewiesen, dass sie OT-Systeme nicht nur kompromittieren, sondern auch aktiv manipulieren. In früheren Kampagnen wurden Konfigurationen verändert und Prozesse gestört, ohne dass Wiper oder Ransomware notwendig waren.

1.3 RedKitten: Der neue technisch hochentwickelte Akteur

Parallel zu CyberAv3ngers ist ein neu identifizierter iranischer Akteur aufgetaucht, der sich technisch deutlich von den bisherigen Gruppen unterscheidet: RedKitten. Die Gruppe nutzt eine Angriffsmethodik, die explizit darauf ausgelegt ist, unter dem Radar normaler Sicherheitstools zu bleiben.

Die Kernmechanik: Die Angreifenden nutzen präparierte Dokumente, um die SloppyMIO-Backdoor auszuführen. Diese liest per Steganografie Konfigurationsdaten aus Bilddateien auf legitimen Code-Repositories aus. Payloads werden über Cloud-Storage nachgeladen. Die gesamte Kommunikation läuft ausschliesslich über Messaging-Platform-APIs – eine sogenannte Dead-Drop-Resolver-Architektur, die bösartigen Traffic in gewöhnlichem Cloud-Rauschen versteckt.

Das Ergebnis: Traditionelle signaturbasierte Erkennung und netzwerkbasierte Anomalie-Detection greifen nicht, weil der Traffic wie normales SaaS-Nutzungsverhalten wirkt. Nach der öffentlichen Exposition Ende 2025 tauschte RedKitten seine Infrastruktur rasch aus und weitete das Targeting auf über 20 Länder aus – inklusive Westeuropa.

1.4 Europa im Fokus koordinierter Cyberangriffe

Ein für Europa besonders relevantes Muster des laufenden Konflikts: Pro-iranische und pro-russische Hacktivisten-Gruppen koordinieren ihre Cyberoperationen opportunistisch. SOCRadar hat für den ersten Kriegsmonat (28. Februar bis 31. März 2026) 1.357 dokumentierte Incidents in über 25 Ländern und 15 Sektoren erfasst. Zypern wurde mit 68 Incidents zum zweitgrössten europäischen Ziel – nicht zufällig, sondern weil es US-Militärinfrastruktur beherbergt und geographisch exponiert ist. Rumänien folgt mit 58 Incidents.

NoName057(16) nutzt die Iran-Operationen für sogenannte Double-Benefit-Hits: dieselbe DDoS-Welle trifft gleichzeitig iranische Gegner und NATO-Mitglieder im Kontext des Ukraine-Kriegs. Für betroffene europäische Organisationen ist die Attribution dabei oft unklar – und das ist gewollt.

Einschätzung Q2/2026

Wir befinden uns jetzt in der Phase, vor der Analysten seit Februar 2026 gewarnt haben: koordinierte APT-Operationen, keine Ablenkungsmanöver. Organisationen in den Sektoren Energie, Industrie, Telekommunikation und öffentliche Verwaltung sollten ihre Exponierung gegenüber Rockwell-Systemen, VPN-Gateways und exponierten OT-Umgebungen neu bewerten. Die Reconnection Irans ist kein Entwarnungssignal – sie markiert das Ende der Aufwärmphase.

2. China: Salt Typhoon erreicht Nordeuropa

In unserem Q1-Report haben wir Chinas Strategie als Pre-Positioning für einen möglichen Taiwan-Konflikt beschrieben: eine stille, jahrelange Kompromittierung kritischer Infrastruktur, ohne Alarm zu schlagen. Q2/2026 bringt die europäische Bestätigung dessen, was viele bereits ahnten.

2.1 Norwegen: Die erste skandinavische Bestätigung

Im Februar 2026 veröffentlichte Norwegen seinen jährlichen Bedrohungsbericht. PST-Direktorin Beate Gangås bestätigte darin explizit: Salt Typhoon hat Netzwerkgeräte in norwegischen Organisationen kompromittiert – die erste offizielle skandinavische Bestätigung, dass die lange als US-Problem wahrgenommene Kampagne Nordeuropa erreicht hat.

Die Formulierung der PST war bemerkenswert direkt: Norwegen stehe vor seiner schwersten Sicherheitslage seit dem Zweiten Weltkrieg. Norwegens Sicherheitsbehörden beschreiben China, Russland und Iran nicht als abstrakte Bedrohungen, sondern als aktiv operierende Geheimdienste auf norwegischem Boden.

2.2 Die strategische Neubewertung durch ODNI 2026

Das US Office of the Director of National Intelligence stuft chinesische Cyberoperationen im Annual Threat Assessment 2026 neu ein: Volt Typhoon und Salt Typhoon gelten nicht mehr primär als Spionagekampagnen, sondern als Pre-Positioning in kritischer Infrastruktur – mit dem Ziel, Sabotage für potenzielle Konflikte vorzubereiten.

Diese Neubewertung ist für Europa relevant, weil sie die Stossrichtung klarstellt: China baut keine Nachrichtendienstlichen Fähigkeiten auf, es baut Schalter ein. Schalter, die in einer geopolitischen Krise – Taiwan, Handelskrieg, militärische Eskalation – aktiviert werden können. Die europäische Infrastruktur ist dabei nicht Ziel, sondern Hebel: Wer Europa destabilisieren kann, schwächt westliche Unterstützung für Taiwan.

2.3 LOTL in Nordeuropa: Warum Salt Typhoon so schwer zu finden ist

Salt Typhoon und Volt Typhoon teilen eine Methodik, die sie für traditionelle Sicherheitsarchitekturen nahezu unsichtbar macht: Living-off-the-Land. Keine Malware, nur native Systemtools. Keine Command-and-Control-Server mit auffälligen Domains, nur kompromittierte SOHO-Router als Relay-Infrastruktur. In mehreren dokumentierten Fällen blieben die Gruppen bis zu fünf Jahre unentdeckt.

Für Organisationen in Skandinavien, den Niederlanden, Deutschland und Österreich bedeutet das: Die Frage ist nicht mehr nur, ob chinesische Akteure bereits in europäischen Netzwerken präsent sind, sondern ob diese Präsenz bekannt ist. Die Wahrscheinlichkeit dafür ist, basierend auf den verfügbaren Daten, erheblich.

Einschätzung Q2/2026

Die norwegische Bestätigung ist kein Einzelfall. Sie ist die erste öffentlich bestätigte Spitze eines europäischen Eisbergs. Telekommunikations-, Energie- und Verteidigungsunternehmen in Europa sollten davon ausgehen, dass Netzwerkgeräte an der Perimeter – Firewalls, VPN-Concentrators, Switches – primäre Angriffsflächen sind. Diese Geräte sind systematisch unzureichend überwacht und haben typischerweise keine EDR-Abdeckung.

3. Russland: «Below Threshold» als permanente Kriegsführung

Russlands Cyberstrategie gegen Europa ist keine Reaktion auf aktuelle Ereignisse. Sie ist eine dauerhaft angelegte Zermürbungskampagne mit klar definiertem Ziel: maximalen Schaden verursachen, ohne die Article-5-Schwelle der NATO zu überschreiten und eine kollektive militärische Reaktion auszulösen. Q2/2026 macht dieses Kalkül an einem konkreten Fall sichtbar.

3.1 Polen Dezember 2025: Der erste bestätigte destruktive OT-Angriff in der EU

Im Dezember 2025 – einem Monat mit unterdurchschnittlicher Gesamtzahl an Sicherheitsvorfällen – wurde Polen Ziel einer der schwerwiegendsten Cyberoperationen gegen EU-Infrastruktur. Russisch-affiliierte Angreifer kompromittierten Kontrollsysteme im Energiesektor. Kritische Steuerungssysteme wurden gestört, und Industrieausrüstung wurde dauerhaft beschädigt – physisch, nicht «nur» digital. Reparatur statt Wiederherstellung.

Doch entscheidend ist, was nicht passierte: Kein weitreichender Blackout, keine Todesopfer, kein Anlass für eine Article-5-Konsultation. Das Ereignis bleibt genau unterhalb der Eskalationsschwelle, kostet aber polnische Energieversorger Millionen, destabilisiert Vertrauen in kritische Systeme und sendet eine unmissverständliche Botschaft an NATO-Mitglieder, die die Ukraine unterstützen.

Der Atlantic Council dokumentiert in einem Report vom April 2026 über 150 Sabotage-, Cyber- und Influence-Incidents in Europa seit 2022 – mit zunehmender Frequenz und zunehmender Destruktivität. Das Muster ist konsistent: testen, eskalieren, einfrieren, wiederholen.

3.2 Das Vakuum der US-Cyber-Abschreckung

Wenn US-Cyber-Abschreckung nachlässt, steigt für Europa der Druck, eigene Cyberkapazitäten strategischer zu denken. CEPA stellt in einem Bericht vom März 2026 einen Zusammenhang fest: Wo Intelligence-Sharing eingeschränkt wird, koordinierte Reaktionen ausbleiben und Operationen ohne NATO-Vorabinformation erfolgen, sinken die Kosten für russische hybride Angriffe.

Die Logik ist simpel: Wenn die Kosten sinken, steigt die Aktivität. Aus Sicht europäischer Sicherheitsarchitekten ist das ein Wendepunkt. Europa kann nicht mehr davon ausgehen, dass US-Cyber-Kapazitäten als verlängerte Abschreckung wirken. Das ist keine Katastrophe – es ist eine strategische Realität, die Europas eigene Kapazitäten in den Vordergrund rückt.

Einschätzung Q2/2026

Russlands Below-Threshold-Modell ist keine Übergangsphase. Es ist die neue Normalität. Energieversorger, Infrastrukturbetreiber und staatliche Stellen müssen damit rechnen, dass OT-Systeme nicht mehr nur als Spionageziele gelten. Sie gelten zunehmend als Ansatzpunkte für physische Sabotage. Der Dezember-Angriff auf Polen ist ein «Proof of Concept», kein Einzelfall.

4. Warum Angreifer keinen Co-Piloten brauchen4.1  KI-Angriffe und Asymmetrie – ein Flugzeugvergleich

Ein modernes Verkehrsflugzeug kann heute vollständig autonom fliegen. Autopilot, automatische Landung, Kollisionswarnung – technisch gesehen, wäre kein menschlicher Pilot nötig. Trotzdem sitzt in jedem kommerziellen Flugzeug mindestens ein ausgebildeter Mensch im Cockpit. Der Grund ist simpel: Bei 300 Passagieren an Bord sind die Konsequenzen eines Fehlers katastrophal und irreversibel. Das System kann 9.999 Flüge perfekt durchführen, beim 10.000sten muss ein Mensch eingreifen können.

Cyber Defence funktioniert nach exakt demselben Prinzip: Ein unbemerkter Angriff, ein ungeblockter Payload oder ein False Negative auf einem produktiven System kann reichen. Die Verteidigung muss immer gewinnen. Deshalb ist Human-in-the-Loop zwingend: erfahrene Analysten, die Kontext einordnen, Anomalien bewerten und Entscheidungen verantworten.

Für den Angreifer gilt exakt das Gegenteil. Wenn ein autonomer Angriff scheitert, kostet das nichts. Keine menschlichen Stunden, kein Operator, der Konsequenzen trägt. Einfach den nächsten starten – schneller, billiger, mit angepasster Methodik. Die Asymmetrie ist fundamental: Die Verteidigung muss immer, ein Angriff muss nur einmal gewinnen. KI macht den Angriff beliebig skalierbar und wiederholbar: Was scheitert, wird angepasst und erneut gestartet. Für die Verteidigung bleibt die Fehlertoleranz gering. Sie muss automatisieren, aber menschliches Urteilsvermögen in der Beurteilungsschleife behalten.

4.2 Vom KI-Tool zur autonomen Cyberattacke

KI in Cyberangriffen ist nicht neu. Seit Jahren wird KI für Spear-Phishing-Personalisierung, automatisierte Vulnerability-Scans und Malware-Varianten genutzt. Was sich in Q2/2026 verändert hat, ist die Qualität: von KI als Werkzeug zu KI als autonomem Akteur.

Armis-Threat-Intelligence-Chef, Michael Freeman, hat es konkret formuliert: Bis Mitte 2026 wird mindestens ein globales Unternehmen durch ein vollständig autonomes agentic AI-System kompromittiert – mit Reinforcement Learning und Multi-Agent-Koordination für den kompletten Angriffs-Lifecycle ohne menschliche Aufsicht. Reconnaissance, Exploitation, Laterale Bewegung, Datenexfiltration – alles automatisiert, alles ohne menschliches Eingreifen. Das WEF Global Cybersecurity Outlook 2026 zeigt: 87 % der befragten Sicherheitsverantwortlichen weltweit nennen KI-Schwachstellen als die am schnellsten wachsende Bedrohung.

Nation-State-Akteure sind hier nicht Nachzügler, sondern Treiber: Berichte aus der Threat-Intelligence-Community zeigen, dass staatlich gesteuerte Gruppen bereits 90 % ihrer Intrusion-Kampagnen automatisieren. Chinesische Akteure haben laut Anthropic-Bericht (November 2025) vollständig automatisierte Angriffsketten gegen Technologieunternehmen und Regierungsstellen eingesetzt. Iran arbeitet nachweislich an AI-gestützten Spear-Phishing-Systemen.

4.3 RaaS goes Autonomous: Wenn Ransomware nicht verhandelt, sondern vernichtet

Auch in der kriminellen Ransomware-Szene zeigt sich das Muster. Q1/2026 brachte eine Rekonsolidierung des Marktes: Qilin, LockBit und The Gentlemen expandieren. Qilin hat inhouse Legal Services eingeführt, um Druck auf Opfer zu erhöhen. Die Global Group lancierte AI-Chatbots für Verhandlungen – autonome Systeme, die Lösegeldforderungen anpassen, Fristen setzen und kommunizieren, ohne menschliche Intervention.

Die Sicarii-Gruppe geht noch weiter: Ihre Ransomware löscht die eigenen Entschlüsselungsschlüssel nach der Verschlüsselung – eine Waffe, die nicht auf Erpressung abzielt, sondern auf permanente Zerstörung. Eine Zahlung ist sinnlos. Wiederherstellung ist unmöglich. Das ist der Übergang von Ransomware als Geschäftsmodell zu Ransomware als Sabotagewaffe.

4.4 KI-Asymmetrie: Cyberabwehr erfordert Human-in-the-Loop

Die KI-Asymmetrie stellt Sicherheitsarchitekturen vor ein strukturelles Problem: Je mehr Automatisierung auf der Angreiferseite, desto höher ist der Druck, auf der Verteidigerseite ebenfalls zu automatisieren – aber die Fehlertoleranz bleibt asymmetrisch. Automatisierte Defense-Systeme können false positives produzieren, die den Betrieb stören, oder false negatives, die Angriffe durchlassen. Jede Fehlentscheidung in der Abwehr birgt Konsequenzen. Für Angreifende hingegen bedeutet ein Fehlversuch nur Trainingsmaterial für den nächsten Angriff.

Das führt zu einer Konsequenz, die kontraintuitiv erscheint, aber operativ richtig ist: Je autonomer Angriffe werden, desto wichtiger wird der menschliche Threat Hunter. Nicht als Reaktion auf Alarme, sondern als proaktiver Jäger in Umgebungen, in denen automatisierte Systeme systematisch umgangen werden.

Einschätzung Q2/2026

Autonome KI-Angriffe sind kein Zukunftsszenario mehr. Sie sind operativ. Die Verteidigung muss diese Asymmetrie akzeptieren: Automatisierung auf der Verteidigerseite ist notwendig, aber nicht ausreichend. Das Co-Piloten-Modell gilt weiterhin – technische Systeme fliegen das Flugzeug, aber ein erfahrener Mensch muss eingreifen können, wenn es darauf ankommt. 

In die Welt der Cybersecurity übersetzt, heisst dieses Co-Piloten-Modell: Threat Hunting. Gemeint ist eine vertiefte Analyse der Exponierungsrisiken durch erfahrene Incident Responder, die sichtbar macht, was automatisierte Systeme oft übersehen – Spuren, Anomalien und Angriffsmuster, die erst im Kontext der aktuellen Bedrohungslage erkennbar werden.

Proaktives Threat Hunting

5. Der unbequeme Verbündete: Die USA aus europäischer Sicht

Vorbemerkung zum Ton dieses Kapitels: Was folgt, ist keine Kritik an den USA als Land oder Verbündeten. Es ist die nüchterne Anwendung einer Grundregel internationaler Politik, die seit dem Westfälischen Frieden 1648 gilt: Jeder Staat handelt primär im eigenen Interesse. Das ist weder überraschend noch verwerflich – es ist die Realität jedes souveränen Akteurs, inklusive der europäischen Staaten selbst. Die Frage ist nur, ob Europa das als gegeben akzeptiert und entsprechend handelt.

5.1 CYBERCOM 2.0 und die Normalisierung offensiver Cyberoperationen

Im Januar 2026 wurde vor dem US-Senatsausschuss für Streitkräfte die bisher grösste Transformation des US Cyber Command präsentiert: CYBERCOM 2.0. Die zuständige Assistant Secretary of War for Cyber Policy beschrieb es als «die bedeutendste Transformation des USCYBERCOM seit seiner Gründung vor über 15 Jahren» – eine fundamentale Neuaufstellung, die offensive Dauerpräsenz in gegnerischen Netzwerken als Routineinstrument etabliert.

Im März 2026 folgte Trumps neue Nationale Cyberstrategie: explizit aggressiver als alle Vorgänger, mit dem Ziel, Bedrohungen «vor» dem Erreichen amerikanischer Netzwerke zu begegnen. Das Konzept des «Persistent Engagement» – kontinuierliche offensive Operationen in gegnerischer Infrastruktur – wird zur offiziellen Doktrin.

Was bedeutet das für Europa? Zwei Dimensionen: Zum einen stärkt eine leistungsfähigere US-Cyberkapazität die kollektive Abschreckung gegen Russland, China und Iran – davon profitiert Europa indirekt. Zum anderen normalisiert die USA offensive Cyberoperationen als legitimes Staatsmittel auf einer neuen Ebene. Europa wird sich fragen müssen, wie es mit diesem Präzedenzfall umgeht – und ob die gleiche Doktrin, die gegen Moskau vertretbar erscheint, auch das Vertrauen in US-Technologieinfrastruktur beeinflusst.

5.2 CLOUD Act: Das strukturelle Souveränitätsproblem

Das vielleicht konkreteste Risiko für die europäische Cybersicherheit geht nicht von einem Angriff aus, sondern von einem Gesetz. Der US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) erlaubt US-Behörden, von US-amerikanischen Unternehmen Zugang zu Daten zu verlangen – unabhängig davon, wo diese Daten physisch gespeichert sind.

Im Juni 2025 wurde Microsoft France in einer Anhörung vor dem französischen Senat direkt gefragt: Können Sie garantieren, dass europäische Kundendaten nie von US-Behörden angefordert werden? Die Antwort war eindeutig und unter Eid: Nein. Diese Garantie kann nicht gegeben werden. Nicht weil Microsoft das nicht will, sondern weil Microsoft eine US-amerikanische Gesellschaft ist und US-Recht für US-Gesellschaften überall auf der Welt gilt.

Das betrifft nicht nur Microsoft. AWS kann dieselbe Garantie nicht geben. Google auch nicht. Jeder US-Hyperscaler, jede US-basierte Sicherheitslösung, jedes US-EDR – sie alle unterliegen demselben rechtlichen Rahmen. Ein europäisches Rechenzentrum ändert die Geografie der Daten, aber nicht die Jurisdiktion über das Unternehmen.

Für die Cybersecurity-Architektur europäischer Organisationen hat das konkrete Implikationen: Wer US-basierte Sicherheitstools einsetzt – und das ist die grosse Mehrheit – hat potenziell einen dritten Akteur im Netzwerk. Nicht zwangsläufig böswillig, aber ausserhalb europäischer Kontrolle und europäischen Rechts. In einer Zeit, in der sich die Interessen der USA und Europas in Handelsfragen, Geopolitik und Verteidigung zunehmend auseinanderbewegen, ist das eine strategische Variable, die ins Kalkül gehört.

5.3 Drei Incidents – ein Muster

Drei öffentlich dokumentierte Incidents der letzten 15 Monate illustrieren das Muster:

  • Signal-Leak (März 2025): US-Verteidigungsminister Pete Hegseth besprach Militärpläne über eine nicht klassifizierte kommerzielle App und teilte sie versehentlich mit einem Journalisten. Intern bezeichnete er Europa als «Freeloaders». Europäische Verbündete erfuhren von den Militäraktionen aus der Presse statt über sichere Kanäle.
  • Grönland (August 2025): Dänischer Rundfunk DR berichtete, gestützt auf Geheimdienstquellen, dass mindestens drei Trump-nahe Personen verdeckte Einflussoperationen auf dänischem Territorium (Grönland) durchführten. Dänemarks Aussenminister bestellte den US-Botschafter ein. Dänemarks Premierminister formulierte öffentlich: «You cannot spy against an ally.»
  • Operation «Epic Fury» (Februar 2026): Die USA und Israel starteten eine Militäroperation gegen Iran, die zur Tötung des Obersten Führers führte und die gesamte Golfregion destabilisierte – ohne vorherige Information an NATO-Verbündete. Der Atlantic Council schreibt explizit: «Trump apparently caught NATO, Gulf, and Asian allies off guard, reportedly providing no advance warning.» Das ist keine Kommunikationspanne. Das ist eine strategische Entscheidung.

Diese drei Incidents sind keine Ausreisser. Sie sind das Muster einer Administration, die «Amerika First» konsequent umsetzt – rational aus US-Perspektive, herausfordernd aus europäischer. Was sie gemeinsam haben: Europa war in keinem dieser Fälle eine gleichwertige strategische Variable in der US-Kalkulation.

5.4 Europas Cybersicherheit verlangt digitale Souveränität

Die Antwort auf diese Analyse ist weder Feindbildkonstruktion noch naiver Vertrauensverlust, sie ist strategische Mündigkeit. Europa sollte von der US-Allianz profitieren, wo sie Vorteile bietet – und gleichzeitig aufhören, US-Interessen mit europäischen Interessen gleichzusetzen.

Konkret bedeutet das für die Cybersicherheit: Europäische digitale Souveränität ist keine Anti-Amerika-Politik. Es ist die logische Konsequenz aus der Erkenntnis, dass Abhängigkeit von fremder Infrastruktur, ob chinesisch, russisch oder amerikanisch, ein Sicherheitsrisiko darstellt. Die EU hat mit dem Cloud Sovereignty Framework (Oktober 2025), dem Cyber Resilience Act und EuroStack erste Schritte in diese Richtung gemacht. Es ist nicht genug – aber es ist die richtige Richtung.

Einschätzung Q2/2026

Jeder Staat handelt im eigenen Interesse. Das ist keine Kritik. Es ist die Grundregel, nach der jede Sicherheitsstrategie gebaut sein sollte. Für europäische Organisationen bedeutet das praktisch: US-Technologie dort einsetzen, wo sie die beste Lösung ist – aber mit dem Wissen um den rechtlichen Rahmen (CLOUD Act, FISA) und mit Architekturentscheidungen, die kritische Daten und Systemzugänge unter europäischer Kontrolle halten.

6. Die Detektionslücke bleibt – das Expositionsdefizit wächst

Die Kernerkenntnis aus unserem Q1-Report hat sich deutlich verschärft: 57 % aller Kompromittierungen werden nicht durch eigene Sicherheitssysteme entdeckt, sondern durch externe Hinweise. Die mediane Verweildauer eines Angreifers in europäischen Netzwerken liegt bei 22 Tagen (EMEA-Median, Mandiant M-Trends 2025).

Im Q2/2026 verschärft sich vor allem die Detektionsfrage: LOTL-Angriffe (Living-off-the-Land) waren bereits für signaturbasierte Systeme unsichtbar. Autonome KI-Angriffe ohne festes Timing, ohne menschliches Verhaltensmuster und ohne statische Infrastruktur stellen auch verhaltensbasierte Anomalie-Detection vor neue Herausforderungen. RedKittens Dead-Drop-Resolver-Architektur, die vollständig über legitime Cloud-APIs kommuniziert, zeigt, wohin die Entwicklung geht: Angriffs-Traffic, der von normalem SaaS-Traffic nicht mehr zu unterscheiden ist.

Zur Detektionslücke tritt die Risikoexposition in den Vordergrund: Exponierte Systeme, übersehene Abhängigkeiten, falsch priorisierte Schwachstellen und unzureichend überwachte Zugänge schaffen Bedingungen, in denen Angriffe leichter vorbereitet und verborgen werden können.

Genau dieses Muster bestätigt sich in der Incident-Response-Praxis: Staatliche Angreifer fallen selten durch Alarme auf, sondern durch externe Hinweise, Zufallsfunde oder ältere Zugangspfade, die erst bei einem anderen Vorfall sichtbar werden.

6.1 Proaktives Threat Hunting: Suchen, bevor ein Alarm entsteht

Proaktives Threat Hunting durch erfahrene Incident Responder ist in der aktuellen Bedrohungslage – Iran Phase 2, China in Nordeuropa, Russland destruktiv in Polen, autonome KI-Angriffe operativ – keine optionale Ergänzung zur bestehenden Sicherheitsarchitektur. Es setzt genau dort an, wo automatisierte Systeme an Grenzen stossen: bei Spuren, Hypothesen und Angriffsmustern, für die es noch keinen Alarm gibt.

Der Unterschied zu automatisierten Systemen liegt im Ansatz: Threat Hunter starten nicht mit einem Alarm. Sie starten mit einer Hypothese – basierend auf aktueller Threat Intelligence, dem Profil der Organisation und dem Wissen, wie staatliche Angreifer in vergleichbaren Umgebungen operieren. Sie suchen nicht nach bekannten Mustern. Sie suchen nach dem, was sichtbar sein müsste, wenn die aktuelle Bedrohungslage bereits in der eigenen Umgebung angekommen ist.

CISAs eigenes Threat-Hunting-Team hat gezeigt, was das bedeutet: Es hat Volt Typhoon in US-Infrastruktur gefunden – in Umgebungen, in denen alle anderen automatisierten Systeme versagt hatten. Nicht weil das Team bessere Tools hatte. Sondern weil erfahrene Incident Responder wissen, wo man sucht.

6.2 Compromise Assessment: Kompromittierung und Exponierung erkennen

Für Organisationen, die noch kein regelmässiges Threat Hunting betreiben, kann ein Compromise Assessment eine sinnvolle Standortbestimmung sein: eine forensische Überprüfung, ob bereits Hinweise auf eine Kompromittierung vorliegen – methodisch, mit aktuellem Wissen über die Taktiken der relevanten Bedrohungsakteure.

Als Momentaufnahme reicht das jedoch nur begrenzt. Wer die aktuelle Bedrohungslage ernst nimmt, betrachtet Kompromittierung und Exponierung gemeinsam: Gibt es Anzeichen für laufende oder frühere Angriffe? Und welche Angriffsflächen erhöhen das Risiko, dass daraus der nächste Vorfall entsteht?

Angesichts der Lage im Q2/2026 – Iran Phase 2 online, China in Nordeuropa bestätigt, Russland destruktiv aktiv, autonome KI-Angriffe operativ – geht es nicht um Aktionismus, sondern um belastbare Entscheidungsgrundlagen. Je später Organisationen Klarheit über Kompromittierung und Risikoexposition gewinnen, desto stärker hängen sie von externen Hinweisen, Zufallsfunden oder dem nächsten Vorfall ab.

Fazit: Cyberresilienz braucht Detektion und Risikoklarheit

Q2/2026 ist kein Fortsetzungsartikel. Es ist eine Zuspitzung. Iran ist nach 47 Tagen wieder online und wechselt von Hacktivismus zu koordinierten APT-Operationen mit neuen OT-Zielen. China hat Skandinavien erreicht. Russland hat in Polen erstmals Industrieanlagen dauerhaft zerstört, ohne eine NATO-Reaktion zu provozieren. Autonome KI-Angriffe sind operativ. Und der Blick auf die eigene Allianz zeigt: Strategische Eigenständigkeit ist keine Isolation – es ist die notwendige Konsequenz aus der Erkenntnis, dass kein Verbündeter die eigenen Interessen über die eigenen stellt.

Für Organisationen folgt daraus: Proaktives Threat Hunting und die kontinuierliche Bewertung der Risikoexposition gehören zusammen. So entsteht kein Versprechen absoluter Sicherheit, sondern ein belastbarer Umgang mit einer Angriffsfläche, die sich laufend verändert.

Ob bereits Spuren einer Kompromittierung bestehen und welche Angriffsflächen das reale Risiko erhöhen, lässt sich nur beantworten, wenn Threat Hunting und Managed Risk Exposure zusammengedacht werden. Die Erkenntnisse aus Threat Hunting, Incident Response und Threat Intelligence der letzten Monate liefern dafür eine fachliche Grundlage.

Am Anfang einer Caberrisikoanalyse steht eine nüchterne Standortbestimmung: Was ist kompromittiert, was ist exponiert – und was muss zuerst reduziert werden? Nutzen Sie das Whitepaper «InfoGuard Threat Intelligence Insights 2025» als Realitätscheck: Erfahren Sie, welche Angriffsmuster jetzt besonders relevant sind und welche Schritte für Ihre Organisation jetzt Priorität haben.

Firmenkontakt und Herausgeber der Meldung:

InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch

Ansprechpartner:
Estelle Ouhassi
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

Kürzere TLS-Zyklen: Automatisiertes Zertifikatsmanagement wird Pflicht

Kürzere TLS-Zyklen: Automatisiertes Zertifikatsmanagement wird Pflicht

Digitale Zertifikate bilden das Rückgrat einer sicheren digitalen Infrastruktur. Sie verifizieren die Authentizität von Geräten, Websites und Organisationen und ermöglichen so erst sichere Verbindungen in unserer vernetzten Welt. Neue Vorgaben des CA/Browser Forums verkürzen die Gültigkeit von TLS-Zertifikaten nun drastisch. Für Unternehmen bedeutet das: mehr Komplexität, wachsende Cyberrisiken und Handlungsdruck. Der Beitrag zeigt, was dieser Paradigmenwechsel für das Zertifikatsmanagement bedeutet, welche Fristen künftig gelten und wie sich diese praxisnah einordnen lassen.

Das Ende langer TLS-Zertifikatslaufzeiten

Bisher waren TLS-Zertifikate (Transport Layer Security) oft über ein Jahr gültig. Das gab IT-Teams ausreichend Zeit für manuelle Erneuerungsprozesse. Doch nun geht diese Ära ihrem Ende entgegen. Das CA/Browser-Forum (CA/B), das Gremium, das die globalen Standards für Zertifikate festlegt, hat offiziell dafür gestimmt, die Gültigkeitsdauer von TLS-Zertifikaten schrittweise drastisch zu verkürzen.

Der Zeitplan für diese Umstellung ist bereits fixiert:

  • Bis März 2026: Die maximale Laufzeit beträgt noch 398 Tage.
  • Ab März 2026: Reduzierung auf 200 Tage.
  • Ab März 2027: Reduzierung auf 100 Tage.
  • Ab März 2029: Die maximale Laufzeit wird nur noch 47 Tage betragen.

Warum kürzere TLS-Laufzeiten notwendig sind

Die drastische Verkürzung der Zertifikatslaufzeiten adressiert ein reales und wachsendes Problem. Denn viele Unternehmen haben heute nur begrenzte Transparenz über ihre Fare-Zertifikatslandschaft und reagieren oft erst, wenn ein Zertifikat abläuft oder ein Vorfall eintritt. In komplexen IT-Umgebungen mit hunderten oder tausenden Zertifikaten führt dies regelmässig zu Ausfällen, Sicherheitslücken oder Compliance-Problemen.

Je länger ein Zertifikat gültig ist, desto grösser ist das Risiko, dass kompromittierte oder veraltete kryptographische Verfahren unbemerkt im Einsatz bleiben. Gleichzeitig nimmt die Geschwindigkeit, mit der neue Bedrohungen und Anforderungen entstehen, stetig zu.

Genau hier setzt die Verkürzung der Laufzeiten an. Sie zwingt Unternehmen, ihre Prozesse zu modernisieren und von reaktiven, manuellen Ansätzen auf automatisierte und kontrollierte Abläufe umzustellen.

Kürzere Laufzeiten bringen damit klare Vorteile:

  • Erhöhte Sicherheit: Kompromittierte Zertifikate können deutlich kürzer missbraucht werden
  • Schnellere Reaktionsfähigkeit: Unternehmen müssen neue Standards und Algorithmen rascher umsetzen
  • Vorbereitung auf Post-Quantum-Kryptographie: Krypto-Agilität wird zur Pflicht

Gerade im Hinblick auf zukünftige Bedrohungen durch Quantencomputing wird es entscheidend, kryptographische Verfahren schnell austauschen zu können.

Certificate Lifecycle Management (CLM): Automation ist Pflicht

Für Unternehmen bedeutet dies einen deutlich steigenden Administrationsaufwand. Wenn ein Zertifikat nur noch 47 Tage gültig ist, muss der Erneuerungsprozess faktisch alle paar Wochen fehlerfrei durchlaufen werden. Eine manuelle Verwaltung, die bei hunderten oder gar tausenden Zertifikaten bereits heute fehleranfällig ist, wird bei diesem Tempo zu einem erhöhten Risiko für Ausfälle.

Ungeplante Zertifikatsabläufe führen zu:

  • Service-Downtimes: Websites und Anwendungen sind nicht mehr erreichbar.
  • Sicherheitslücken: Ungeschützte Datenübertragungen und Compliance-Verstösse.
  • Überlastung der IT-Teams: Mitarbeitende werden durch repetitive Routineaufgaben von strategischen Projekten abgezogen.

Kurz gesagt: Ohne Automatisierung wird Zertifikatsmanagement zum Betriebsrisiko.

DigiCert als Leader im Zertifikatsmanagement

Moderne Lösungen für Certificate Lifecycle Management (CLM) setzen genau hier an. Um der Herausforderung immer kürzerer Zertifikatslaufzeiten effektiv zu begegnen, setzen wir auf unseren Partner DigiCert.

DigiCert ist ein weltweit führender Anbieter für Digital Trust und sichert Menschen, Daten und Geräte mit KI-gestützten Lösungen, um Bedrohungen zu stoppen und eine quantensichere Zukunft zu ermöglichen. Mehr als 100’000 Organisationen, darunter 90 % der Fortune 500, vertrauen auf DigiCert, um ihre digitale Infrastruktur zu sichern und sich auf zukünftige Bedrohungen vorzubereiten.

Warum DigiCert?

  • Vollständige Transparenz: Zentrale Übersicht über alle Zertifikate durch CA-agnostische Discovery, kontinuierliches Monitoring sowie Alerts in Echtzeit – für volle Kontrolle über die gesamte Zertifikatslandschaft.
  • Automatisierung: End-to-End-Automatisierung des gesamten Zertifikatslebenszyklus – reduziert Fehler und verhindert Ausfälle.
  • Skalierbarkeit: Nahtlose Integration in Multi-Cloud- und Hybrid-Umgebungen sowie bestehende IT- und DevOps-Prozesse.
  • Sicherheit & Kontrolle: Durchsetzung von Richtlinien, klare Auditierbarkeit und frühzeitige Erkennung von Risiken.
  • Zukunftssicherheit: PQC-Ready (Post-Quantum-Kryptographie) und flexibel anpassbar an neue Standards und Anforderungen. 

Praxisbeispiel – Zertifikatsmanagement auf Knopfdruck

Wie gross der Effekt der Automatisierung sein kann, zeigt ein Praxisbeispiel von DigiCert aus dem Schweizer Healthcare-Bereich. In einer komplexen Infrastruktur mit über 10’000 Zertifikaten war das Zertifikatsmanagement früher stark manuell geprägt. Heute wird die gesamte Umgebung von nur einer Person überwacht.

Dort, wo früher manuell eingegriffen werden musste, nutzt das Unternehmen heute die DigiCert-API.

  • Über 450 interne Anwendungs-Endpunkte wurden erfolgreich für die automatische Registrierung (Auto-Enrollment) konfiguriert.
  • Auch für interne Webserver läuft der Prozess nun vollautomatisch ab.
  • Das Beste daran: Für die Server-Administratoren war keine Schulung erforderlich, da die bestehenden Workflows im Hintergrund effizienter wurden.

Durch den Wechsel auf die containerisierte DigiCert ONE-Plattform ist das Unternehmen nicht nur bereit für die Cloud (Azure-Migration), sondern auch für die kommende Ära der Post-Quantum-Kryptographie (PQC). Die Plattform ermöglicht es, schnell auf neue kryptographische Standards zu reagieren, ohne die gesamte Infrastruktur umbauen zu müssen.

InfoGuard & DigiCert – eine Partnerschaft für Ihr CLM

Mit DigiCert setzt InfoGuard auf einen der weltweit führenden Anbieter im Bereich Digital Trust. Im aktuellen IDC MarketScape «Worldwide Certificate Lifecycle Management Software 2026 Vendor Assessment» wurde DigiCert erneut als Leader positioniert.

Unsere Expert:innen unterstützten Sie gemeinsam mit DigiCert dabei, Ihr Zertifikatsmanagement nachhaltig zu transformieren.

Ihre Vorteile:

  • Analyse bestehender Zertifikate und Prozesse
  • Einführung automatisierter CLM-Lösungen
  • Integration in bestehende IT- und Security-Architekturen
  • Vorbereitung auf zukünftige Anforderungen wie PQC

So schaffen Sie die Grundlage für eine Zertifikatsinfrastruktur, die nicht nur heute zuverlässig funktioniert, sondern auch langfristig sicher, skalierbar und effizient betrieben werden kann.

Erfahren Sie mehr über den Trust Lifecycle Manager von DigiCert oder sprechen Sie mit unseren Expert:innen über Ihre CLM-Strategie.

Mehr zum automatisierten CLM

Autor: Natacha Suter

Firmenkontakt und Herausgeber der Meldung:

InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch

Ansprechpartner:
Estelle Ouhassi
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

Cyber Threat Intelligence: Risikoexpositionen erkennen, bevor Angreifer es tun

Cyber Threat Intelligence: Risikoexpositionen erkennen, bevor Angreifer es tun

Die Cyber Defence ist ausgebaut, das Budget investiert – und trotzdem bleiben viele Organisationen an entscheidenden Stellen blind. Einfallstore sind kompromittierte Identitäten, exponierte Services, Fehlkonfigurationen oder Assets, die niemand auf dem Radar hatte. Was fehlt, ist Klarheit: Was ist erreichbar, was kritisch und was muss zuerst behoben werden? Wer seine Angriffsflächen 2026 sichtbar macht, kann Cyberrisiken richtig einordnen und daraus Massnahmen ableiten, die Cyberresilienz wirksam stärken.

Rein hypothetisch: Wo würden Sie als Cyberkriminelle:r Ihren Angriff starten? Mit Sicherheit dort, wo der Aufwand klein und die Wirkung gross ist. Die meisten Angriffe entstehen nicht aus hochspezialisierten Einzeloperationen, sondern aus Opportunitäten. Cyberkriminelle suchen skalierbare Eintrittspunkte, automatisieren die Suche und verwerten erfolgreiche Zugänge weiter. So wird ein kompromittierter Unternehmenszugang zum verwertbaren Einstiegspunkt.

Angriffsflächen 2025 in Zahlen: von Phishing bis zur Supply ChainPhishing ungeschlagen: 43 % aller Angriffe beginnen hier

Cyberkriminelle versuchen durch kompromittierte E-Mail-Accounts, weitere Benutzer:innen zu phishen. Mit LLMs lassen sich Phishing-Szenarien mit geringem Aufwand skalieren. So sind die meisten Phishingangriffe weniger gezielt als opportunistisch: Entscheidend ist die Quantität der versendeten E-Mails.

25 % schlecht geschützte Remote Services

Angreifer testen exponierte Login Prompts systematisch mit Brute Force oder Password Spraying. Dabei nutzen sie bekannte Benutzername-Passwort-Kombinationen, geleakte Passwörter, typische Varianten und erkennbare Muster in der Passwortwahl von Mitarbeitenden. Entsprechend zählen Brute Force und Password Spraying zu den häufigen Angriffsvektoren, die 2025 im InfoGuard Security Operations Center (SOC) als True Positive erkannt wurden.

20 % exponierte Schwachstellen: Patchfenster schrumpfen weiter!

Gemäss Zerodayclock werden Schwachstellen 2026 im Schnitt bereits nach 2,1 Tagen ausgenutzt gegenüber 21,5 Tagen im Vorjahr. Diese Beschleunigung setzt klassische Patchprozesse massiv unter Druck. Ein wesentlicher Treiber sind KI-Tools, die sowohl die Erkennung von Schwachstellen als auch die Entwicklung von Exploits erleichtern.

12 % Supply Chain: Wenn Vertrauen zur Angriffsfläche wird

Partner und Lieferanten stellen Software, Services und Hardware bereit, warten Systeme über Remotezugänge oder unterstützen geschäftskritische Prozesse. Genau dadurch wird die eigene Sicherheit zunehmend von der Sicherheit Dritter abhängig. Supply-Chain-Risiken entstehen dort, wo Vertrauen, technische Abhängigkeiten und externe Zugriffe zusammenkommen.

Krimineller Markt: Wenn Unternehmenszugänge handelbar werden

Die häufigsten Eintrittspunkte zeigen: Der erste Zugriff auf eine Unternehmensumgebung ist längst nicht mehr nur ein technisches Problem, sondern Teil eines kriminellen Markts. Initial Access Broker beschaffen, prüfen und verkaufen solche Zugänge weiter. Was früher der Auftakt eines einzelnen Cyberangriffs war, ist heute Teil der cyberkriminellen Wertschöpfungskette.

Dabei zählt Skalierbarkeit. Cyberkriminelle sammeln möglichst viele Zugänge, bewerten deren Schadenpotenzial und verkaufen besonders lohnende Einstiege weiter. Ein kompromittiertes VPN-Konto, ein gültiger Remote-Zugang, ein gekaperter Cloud-Account oder Zugriff auf ein internes System kann bereits genügen – etwa für Ransomware, Datendiebstahl, Erpressung oder Spionage.

Für Unternehmen bedeutet das: Der eigentliche Angriff beginnt oft lange bevor Ransomware ausgeführt oder Daten gestohlen werden – nämlich dann, wenn ein Zugang unbemerkt kompromittiert und in kriminellen Lieferketten weitergereicht wird.

«Gehandelt werden nicht blosse Logins, sondern Zugriffschancen und damit die Möglichkeit, ein Unternehmen für Erpressung, Betrug oder Spionage verwertbar zu machen.»

Gestohlene Zugangsdaten: Warum die Rolle über den Schaden entscheidet

Welche Zugänge abfliessen und wie sie missbraucht werden, hängt vom Kompromittierungsweg und der betroffenen Rolle ab.

Die folgenden Beispiele zeigen, wie unterschiedlich das Schadenspotenzial je nach Funktion ausfällt:

Mitarbeitende

  • E-Mail-Konten: Business E-Mail Compromise, internes Phishing, Zugriff auf vertrauliche Kommunikation, Passwort-Resets
  • M365/Google Workspace Account: SharePoint, OneDrive, Teams/Chat, Kalender, interne Dokumente
  • Session Cookies und Browser Tokens: Zugriff ohne Passwort ohne erneute MFA-Abfrage
  • VPN-Konten: Einstieg ins interne Netzwerk
  • Passwort-Manager-Inhalt: Zugriff auf weitere interne und externe Dienste

Vertrieb/Verkauf

  • CRM-Zugänge: Kundendaten, Pipeline, Verträge, Kontaktlisten
  • E-Mail-Konten: Rechnungsbetrug
  • Signierungs-Lösungen: Manipulation oder Missbrauch von Vertragsprozessen
  • Kundenportal-Zugang: Kundendaten, Servicefälle, Bestellungen

Helpdesk/IT-Support

  • Helpdesk-Accounts: Passwort-Resets, Account-Recovery, Benutzerinformationen
  • Ticketing-System: interne Probleme, Systemnamen, laufende Projekte
  • Remote-Support-Zugänge: Direkt-Zugriff auf Endgeräte und Server
  • MDM- und Endpoint-Management-Zugänge: Geräteverwaltung, Softwareverteilung, Policy-Änderungen
  • MFA-Reset oder MFA-Registrierungsrechte: Übernahme fremder Accounts

Engineering / IT-Betrieb

  • VPN- und Jumphost-Zugänge: Zugriff auf interne Administrationszonen
  • SSH-Keys: Zugriff auf Linux-Server, Netzwerkgeräte, Appliances
  • Domänen-Admin: Vollständige Kompromittierung der Windows-Umgebung
  • Cloud-Admin-Zugänge: Zugriffe auf virtuelle Geräte, Storage, IAM, Datenbanken, Backup
  • Kubernetes-Admin-Zugänge: Zugriff auf Cluster, Secrets, Workloads, Container

Softwareentwicklung / DevOps

  • GitHub-/GitLab-/Bitbucket-Zugänge: Quellcode-Diebstahl, Suche nach Secrets, Codemanipulation
  • CI/CD-Secrets: Manipulation von Builds und Deployments
  • Deployment Tokens: Veröffentlichung manipulierte Software in Produktion
  • Container-Registry-Zugänge: Einschleusen bösartiger Images
  • Package-Registry-Zugänge: Supply-Chain Angriffe über manipulierte Pakete
  • Signing-Zertifikate: Signieren manipulierte Software
  • Secrets auf lokalen Entwicklermaschinen: Seiteneinstieg in Build-, Test-, Produktionsumgebungen
  • Webhook-Secrets: Manipulation von Integrationen und Automationen

Identitäten härten und überwachen: 7 Massnahmen gegen kompromittierte Identitäten

Identitäten gehören heute zu den wichtigsten Angriffszielen. Oft brauchen Angreifer keine Malware und keine komplexe Schwachstelle. Ein gültiges Passwort, ein gestohlener Session-Cookie oder ein manipulierter MFA-Prozess genügt. Identitätsschutz muss deshalb als eigene Sicherheitsdisziplin verstanden werden, nicht als reine IT-Administrationsaufgabe.

Folgende sieben Massnahmen zeigen, wie Organisationen Identitäten, Zugriffe und Sessions wirksam absichern:

  1. Benutzerkonten mit phishing-resistenter MFA absichern 
    Alle Benutzerkonten brauchen starke Authentifizierung. MFA ist Pflicht, aber nicht jede MFA ist phishing-resistent: SMS-Codes und einfache Push-Bestätigungen lassen sich umgehen. Wirksamer sind FIDO2 Security Keys, Passkeys oder zertifikatsbasierte Verfahren – besonders für privilegierte Konten, Helpdesk-Rollen sowie Zugriffe auf Cloud-, VPN- und Remote-Access-Systeme.
  2. Anmeldungen mit Conditional Access bewerten 
    Conditional Access bewertet nicht nur Benutzername, Passwort und MFA, sondern auch den Kontext der Anmeldung: Gerät, Standort, Browser, Zugriffsmuster und Sensibilität der Daten. So lassen sich riskante Logins blockieren, zusätzliche Prüfungen erzwingen oder Zugriffe auf vertrauenswürdige Geräte beschränken.
  3. Privilegierte Identitäten streng kontrollieren 
    Admin-Konten brauchen getrennte Zugänge, starke MFA, «Just-in-Time»-Zugriff, rollenbasierte Berechtigungen und lückenloses Logging. Dauerhaft aktive Global-Admin-, Domain-Admin- oder Cloud-Admin-Rechte erhöhen das Risiko unnötig. Privilegien sollten nur bei Bedarf vergeben und danach automatisch wieder entzogen werden.
  4. Passwörter nicht unterschätzen
    Passwörter bleiben relevant, besonders ohne phishing-resistente Authentifizierung. Entscheidend sind starke Passwörter oder Passphrases, keine Wiederverwendung, keine geleakten oder Standard-Passwörter und keine gemeinsam genutzten Konten. Passwortmanager helfen bei der sicheren Verwaltung; langfristig sollten passwortlose Verfahren zum Zielbild werden.
  5. Session-Schutz: MFA endet nicht nach dem Login 
    Angreifer stehlen zunehmend Browser-Cookies und Tokens, um MFA zu umgehen. Deshalb sollten Unternehmen riskante Sessions erkennen, Token-Lebenszeiten begrenzen, Re-Authentication bei sensiblen Aktionen verlangen und Zugriffe von nicht verwalteten Geräten einschränken. Der Schutz endet nicht nach dem Login
  6. Helpdesk-Prozesse absichern
    Cyberkriminelle umgehen technische Schutzmassnahmen oft über den Support, etwa durch manipulierte MFA-Resets, neue Geräte-Registrierungen oder Passwortänderungen. Helpdesk-Prozesse brauchen deshalb klare Identitätsprüfungen, Vier-Augen-Prinzipien und Alarme bei sensiblen Änderungen. Ein schwach abgesicherter Helpdesk kann selbst starke MFA aushebeln.
  7. Identity Use Cases für Monitoring und Detection definieren
    Logs allein reichen nicht. Entscheidend sind konkrete Identity-Use-Cases für Monitoring und Detection: unmögliche Reisebewegungen, ungewöhnliche Herkunftsländer, gehäufte Login-Fehler, unübliche MFA-Registrierungen, neue Geräte, verdächtige OAuth-Freigaben, Passwort-Reset-Anomalien, privilegierte Rollenänderungen oder massenhafte Dateizugriffe. Identitäten müssen geschützt und laufend überwacht werden.

«Nicht jede Anmeldung ist vertrauenswürdig, nur weil das Passwort stimmt.»

Eine starke Identity-Sicherheitsstrategie wirkt erst im Zusammenspiel: robuste Authentifizierung, kontextbasierte Zugriffe, minimale Rechte, sichere Admin-Prozesse, Session-Schutz, laufendes Monitoring und schnelle Reaktion bei verdächtigen Anmeldungen.

Wie stark Identitäten 2025 ins Zentrum realer Cybervorfälle gerückt sind, zeigt das Whitepaper «InfoGuard Threat Intelligence Insights 2025». Es ordnet aktuelle Angriffsmuster ein und zeigt, welche Massnahmen Organisationen priorisieren sollten, um Account Takeover früher zu erkennen und gezielter zu verhindern.

Whitepaper jetzt downloaden

Endpunkte und Server überwachen: Angriffe erkennen, bevor sie eskalieren

Auch starke Identity Security schliesst nicht jede Lücke. Angreifer können über Schwachstellen, gestohlene Sessions, kompromittierte Lieferanten oder bereits vorhandene Zugänge in eine Umgebung gelangen. Ab diesem Moment entscheidet Sichtbarkeit darüber, ob ein Angriff früh erkannt wird oder ob sich Angreifer ungestört weiterbewegen.

EDR-Abdeckung: Sensorik auf den entscheidenden Systemen

Systeme mit Zugriff auf Unternehmensdaten oder interne Infrastrukturen brauchen eine möglichst vollständige EDR-Abdeckung: Arbeitsplätze, Notebooks, Server, virtuelle Maschinen, Terminalserver, Admin-Systeme und kritische Applikationsserver. Besonders wichtig sind Systeme, auf denen privilegierte Benutzer:innen arbeiten oder über die auf geschäftskritische Daten zugegriffen wird.

EDR ist dabei nicht einfach ein weiteres Tool, sondern die Sensorik auf dem System selbst. Sie erkennt verdächtige Prozessketten, ungewöhnliche Skriptausführung, Credential Dumping, laterale Bewegung, Ransomware-Verhalten oder Manipulationen an Sicherheitstools. Ohne diese Sichtbarkeit erkennt ein Unternehmen oft nur noch die Folgen – nicht aber den eigentlichen Ablauf des Angriffs.

Wenn EDR nicht möglich ist: Sichtbarkeit anders herstellen

Nicht jedes System lässt sich mit einem EDR-Agenten ausstatten. Legacy-Systeme, Produktionsanlagen, Appliances, Netzwerkgeräte, Mainframes, OT-Systeme oder hochkritische Plattformen mit Stabilitätsanforderungen brauchen kompensierende Kontrollen. Wo EDR nicht möglich ist, müssen mindestens administrative Zugriffe kontrolliert, protokolliert und überwacht werden – etwa über gehärtete Jump Hosts oder Admin Workstations mit EDR-Abdeckung.

Zusätzlich braucht es Netzwerksichtbarkeit durch Network Detection and Response (NDR) sowie zentrale Logs im SIEM. NDR hilft, laterale Bewegung, ungewöhnliche Verbindungen, Command-and-Control-Kommunikation, Scans oder Datenabfluss zu erkennen. Gerade dort, wo kein Endpoint-Agent installiert werden kann.

Kritische Server: Keine blinden Flecken in der Eskalationszone

Besonders kritisch ist die Überwachung von Servern mit hoher Bedeutung. Domain Controller, Identity-Systeme, Backup-Server, Virtualisierungsplattformen, File Server, Datenbanken, Applikationsserver, CI/CD-Systeme, Management-Server, EDR-/SIEM-Komponenten und Cloud Connectoren. Wer nur Benutzer-Endgeräte überwacht, aber Server, Linux-Systeme, virtuelle Umgebungen oder Admin-Infrastruktur vernachlässigt, erkennt möglicherweise den Einstieg –verpasst aber die Eskalation.

Der entscheidende Punkt: Jede Ausnahme braucht Transparenz. Unternehmen müssen wissen, welche Systeme existieren, welche davon EDR haben, welche Ausnahmen bestehen und welche kompensierenden Kontrollen greifen. «Fast überall» reicht nicht, wenn ausgerechnet kritische Systeme blind bleiben.

Managed Risk Exposure: Welche Risiken zuerst reduziert werden müssen

Neben Identitätsschutz sowie Endpunkt- und Server-Monitoring braucht es eine dritte zentrale Fähigkeit, die eigene Angriffsfläche kontinuierlich zu prüfen. Denn viele Angriffe beginnen nicht mit hochkomplexen Exploits, sondern damit, was nach aussen sichtbar, falsch konfiguriert, vergessen oder nicht sauber verantwortet ist.

Dazu gehören unmanaged Assets, exponierte Systeme, Shadow IT, Fehlkonfigurationen, ungepatchte Schwachstellen und technische Angriffspfade, die Angreifer schneller finden als die eigene Organisation. Genau hier entsteht ein gefährlicher blinder Fleck: Organisationen schützen häufig, was sie kennen – kompromittiert werden sie über das, was niemand mehr auf dem Radar hatte.

Von Schwachstellenlisten zu echten Cyberrisiken

Managed Risk Exposure erweitert klassisches Vulnerability Management um den entscheidenden Kontext: Es geht nicht nur darum, CVEs zu scannen und Tickets zu erstellen. Entscheidend ist die tatsächliche Angriffsfläche: Welche Systeme sind von aussen erreichbar? Welche Identitäten haben kritische Rechte? Welche Cloud-Ressourcen sind falsch konfiguriert? Welche Lieferanten- oder Remote-Zugänge existieren? Welche Schwachstellen lassen sich realistisch zu einem Angriffspfad kombinieren?

Der wichtigste Punkt: Nicht alles kann gleichzeitig behoben werden. Deshalb braucht es risikobasierte Priorisierung. Eine kritische Schwachstelle auf einem isolierten Testsystem ist nicht automatisch wichtiger als eine mittlere Schwachstelle auf einem exponierten System mit Zugriff auf produktive Daten. Entscheidend sind Erreichbarkeit, Kritikalität, vorhandene Kontrollen, mögliche Auswirkungen und Wahrscheinlichkeit zur Ausnutzung.

Identifizierte Risiken sollten deshalb laufend priorisiert werden. Diese Liste ist kein statisches Reporting-Artefakt, sondern ein operatives Steuerungsinstrument. Sie zeigt, welche Risiken mit den verfügbaren Ressourcen zuerst reduziert werden müssen und welche Massnahmen den grössten Sicherheitsgewinn bringen.

Die typischen Bereiche sind:

  • Unmanaged Assets: Systeme ohne Besitzer, EDR, Patch-Prozess oder Inventarisierung
  • Exposed Assets: Internet-erreichbare Server, VPN-Portale, Remote-Zugänge, Admin-Oberflächen, Cloud-Dienste
  • Shadow IT: Nicht freigegebene SaaS-Dienste, private Cloud-Ressourcen, vergessene Subdomains, inoffizielle Tools
  • Fehlkonfigurationen: Offene Storage Buckets, zu breite Firewall-Regeln, schwache IAM-Rollen, unsichere Standardkonfigurationen
  • Schwachstellen: Ungepatchte Systeme, veraltete Software, bekannte Exploit-Pfade, fehlende Härtung
  • Angriffspfade: Kombinationen aus Exponierung, Identitäten, Berechtigungen, Netzwerkzugriff und Schwachstellen

Findings übersetzen: Was technisch auffällt, muss geschäftlich relevant sein

Besonders wertvoll wird dieser Ansatz, wenn technische Findings nicht isoliert betrachtet werden. Ein offener Port ist noch kein Risiko in verständlicher Sprache. Ein exponiertes Admin-Interface ohne MFA auf einem geschäftskritischen System dagegen schon. Genau diese Übersetzung ist entscheidend: Aus technischen Findings werden priorisierte Risiken, die Management und Technik gemeinsam verstehen und bearbeiten können.

Cyberresilienz beginnt mit einem realistischen Lagebild

Ein jährlicher Blick auf die Angriffsfläche reicht nicht. Neue Systeme, Cloud-Projekte, Lieferanten, Software-Releases, Berechtigungen, Akquisitionen oder Schatten-IT verändern die Sicherheitslage laufend. Wer seine Angriffsfläche nur einmal jährlich prüft, ist praktisch immer zu spät. Entscheidend ist ein wiederkehrender Prozess: Risiken identifizieren, bewerten, priorisieren, Massnahmen umsetzen und deren Wirkung überprüfen.

Das InfoGuard Whitepaper «Threat Intelligence Insights 2025» vertieft diese Perspektive auf Basis von über 350 realen Cybervorfällen, die wir im Jahr 2025 bearbeitet haben. Es zeigt, welche Angriffspfade besonders relevant sind, warum Identitäten, Sichtbarkeit und Reaktionsfähigkeit 2026 weiter an Bedeutung gewinnen. Im Mittelpunkt stehen konkrete Erkenntnisse aus realen Angriffsmustern. So entsteht ein Lagebild, das nicht bei der Analyse stehen bleibt, sondern hilft, Monitoring gezielt auszubauen, Prozesse zu testen und Entscheidungen fundierter zu treffen.

Nutzen Sie das 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.

Whitepaper jetzt downloaden

Ein Angriff. Ein blinder Fleck. Eine Chance, das zu ändern.

Sandro Bachmann, Principal Threat Intelligence Analyst, weiss aus täglicher Praxis: Ein Angriff läuft selten so ab, wie man ihn erwartet.

Im «Cyber Threat Intelligence Webinar» vom 27. Mai 2026 zeigt er, wie moderne Bedrohungen wirklich funktionieren und woran Organisationen Risikoexpositionen frühzeitig erkennen. 

  • Wann: Mittwoch, 27. Mai 2026 | 10.00 – 10.45 Uhr
  • Wo: virtuell

Sind Sie dabei? Einfach anmelden und teilnehmen. Wir freuen uns auf Sie!

Anmelden und teilnehmen

Firmenkontakt und Herausgeber der Meldung:

InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch

Ansprechpartner:
Estelle Ouhassi
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

Anthropic’s «Claude Mythos»: Was CISOs jetzt im Threat Model anpassen

Anthropic’s «Claude Mythos»: Was CISOs jetzt im Threat Model anpassen

Mit «Claude Mythos» hat Anthropic ein KI-Modell vorgestellt, das das Unternehmen selbst als zu gefährlich für eine öffentliche Freigabe einstuft – und bereits Behörden und Unternehmen alarmiert. KI-gestützte Cyberangriffe werden damit schneller, skalierbarer und breiter nutzbar. Für CISOs entsteht unmittelbarer Handlungsbedarf: Das eigene Threat Model muss überprüft und gezielt angepasst werden. Dieser Beitrag ordnet die Entwicklung datenbasiert ein – jenseits von Hype und Verharmlosung – und zeigt mit einem konkreten 90-/180-/365-Tage-Playbook, worauf es jetzt ankommt.

Am 7. April 2026 kündigte Anthropic mit «Claude Mythos Preview» ein neues KI-Modell an. Parallel dazu entstand mit Project Glasswing ein exklusives Konsortium ausgewählter Technologie- und Infrastrukturanbieter mit Zugang für defensive Sicherheitsarbeit. Während US-Finanzminister und Fed-Chef intern gebrieft wurden, äusserte der IWF öffentlich Zweifel an der Verteidigungsfähigkeit des globalen Finanzsystems. Auch deutsche Banken suchten umgehend den Schulterschluss mit ihren Aufsichtsbehörden.

Die Reaktionen in der Security-Community reichen seither von «AGI ist da» bis «reines PR-Theater». Für CISOs taugt beides nicht: Wer in Panik verfällt, trifft teure Fehlentscheidungen. Wer abwinkt, verpasst einen realen Shift im Threat Model.

Was «Claude Mythos» ist – und was es nicht

Die Ankündigung liest sich zunächst wie ein Paradigmenwechsel: «Claude Mythos» soll eigenständig tausende Zero-Day-Schwachstellen in grossen Betriebssystemen und Browsern identifiziert haben – darunter ein 27 Jahre alter Bug in OpenBSD, einem der sichersten Systeme der Branche. 99 % dieser Schwachstellen waren zum Zeitpunkt der Veröffentlichung ungepatcht. Das UK AI Security Institute (AISI) bestätigte zudem eine Erfolgsrate von 73 % bei Expert-Level-Hacking-Aufgaben. Gleichzeitig ist Mythos das erste Modell, dessen Veröffentlichung primär aus Cybersecurity-Gründen zurückgehalten wird.

Das ist jedoch erst eine Hälfte der Geschichte. So geht die Geschichte weiter:

AISI weist selbst darauf hin, dass Mythos in den Testszenarien gegen nahezu nicht vorhandene Verteidigungsebenen antrat. Der Vergleich eines AISI-Gutachters ist entsprechend pointiert: ein Stürmer gegen den schlechtesten Torhüter der Welt. Im produktiven Enterprise-Kontext sieht das Setup anders aus. Auch die auf KI-gestützte Schwachstellenforschung spezialisierte Organisation AISLE relativiert die öffentliche Erzählung: Sie hat die von Anthropic veröffentlichten Mythos-Findings gegen kleine, günstige Open-Weight-Modelle gegengeprüft. Acht von acht getesteten Modellen entdeckten den FreeBSD-Flagship-Exploit, den Anthropic als Beleg für die Überlegenheit von Mythos präsentierte. Eines dieser Modelle verfügt über 3,6 Mrd. aktive Parameter und kostet rund 0,11 USD pro Million Tokens.

Auch aus der Forschung kommt Einordnung. Peter Swire, Professor an der Georgia Tech und früherer Berater der Clinton- und Obama-Administrationen, beschreibt den Release nach Gesprächen mit akademischen Kolleg:innen nicht als Zäsur, sondern als Fortsetzung eines erwartbaren Trends. Zugleich weist er darauf hin, dass auch CISOs und Security-Vendors einen rationalen Anreiz haben, die Tragweite neuer Capabilities zu überzeichnen – nicht zuletzt zur Rechtfertigung eigener Budgets.

Die nüchterne Zusammenfassung lautet deshalb: Mythos ist leistungsfähig und eine ernstzunehmende Capability. Für ein verändertes Threat Model ist aber nicht die reine Fähigkeit entscheidend – die gab es in Teilen bereits. Relevant ist die Kombination aus Zugänglichkeit, Geschwindigkeit, Skalierung und der parallel laufenden Demokratisierung vergleichbarer Fähigkeiten in Open-Weight-Modellen.

Das ist der Shift, über den wir reden müssen. Nicht: «KI kann jetzt hacken.» Sondern: KI-gestützte Offensiv-Capability nimmt Commodity-Trajectory an. 

Was sich am Threat Model real verändert: Diese Grundannahmen sind zu prüfen

Vier Dimensionen, in denen der CISO seine Grundannahmen prüfen sollte.

  1. Time-to-Exploit kollabiert
    Die klassische Annahme, dass zwischen Disclosure und weaponisiertem Exploit-Code Wochen bis Monate liegen, ist nicht mehr tragfähig. PwC formuliert es im jüngsten Threat-Report so: KI-gestützte Angreifer verkürzen Attack-Timelines und skalieren Operationen gleichzeitig. Für die Risk-Quantifizierung heisst das: Exposure-Fenster sind tendenziell kürzer als die Patch-Fenster der Hersteller.
  2. Low-Skill-Enablement
    Der gravierendste Effekt ist nicht, dass APT-Gruppen besser werden – die sind es ohnehin. Entscheidend ist vielmehr, dass mittelmässige Angreifer deutlich gefährlicher werden. Ein Ransomware-Affiliate ohne tiefe OS-Kenntnisse kann künftig strukturiert nach Exploit-Chains suchen, statt ausschliesslich auf gekaufte Exploits angewiesen zu sein. Das verschiebt die Verteilung der realen Bedrohung messbar nach oben – und zwar genau im Segment, das für mittelständische Unternehmen am häufigsten relevant ist.
  3. Skalierung und Breite
    Mythos hat im Test laut Anthropic tausende Findings parallel produziert. Selbst wenn nur ein Bruchteil davon in reale Exploits überführbar ist, verändert das die Annahmen über «gleichzeitig aktive Vulns». Klassisches Vulnerability-Management geht davon aus, dass man priorisieren kann, weil man weiss, welche Schwachstellen aktiv ausgenutzt werden. Signale wie CISA KEV und EPSS werden verrauschter (unzuverlässiger), je mehr parallel entdeckte Zero-Days in den Umlauf kommen.
  4. Asymmetrie in Glasswing
    Das Programm ist nicht neutral. Ausgewählte Unternehmen, darunter JPMorgan Chase, Goldman Sachs und einige Cloud-/OS-Vendor, bekommen Mythos-Zugang für defensive Zwecke. Der Rest der Wirtschaft bekommt ihn nicht. Gleichzeitig ist keineswegs garantiert, dass Angreifer kein vergleichbares Tooling beschaffen können; die AISLE-Findings zu Open-Weight-Modellen zeigen, dass Teile der Capability bereits ausserhalb kontrollierter Kanäle existieren. Für mittelständische und kleinere Unternehmen – den typischen Kunden eines europäischen IR-Teams – verschiebt sich die Asymmetrie zu Ungunsten der Verteidigung.

Mythos ist weder Revolution noch PR-Theater, sondern ein klares Signal: KI-gestützte Offensiv-Capabilities werden zur Commodity – und das bestehende Threat Model gehört jetzt geschärft. Entscheidend ist nicht ein neues Tool, sondern die ehrliche Überprüfung der eigenen Annahmen – im Betrieb, in der Priorisierung und im Austausch mit dem Vorstand.

Threat Modeling

Risk Quantification: Must-have-Anpassung im Threat-Modell

Wer mit FAIR, Cyber-Risk-Quantifizierung oder Heatmap-Ansätzen arbeitet, muss drei Parameter überarbeiten.

Probability of Successful Compromise pro Asset-Klasse. Die Prios auf ältere, wenig gepflegte Systeme (ICS/OT, Legacy-Web-Anwendungen, interne Java-Backends, Delphi-Tools aus den späten Neunzigern, vergessene VB6-Anwendungen) steigen überproportional. Ein 27-Jahre-Bug in OpenBSD ist kein Einzelfall, sondern ein Proof-of-Concept für das, was in jedem Enterprise-COBOL-Stack und jeder halb-vergessenen internen Anwendung latent schlummert. Legacy-Risiko, das drei Jahrzehnte unterhalb der Realisierungsschwelle lag, rückt in Reichweite plausibler Angreifer.

Time-to-Detect versus Time-to-Exploit. Viele Organisationen operieren mit MTTD-Werten von Tagen bis Wochen. Wenn Time-to-Exploit auf Stunden kollabiert, ist das Delta das eigentliche Risiko. Die Kennzahl, die ab sofort getrackt wird, ist nicht MTTD per se, sondern MTTD minus geschätzte TTE – negative Werte sind rote Flaggen und gehören ins Board-Reporting.

Patch-SLA-Modelle. Klassische 30/60/90-Tage-Fenster wurden in einer Welt entworfen, in der Disclosure-zu-Exploit im Median mehrere Wochen brauchte. Dieses Modell braucht entweder deutlich schärfere Tiers für «critical exposed assets» oder eine Erweiterung um eine Compensating-Controls-Dimension: Virtual Patching, WAF-Rules, Netzsegmentierung als zeitkritische Zwischenmassnahme, nicht als Option.

Konkret für die Quantifizierung:

  • CVSS-Base allein reicht nicht mehr; EPSS-Score plus Exposure-Kontext wird zur Standardschicht.
  • Für Risk-Akzeptanz-Entscheidungen zu nicht gepatchten Systemen ist eine explizite Angabe der kompensierenden Controls notwendig. Eine Management-Unterschrift reicht nicht mehr aus.
  • Threat-Modeling-Sessions führen «AI-enabled attacker» als Standard-Threat-Actor, nicht als Sonderfall.

SOC und IR-Operations: Was sich im Alltag ändert

Hier wird es konkret – und für IR-Teams am relevantesten.

  1. Signatur-basierte Erkennung verliert weiter an Gewicht
    Das ist kein neuer Trend, aber er beschleunigt sich. Wenn ein Angreifer mit minimalem Aufwand funktional äquivalente, aber IOC-freie Varianten bekannter Malware-Familien generieren kann, ist Signatur-Detection primär noch für Noise-Reduction tauglich. Investitionen sollten sich auf Verhaltensdetektion (EDR-Behavioral, UEBA), Abuse-of-Legitimate-Tools-Pattern (Living-off-the-Land) und Anomaly-Detection im Netzwerk- und Identity-Layer verschieben.
  2. Alert-Triage muss maschinell assistiert werden
    Wenn die Angreiferseite KI-gestützt skaliert, kann die Verteidigerseite das nicht manuell ausgleichen. Konkret: LLM-gestützte First-Line-Triage, die Alert-Cluster bildet, Kontext anreichert (Asset, Owner, letzte Änderungen, historische False Positives) und Priorisierungs-Vorschläge macht. Das ist keine Ablösung von Analyst:innen, sondern eine Verlagerung ihrer Arbeit – weg von «was ist das?» hin zu «stimmt die Hypothese, und was ist das Playbook?».

    Zwei architektonische Entscheidungen gehören direkt mit auf den Tisch.

    ▪️Deployment-Modell. Der LLM-Layer im SOC braucht ein sauberes Deployment. On-Prem oder dedicated-tenant, mit klaren Data-Boundaries. Alert-Daten sind privilegiert; sie gehören nicht in einen generischen Cloud-LLM-Endpunkt.

    ▪️Model Drift als operatives Risiko. Wer LLM-gestützte Detection oder Triage einsetzt, erbt ein Problem, das in klassischen Detection-Engineering-Lehrbüchern nicht vorkommt: Frontier-Modelle hinter APIs verändern ihr Verhalten auf identischen Inputs lautlos und ohne Changelog. Thresholds, die gegen eine bestimmte Confidence-Verteilung kalibriert wurden, wandern unter dem eigenen Dashboard weg – stille Erhöhung der False-Negative-Rate, ohne dass irgendwo eine Version gebumpt wäre.

    Selbst self-hosted Stacks sind nicht immun: ein vLLM-Update, eine neue Quantisierung oder ein subtiler Tokenizer-Change verschiebt Outputs messbar, ohne dass jemand eine Änderung geflaggt hat. Für detection-kritische Workloads ist deshalb ein gepinntes lokales Modell häufig die operativ bessere Wahl als das stärkste Frontier-Modell: reproduzierbar, auditierbar, immun gegen silent Updates.

    Für die eigentliche Analyst:innen-Arbeit (Zusammenfassungen, Hypothesenbildung, Client-Kommunikation) bleibt das Frontier-Modell sinnvoll. Diesen Split zwischen maschinenseitiger Entscheidung (lokal, gepinnt) und menschenzugewandter Generierung (frontier, drift-tolerant) samt Monitoring-Werkzeugkasten – Golden Corpus, PSI/JS-Divergence, Refusal-Rate-Tracking – habe ich an anderer Stelle ausführlicher beschrieben: Your AI Detections Are Rotting: Model Drift as a Hidden Risk in Security Operations.
    Die regulatorische Pointe dort ist hier noch wichtiger: Unter NIS2 und DORA ist ein LLM, dessen Verhalten man nicht festhalten kann, eine Compliance-Schuld, keine Capability.

    Das ist der Punkt, an dem der Mythos-Reflex «wir brauchen jetzt mehr KI im SOC» in die Irre führen kann. Mehr KI ohne Drift-Monitoring erzeugt das nächste Blind-Spot-Problem – nur jetzt mit hübscherem UI.

  3. IR-Playbooks: Zero-Day-Assumption als Default
    Die klassische Trennung zwischen «bekannte Schwachstelle, Standardplaybook» und «Zero-Day, eskaliere an Senior-Responder» erodiert. Wenn Angreifer häufiger Zero-Days im Portfolio haben – weil das Finden billiger geworden ist – muss das Standardplaybook mit dieser Möglichkeit rechnen.
    Konkret:
    ▪️  Erst-Hypothese im Major-Incident: «unbekannter Initial Access Vector» bekommt mehr Gewicht, bevor sie abgeräumt wird.
    ▪️  Forensik-Preservation wird früher getriggert, auch wenn die Incident-Klassifikation noch unsicher ist.
    ▪️  Tabletop-Exercises führen «AI-enabled adversary» als Standard-Szenario, nicht als Spezialübung. In unseren Hybrid Crisis Simulations sehen wir, dass dieser Szenario-Typ bisher häufig als Sonderfall behandelt wird. Das Timing, ihn zu normalisieren, ist jetzt.
  4. Threat Hunting proaktiv auf Legacy-Assets
    Wenn Mythos-Klassen-Tooling in Angreiferhand ist, verschiebt sich die Hunting-Priorität auf Assets, bei denen bislang «zu alt, zu langweilig für einen Attacker» angenommen wurde. Die proprietäre Inhouse-Anwendung aus 2007, die seit zwei CISO-Generationen «eigentlich abzulösen» ist, wird zum plausiblen Initial-Access-Vektor. Hunting-Hypothesen sind entsprechend zu priorisieren.

Proaktives Threat Hunting

Patch- und Vulnerability-Management: Der eigentliche Schmerzpunkt

Dieser Bereich ändert sich am stärksten, weil er am stärksten auf den alten Annahmen gebaut war.

  1. Exposure Management ersetzt Vulnerability Management
    Die Branche redet seit Jahren davon, der Mythos-Moment beschleunigt es. Vulnerability-Management fragt: welche CVEs betreffen mich? Exposure-Management fragt: welche Angriffspfade sind realistisch nutzbar, und wo ist meine Verteidigung am schwächsten? Für die zweite Frage braucht es Attack-Path-Analyse, reachability-aware SCA und kontinuierliche External-Attack-Surface-Management-Capabilities (EASM).
  2. Virtual Patching wird Default, nicht Option
    Wenn Patch-Zyklen des Herstellers länger brauchen als die Exploit-Entwicklung, muss die Lücke überbrückbar sein. WAFs, IPS, Deception-Tech, Netzsegmentierung und Micro-Perimeter-Policies sind nicht länger «nice to have». Für kritische Assets muss eine Compensating-Control im Werkzeugkasten sein, die schneller aktivierbar ist, als der Vendor patchen kann. Das ist ein architektonischer Punkt, kein Tooling-Punkt – und er muss vor dem nächsten grossen Zero-Day geklärt sein, nicht während.
  3. SBOM plus VEX: Von Compliance zu Operations
    SBOMs waren in vielen Organisationen bislang ein Compliance-Artefakt – für EU Cyber Resilience Act, Executive Order 14028 oder Sektorregulierungen. Nach Mythos ist die operative Frage: wie schnell kann ich eine neu disclosed Library-Vulnerability in meinem gesamten Software-Portfolio lokalisieren? Ohne SBOM: Tage bis Wochen. Mit SBOM plus VEX (Vulnerability Exploitability eXchange): Minuten. Diese Geschwindigkeitsdifferenz entscheidet künftig über Incident-Kosten.
  4. Priorisierung umbauen
    Die typische Frage «welche Critical-CVEs muss ich diese Woche patchen?» wird ersetzt durch «welche Kombinationen aus Exposure, Exploitability und Business-Impact haben aktuell das schlechteste Risk-Profil?». CISA KEV, EPSS und exposure-aware Scoring werden zur Standardschicht. Monatsbasierte Patch-Boards reichen nicht mehr; Patch- und Mitigation-Entscheidungen werden zu einem kontinuierlichen Prozess mit wenigen klar priorisierten Eskalationspfaden.

Vendor- und Supply-Chain-Strategie

Hier liegt einer der unangenehmsten Effekte. Glasswing schafft eine Zwei-Klassen-Wirtschaft.

  1. Vendor Due Diligence: Neue Fragen
    Lieferanten-Fragebögen brauchen neue Punkte:
    ▪️Nutzt der Vendor KI-gestützte Security-Analyse in der eigenen Entwicklung? Seit wann? Welche Coverage (Code, Dependencies, Build-Pipeline)? 
    ▪️Gibt es SBOMs für alle bezogenen Produkte und Versionen? In welchem Format (SPDX, CycloneDX)? 
    ▪️Existieren VEX-Statements für bekannte CVEs? 
    ▪️Time-to-Patch-SLA für Critical-Findings, die durch automatisierte Analyse entdeckt werden? 
    ▪️Für kritische Vendors: Teilnahme an Programmen vom Glasswing-Typ oder vergleichbare AI-assisted-defense-Capability? Wenn nein – warum nicht, und welche Alternative bietet sich an? 
  2. Konzentrationsrisiko wird sichtbar
    Glasswing-Partner sind bei Anthropic namentlich gelistet. Für europäische Unternehmen ist die operative Frage: wie viel des eigenen Risiko-Stacks hängt an Vendors mit dieser Capability, versus an Vendors ohne? Das ist kein moralisches Argument, sondern ein Risiko-Argument: Defensive-AI-Capability wird Teil der Vendor-Risikobewertung.
  3. Regulatorische Hebel nutzen
    Für den DACH-Raum relevant: NIS2 (EU-weit), DORA (Finanzsektor), CRA (Produkt-Security) und in Österreich das NISG 2024 bieten bereits heute Hebel, um von kritischen Lieferanten strukturierte Antworten zu diesen Fragen einzufordern. Die Werkzeuge existieren; sie müssen nur auf die neue Bedrohungslage geschärft werden. Wer CRA-Anforderungen bislang als Compliance-Kosten gesehen hat, sollte sie nun als Risk-Mitigation-Hebel reframen.
  4. Open-Source-Abhängigkeiten
    Die andere Seite der Glasswing-Medaille: Anthropic hat 100 Mio. USD an Usage Credits und 4 Mio. USD direkt an Open-Source-Security-Organisationen zugesagt. Wenn die eigene Organisation Open-Source-Upstream-Beiträge liefert oder auf kritische OSS-Infrastruktur angewiesen ist, ist aktive Beteiligung an diesen defensive efforts – OpenSSF-Initiativen, direkter Kontakt zu Upstream-Maintainern, Contributor-Backing für kritische Libraries – ein direkter Risk-Mitigator für die eigene Supply Chain.

Ein pragmatisches 90-/180-/365-Tage-Playbook

Genug Analyse. Was sollte jetzt konkret getan werden?

Playbook: Die ersten 90 Tage

  1. Assumption Update. Threat-Model-Review-Session, in der «AI-enabled adversary» als Standard-Threat-Actor-Profil eingeführt wird. Betroffen: alle kritischen Assets, alle Tier-1-Prozesse.
  2. TabletopMindestens eine TTX-Übung mit Szenario «mittelmässig kompetenter Angreifer, AI-assisted, unbekannte Initial-Access-Methode gegen Legacy-Asset». Playbook-Gaps dokumentieren.
  3. Legacy-Inventar. Liste aller Assets älter als zehn Jahre, insbesondere intern entwickelte Software. Klassifizierung nach Exposure und Business-Criticality. Wahrscheinlichste erste Angriffsfläche.
  4. Detection-Engineering-Backlog prüfen. Anteil signaturbasierter vs. verhaltensbasierter Detections messen. Zielwert für Verschiebung setzen.
  5. Vendor-Liste der Top-20-Kritischen. Fragebogen um die Punkte aus Abschnitt 6.1 ergänzen. Versenden.

Playbook: Monate 3 bis 6

  1. Virtual-Patching-Capability etablieren. Wenn nicht vorhanden: WAF-Rule-Pipeline, schnelle IPS-Signature-Deployment-Prozesse, Netzsegmentierungs-Playbook für kritische Assets.
  2. Exposure Management. Pilot mit einem EASM- oder Attack-Path-Analysis-Tool. Ziel: Umstieg von «welche CVEs?» zu «welche Pfade?».
  3. SBOM-Programm. Für intern entwickelte Produkte automatisiertes SBOM-Generation im Build. Für extern bezogene Software: systematische SBOM-Anforderung, gestaffelt nach Kritikalität.
  4. LLM-assistierte SOC-Triage – mit Drift-Monitoring ab Tag eins. Pilot mit dedizierter, datenschutzkonformer LLM-Integration in SIEM/SOAR. Data-Boundaries vor dem Pilot definieren, nicht danach. Zwingend begleitend: Golden Corpus mit 200-2.000 Referenzinputs, Output-Distribution-Monitoring (PSI, JS-Divergence), Refusal-Rate-Tracking und eine klare Trennung zwischen maschineller Entscheidung (gepinntes lokales Modell) und analyst-facing Generierung (Frontier-Modell). Ohne diese Schicht ist jede Aussage zu Detection-Qualität nach drei Monaten Produktion unbelegt.
  5. IR-Playbook-Review. Zero-Day-Assumption als Default in Major-Incident-Procedures. Preservation-Trigger früher.

Playbook: Monate 6 bis 12

  1. Risk-Quantification-Modell anpassen. Time-to-Exploit-Schätzungen revidieren, SLA-Tiers entsprechend neu strukturieren.
  2. Vendor-Rescoring. Auf Basis der Antworten aus Phase 1 Top-Vendors neu bewerten. Kritisch sind insbesondere unklare Aussagen zu KI-gestützter Security-Analyse, fehlende SBOM-/VEX-Nachweise oder unrealistische Patch-SLAs. Bei solchen Lücken gezielte Eskalationsgespräche führen und Konzentrationsrisiken im Board-Reporting sichtbar machen.
  3. Threat Hunting auf Legacy. Dedizierte Hunting-Kampagnen auf den identifizierten Legacy-Assets. Hypothesen: unbekannter Initial Access via alter Library-Vulnerability, Lateral Movement über deprekatiertes Admin-Protokoll.
  4. Participation. Teilnahme an branchenspezifischen Information-Sharing-Initiativen prüfen (ISACs, CERT.at, sektorale CSIRTs), die AI-enabled-threat-Intelligenz austauschen. Isoliertes Arbeiten wird teurer.
  5. Board-Reporting neu aufsetzen. Metriken, die vor zwei Jahren aussagekräftig waren (Anzahl gepatchter CVEs, Anzahl gehandhabter Alerts), sind es weniger denn je. Ersetzen durch Exposure-Metriken, MTTD-minus-TTE-Proxies, Vendor-Risk-Heatmaps.

Fehlreaktionen nach Anthropic’s Claude Mythos, die teuer werden

Drei häufige Reaktionsmuster, die in den nächsten Monaten teuer werden:

  1. Panik-Prozess-Neubau. Wer jetzt das komplette Vulnerability-Management-Programm «wegen Mythos» neu ausschreibt, verschenkt sechs Monate auf einen Prozess, der zwei Iterationen zu weit von der aktuellen Realität entfernt ist. Inkrementelle Anpassungen sind fast immer überlegen.
  2. AI-Security-Snake-Oil kaufen. Die nächsten Marketingwellen werden «Mythos-proof»-Labels tragen. Das Wort hat keine technische Bedeutung. Die Gegenfragen, die man einem Vendor stellt: wie behandelt das Produkt AI-generierte Malware-Varianten? Was ist die False-Positive-Rate bei LLM-assistierten Detections? Welche Trainingsdaten, welche Adversarial-Robustness-Tests?
  3. Alles ignorieren. «Haben wir immer schon so gemacht, wird schon nicht so schlimm.» Mag stimmen, doch die Grundannahmen, auf welchen «immer so gemacht» basiert, haben sich verschoben. Ein Review der Annahmen ist günstig; ein Incident auf Basis veralteter Annahmen teuer.
  4. LLM-gestützte Detection als Fire-and-Forget behandeln. Ein LLM-Klassifikator sieht aus wie eine Korrelationsregel, verhält sich aber nicht so. Hosted-Modell-Verhalten driftet ohne Ankündigung; self-hosted Stacks driften bei vLLM-Updates, Quantisierungswechseln oder Tokenizer-Changes. Ohne Golden-Corpus-Regression und Drift-Monitoring ist jede produktive AI Detection nach wenigen Monaten schlecht kalibriert – und die Operating-Point-Verschiebung bemerkt man typischerweise erst nach dem Incident, der sie sichtbar gemacht hat.

Takeaways und CISOs Antworten auf Anthropic’s Claude Mythos

Mythos ist keine Revolution und keine PR-Nummer. Es ist ein deutliches Signal, dass KI-gestützte Offensiv-Capability eine Commodity-Trajektorie genommen hat und die defensive Seite entsprechend anpassen muss – nicht über Nacht, nicht in Panik, aber auch nicht später als 2026.

Der pragmatische CISO operiert in drei Modi gleichzeitig:

  • Tagesgeschäft weiterführen
  • an den Stellen inkrementell anpassen, an denen sich die Grundannahmen messbar verschoben haben 
  • mit dem Vorstand ehrlich über die verbleibende Unsicherheit sprechen.

Alle drei sind wichtiger als die perfekte Antwort auf die Frage, ob Mythos «wirklich» AGI ist.

Die eigentliche Arbeit beginnt nicht mit einem neuen Tool. Sie beginnt mit einer harten Review der eigenen Annahmen.

Threat Modeling

Bleiben Sie am Puls der digitalen Sicherheit: Entdecken Sie spannende Entwicklungen, fundierte Analysen und die wichtigsten News aus der Welt der Cybersicherheit. Abonnieren Sie unsere Blog-Updates und lassen Sie sich die neuesten Insights direkt in Ihr Postfach liefern – kompakt, relevant und immer einen Schritt voraus.

Blog Updates abonnieren

Quellenangabe:
•    Anthropic: Ankündigung Claude Mythos Preview und Project Glasswing, 7. April 2026. https://red.anthropic.com/…
•    UK AI Security Institute (AISI): Unabhängige Mythos-Evaluierung. https://www.aisi.gov.uk/…
•    AISLE: AI Cybersecurity After Mythos: The Jagged Frontier — https://aisle.com/…
•    Scientific American: What is Mythos and why are experts worried about Anthropic’s AI model — https://www.scientificamerican.com/…
•    Council on Foreign Relations: Six Reasons Claude Mythos Is an Inflection Point for AI and Global Security — https://www.cfr.org/…
•    Bloomberg: How Anthropic Discovered Mythos AI Was Too Dangerous For Release — https://www.bloomberg.com/…
•    The Hill: Anthropic’s Mythos model sparks cybersecurity concerns — https://thehill.com/…
•    CBS News: Anthropic’s Mythos AI can spot weaknesses in almost every computer on Earth — https://www.cbsnews.com/…
•    PwC: Global Digital Trust Insights 2026 (AI-enabled threat dynamics).
•    Mat Fuchs: Your AI Detections Are Rotting: Model Drift as a Hidden Risk in Security Operations — https://medium.com/@mathias.fuchs/your-ai-detections-are-rotting-model-drift-as-a-hidden-risk-in-security-operations-cac014477248

Firmenkontakt und Herausgeber der Meldung:

InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch

Ansprechpartner:
Estelle Ouhassi
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

DevSecOps: 3 Frameworks und ein 4-Stufen-Plan beenden jeden Cyber-Blindflug

DevSecOps: 3 Frameworks und ein 4-Stufen-Plan beenden jeden Cyber-Blindflug

Künstliche Intelligenz entfesselt Innovationen in ungeahntem Masse, während sich bewährte Sicherheitslogiken zur Variablen wandeln. Obwohl DevSecOps klassische Entwicklungsprozesse wirksam absichert, entstehen mit KI laufend neue Cyberrisiken, die bestehende Modelle nicht vollständig erfassen. Die Lösung: Eine Erweiterung von DevSecOps um drei gezielte KI-Frameworks sowie ein konkreter 4-Stufen-Plan, der Risiken priorisiert und in praxisnahe DevSecOps-Massnahmen überführt.

DevSecOps hat Entwicklungsprozesse über Jahre hinweg robuster gemacht: CI/CD-Pipelines sind abgesichert, Infrastrukturen stabiler, Sicherheitsprüfungen fest integriert. Doch mit dem Einsatz von Künstlicher Intelligenz verschiebt sich die Ausgangslage jetzt grundlegend.

Entwickler:innen integrieren LLMs in bestehende Applikationen, Data Analysts trainieren Machine-Learning-Modelle, KI-Tools werden unternehmensweit produktiv eingesetzt – und die Angriffsfläche wächst schneller, als bestehende Sicherheitsmodelle nachziehen können. Plötzlich zeigen sich Lücken dort, wo Prozesse als bewährt galten.

Warum Scanner, Firewalls und Pentests bei KI versagen

Die harte Wahrheit ist: KI-Systeme sind mit herkömmlichen Sicherheitsmassnahmen nur unzureichend geschützt. Schwachstellenscanner übersehen sogenannt vergiftete, manipulierte Trainingsdaten, klassische Firewalls greifen bei Prompt-Injection-Angriffen auf KI-Lösungen ins Leere, und selbst Penetrationstests erfassen keine Schwachstellenrisiken in der Modellextraktion. KI ohne spezialisierte Sicherheitsmassnahmen bedeutet Kontrollverlust. Wer sie dennoch ohne KI-spezifische Schutzmassnahmen einsetzt, operiert im Blindflug.

KI-Sicherheit beginnt nicht im Code, sondern im Management

Sie kennen die DevSecOps-Philosophie: Sicherheit gehört von Anfang in jeden Prozess, wird konsequent automatisiert und als gemeinsame Verantwortung verankert. Mit KI entstehen völlig neue Angriffsmuster, die ausserhalb der bisherigen Erfahrungswerte und Schutzmechanismen liegen.

Die neuen Cyberrisiken zeigen sich auf folgenden drei Ebenen: in der Data Science, im operativen Betrieb von KI-Systemen und in strategischen Entscheidungsprozessen.

Data Science und KI: Wie Machine-Learning-Modelle neue Angriffsflächen schaffen

Im Bereich «Data Analysts & Scientists» können unbeabsichtigt folgende, neue Sicherheitsrisiken entstehen:

  • Einsatz nicht verifizierter Trainingsdaten, potenziell manipuliert von Angreifern oder Wettbewerbern.
  • Verwendung von vorab trainierten Modellen aus öffentlichen Repositories ohne Überprüfung ihrer Sicherheit oder Urheberschutz.
  • Offenlegung von Modell-APIs ohne Rate Limitation oder Extraktionsschutz.
  • Bereitstellung von Modellen ohne Rücksicht auf Angriffe durch böswillige Akteure.

MLOps: Deshalb versagt ein klassischer Schutz bei ML-Systemen

Der Betrieb von ML-Systemen folgt einer anderen Sicherheitslogik als klassische Applikationen mit konkreten Auswirkungen auf ArchitekturLieferkette und Monitoring:

  • Anwendungscode und ML-Pipelines erfordern unterschiedliche Arten von Sicherheit.
  • Die Infrastruktur für die Bereitstellung von Modellen benötigt besonderen Schutz.
  • Kontinuierliches Training von KI-Modellen birgt neue Risiken für die Lieferkette.
  • Bei der Drift-Erkennung (Überwachen von Daten- oder Modellveränderungen) geht es nicht nur um Leistung, sondern auch um Sicherheit.

Wenn fehlende Risikoanalyse zum Business-Risiko wird

Fehlende Transparenz über KI-Risiken kann dazu führen, dass strategische Entscheidungen auf unsicherer Basis getroffen werden:

  • Welche KI-Systeme sind für Ihr Unternehmen am gefährlichsten?
  • Halten wir die neuen KI-Vorschriften (https://www.infoguard.ch/…) ein (z. B. EU-KI-Gesetz, Vorschriften für bestimmte Branchen)?
  • Wie wahrscheinlich ist es, dass unsere Modelle gestohlen werden, unsere Daten nach aussen geleakt werden oder unsere Algorithmen voreingenommen sind?
  • Wie viel Geld sollten wir für KI-Sicherheit ausgeben und wo?

Eine KI-Sicherheitsbewertung hilft Ihnen alle diese Fragen zu beantworten, bevor sie zu Problemen werden.

Mehr zur KI-Sicherheitsbewertung

Das Drei-Framework-Modell: Was macht es so erfolgreich?

Wir haben das DevSecOps-Modell, dem Sie bereits vertrauen, um drei Frameworks erweitert, die gut zusammenarbeiten:

Strategische Ebene: NIST AI Risk Management Framework

Was das NIST AI Risk Management Framework leistet:

Das NIST AI Risk Management Framework übersetzt KI-Risiken in eine für Führungskräfte verständliche Governance-Sprache; wie Sicherheit, Datenschutz, Fairness, Transparenz und Einhaltung von regulatorische Anforderungen. Es unterstützt dabei, das KI-Portfolio systematisch zu klassifizieren und Prioritäten anhand von Risikostufen zu setzen.

Warum Sie es brauchen:

Verwaltungsräte interessieren sich zunehmend dafür, wie KI im Unternehmen eingesetzt wird. Regulierungsbehörden beobachten deren Anwendung genau, und auch Kunden erwarten Transparenz. Das NIST AI RMF schafft die notwendige Governance-Struktur, um diese Anforderungen systematisch und nachvollziehbar zu adressieren.

Taktische Ebene: MITRE ATLAS Threat Intelligence

Was MITRE ATLAS Threat Intelligence für Sie leistet:

Das MITRE ATLAS Threat Intelligence zeigt genau, wie KI-Systeme angegriffen werden,¬ mit realen Techniken, die Wettbewerber, Staaten und Cyberkriminelle in der Vergangenheit eingesetzt haben. Nicht nur hypothetische, sondern auch reale und verifizierte Angriffe: Vom Modell-Diebstahl durch API-Abfragen bis hin zur Vergiftung von Trainingsdaten über Monate hinweg.

Warum Sie es brauchen:

Ein Red Team kennt die Methoden, in klassische Apps einzudringen. Es weiss jedoch noch nicht, wie man Modelle extrahiert oder ML-Pipelines vergiftet. ATLAS füllt diese Wissenslücke mit Angriffsmustern, die speziell für KI entwickelt wurden.

Operative Ebene: CRISP-ML(Q) Development Lifecycle

Was das CRISP-ML(Q) Development Lifecycle leistet:

Das CRISP-ML(Q) Development Lifecycle fügt Sicherheitskontrollen in jedem Schritt der ML-Entwicklung hinzu, von der Datenerfassung über die Bereitstellung bis hin zur Überwachung. Es überträgt das aus DevSecOps bekannte «Shift Left»-Prinzip auf den Entwicklungszyklus von KI-Systemen.

Warum Sie es brauchen:

Die Kompetenz zur sicheren Softwareentwicklung ist etabliert, während der sichere Aufbau von ML-Systemen häufig noch nicht vergleichbar verankert ist. CRISP-ML(Q) schliesst diese Lücke mit einem strukturierten Prozess, der Sicherheit nicht nur in der Theorie, sondern auch in der Praxis gewährleistet.

Praktische Umsetzung: Do’s und Dont’s beim Aufspüren von Betrugsfällen mit KI

Angenommen, Sie entwickeln ein KI-System zur Betrugserkennung. Was passiert, wenn Sicherheitsmechanismen nicht von Anfang an integriert sind?

Ohne integrierte DevSecOps-Frameworks (Worst-case-Szenario)

Fehlen integrierte Frameworks, entfaltet sich das Risiko entlang der gesamten Wertschöpfungskette:

  • Datenwissenschaftler trainieren mit den verfügbaren Daten, wodurch sie mit höherer Wahrscheinlichkeit «vergiftet» sein werden.
  • Ein DevOps-Team stellt es wie jede andere App bereit, was bedeutet, dass es keine KI-spezifischen Kontrollen gibt.
  • Das Sicherheitsteam testet es wie normale Software, was bedeutet, dass es keine Betrachtung von KI-Angriffsvektoren gibt.
  • Sechs Monate später stehlen Wettbewerber das Modell durch API-Abfragen, Aufsichtsbehörden verhängen Geldstrafen wegen Voreingenommenheit und Führungskräfte fragen sich, warum die Sicherheit «das nicht bemerkt hat».

KI mit integrierter KI-Sicherheitsbewertung

Basierend auf den Kriterien des NIST AI RMF wird dies als ein System mit hohem Risiko eingestuft, das strengen Kontrollen unterliegt, da es die Finanzen der Kunden betrifft und unter behördlicher Aufsicht steht.

Die Bedrohungsmodellierung nach MITRE ATLAS zeigt, dass die grössten Bedrohungen die Modell-Extraktion (durch Wettbewerber), Datenvergiftung (durch Gegner, die eine Entdeckung vermeiden wollen) und «Bias Incidents» (durch Aufsichtsbehörden) sind.

Die Integration von CRISP-ML(Q) stellt sicher, dass die Datenvalidierung das Verfälschen verhindert, Fairness-Tests entsprechende Verzerrungen aufdecken und die kontinuierliche Überwachung Angriffe in der Produktion erkennt.

Das Ergebnis? Die Betrugserkennung geht planmässig live, besteht die behördliche Überprüfung und funktioniert sicher, da die Sicherheitsmechanismen von Anfang an integriert war und Schwachstellen nicht erst bei der Einführung sichtbar werden.

«Mehr KI, mehr Risiko. Wer Sicherheit nicht entlang des ML-Lebenszyklus denkt, verliert die Kontrolle.» 

Eine KI-Sicherheitsbewertung beantwortet die brennendsten Governance-Fragen, bevor sie Ihre Innovation ausbremsen.

Von der Analyse zur Umsetzung: Der 4-Stufen-Plan für sichere KI

Unsere KI-Sicherheitsbewertung schafft für DevSecOps-Teams Klarheit darüber, welche Massnahmen prioritär umzusetzen sind und worauf der Fokus beim Einsatz von KI liegen sollte.

Schritt 1: Finden Sie heraus, wie hoch Ihr KI-Risiko ist

Wir erstellen eine Karte aller KI-Systeme, einschliesslich derjenigen, die der IT bekannt sind, und derjenigen, die «Schatten-KI» sind. Durch die systematische Risikoklassifizierung wird transparent, welche KI-Projekte ein erhöhtes Sicherheitsrisiko darstellen und welche weniger kritisch sind.

Was Sie potenziell sehen werden: «Das Data-Science-Team verwendet 12 verschiedene KI-Tools. Drei davon verarbeiten personenbezogene Daten von Kunden. Eines ist mit der Datenbank verbunden, in der der Betrieb Produktionsdaten speichert. Zwei davon sind gemäss dem EU-KI-Gesetz mit einem hohen Risiko behaftet.» Jetzt wissen Sie, wo Sie ansetzen müssen.

Schritt 2: Wissen, wie Angreifer vorgehen werden

Wir verwenden MITRE ATLAS, um dem Sicherheitsteam genau zu zeigen, wie Angreifer die KI-Systeme angreifen werden. Dabei handelt es sich nicht um allgemeine Bedrohungen, sondern um spezifische Angriffsszenarien, die auf dokumentierten Methoden aus der Praxis basieren.

Was Sie potenziell sehen werden: «Prompt-Injection-Angriffe können in den Kundenservice-Chatbot eindringen und Kundendaten stehlen. Durch eine Vielzahl von API-Abfragen lässt sich die Funktionsweise eines Betrugserkennungsmodells rekonstruieren. Eine KI-gestützte Lösung im Bereich Personalbeschaffung kann zudem ins Visier von Aufsichtsbehörden geraten, wenn Anzeichen für Voreingenommenheit bestehen.» Jetzt weiss Ihr Sicherheitsteam, worauf es achten muss.

Schritt 3: Suchen Sie nach Lücken in Ihrer Sicherheit

Wir vergleichen die aktuelle KI-Sicherheitslage mit den Branchenstandards. Welche Kontrollmechanismen sind etabliert? Wo gibt es Lücken? Wie hoch ist die Risikobewertung für jede Lücke?

Was Sie potenziell sehen werden: «Die API-Sicherheit ist robust, jedoch fehlt ein wirksamer Schutz gegen Modellextraktion. Für Trainingsdaten bestehen Qualitätsprüfungen, aber keine Abwehrmassnahmen gegen Datenvergiftung (Poisoning). Die Überwachung identifiziert Probleme mit der Leistung, aber erkennt keine sicherheitsrelevanten Angriffe.» Jetzt wissen Sie genau, was Sie verbessern können.

Schritt 4: Etablieren Sie Ihren Aktionsplan als prioritär

Wir geben Ihnen einen Plan mit drei Implementierungsphasen: Kritisch (Monate 1–2), Hohe Priorität (Monate 3–4) und Mittlere Priorität (Monate 5–6). Jede Phase hat ihre eigenen Kontrollen sowie Schätzungen zum Arbeitsaufwand für die Umsetzung.

Was Sie potenziell sehen werden: «In Phase 1 arbeiten Sie an fünf wichtigen Kontrollen, die Ihre grössten Risiken innerhalb acht Wochen Arbeit senken. Für zusätzliche Einsatz von Experten über acht Wochen fügt Phase 2 eine tiefgreifende Verteidigung hinzu. Phase 3 erreicht einen hohen Reifegrad.» Jetzt können Sie Ihre Pläne erstellen, budgetieren und umsetzen.

Eine KI-Sicherheitsbewertung deckt Schatten-Ki sowie Angriffsszenarien auf und liefert in einem 4-Stufen-Plan die fünf entscheidenden Kontrollmechanismen für sofortige Risikosenkung.

Mehr zur KI-Sicherheitsbewertung

KI-Security-Assessment abgeschlossen: Vom Bericht zur operativen Umsetzung

Die Bewertung ist nicht nur ein Bericht, sondern die Grundlage dafür, wie Teams KI-Modelle künftig sicher entwickeln können:

Sofort zu ergreifende Massnahmen (erste 90 Tage)

  • Einrichtung zentraler Kontrollen zur Reduktion der kritischsten Schwachstellen
  • Implementierung von Abwehrmassnahmen gegen Datenvergiftung (Poisoning)
  • Begrenzung und Überwachung von API-Aufrufen zum Schutz vor Modellextraktion
  • Prüfung und Sicherstellung der Modellintegrität
  • Schliessen identifizierter Sicherheitslücken mit unmittelbarem Schadenspotenzial.

Grundlagen schaffen (3–6 Monate)

  • Integration von KI-spezifischen Sicherheitskontrollen in bestehende DevSecOps-Pipelines
  • Automatisierte Tests zur Erkennung potenziell schädlicher Eingaben
  • Überprüfung von Modellartefakten und -integrität innerhalb der CI/CD-Prozesse
  • Monitoring zur Identifikation ungewöhnlicher oder sicherheitsrelevanter Abfragen
  • Verankerung von KI-Sicherheit als kontinuierlicher Bestandteil des operativen Betriebs statt als reaktive Massnahme im Vorfallfall.

Reifephase (6–12 Monate)

  • Aufbau organisationaler Kompetenz zum Schutz von KI-Systemen
  • Etablierung sicherer Entwicklungspraktiken im Bereich Machine Learning
  • Souveräner und kontrollierter Einsatz von KI im operativen Betrieb
  • Spezifische Abwehrmechanismen gegen KI-bezogene Bedrohungen
  • Verankerung von KI-Sicherheit als Bestandteil der Unternehmenskultur

Kontinuierliche Optimierung

Mit entsprechenden Frameworks lässt sich flexibel auf veränderte Bedrohungen reagieren. Neue MITRE-ATLAS-Methoden werden in bestehende Abwehrmassnahmen integriert. Anpassungen gemäss NIST AI RMF stärken die Governance-Strukturen, während Weiterentwicklungen im CRISP-ML(Q)-Prozess die sichere KI-Entwicklung kontinuierlich verbessern. Sicherheit bleibt damit anpassungsfähig, ohne die Sicherheitsstrategie jeweils von Grund auf neu definieren zu müssen.

Von DevSecOps zu MLSecOps: Warum sichere KI ein Wettbewerbsvorteil ist

DevSecOps hat dieses Problem gelöst, indem es Sicherheit von Anfang an zu einem Teil des Prozesses gemacht hat. Dank Automatisierung konnte es wachsen. Es hat sich eine Kultur entwickelt, in der jeder Verantwortung trägt.

KI ist dasselbe, nur mit anderen Werkzeugen. Die Teams, welche heute DevSecOps-Ideen auf KI anwenden, werden sich durchsetzen. Wenn Sie KI-Sicherheit als «etwas, um das wir uns später kümmern werden» betrachten, werden Unternehmen gegenüber Wettbewerbern, Aufsichtsbehörden oder Angreifern den Kürzeren ziehen.

Jetzt handeln: DevSecOps um KI-Governance und ML-Security erweitern

KI erweitert die Angriffsfläche – und verlangt nach einer Sicherheitslogik, die über klassische DevSecOps-Modelle hinausgeht. Entscheidend ist nicht die Anzahl einzelner Kontrollen, sondern eine strukturierte Bewertung der Risiken, eine klare Priorisierung und die konsequente Integration von Sicherheitsmechanismen entlang des gesamten ML-Lebenszyklus. Nur so wird KI steuerbar, auditierbar und nachhaltig resilient. Ist Ihre Innovation nicht zu wertvoll, um sie Cyberangriffen schutzlos auszusetzen?

Lassen Sie uns gemeinsam für die Sicherheit Ihrer Kronjuwelen sorgen und eine fundierte, nachvollziehbare Einschätzung erstellen.

  • Analyse laufender KI-Initiativen
  • Identifikation konkreter Risikotreiber
  • Definition einer gezielten Erweiterung von DevSecOps um KI-spezifische Sicherheitsmechanismen

Gemeinsam ordnen wir Ihre KI-Sicherheitsanforderungen ein und definieren die nächsten Schritte zu einem individuellen Massnahmenpaket.

Mehr zur KI-Sicherheitsbewertung

Quellenverzeichnis

Bildlegende: mit KI generiertes Bild

Firmenkontakt und Herausgeber der Meldung:

InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch

Ansprechpartner:
Estelle Ouhassi
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

Risiko Schatten-KI: In 4 Schritten zur sicheren KI-Nutzung nach ISO 42001

Risiko Schatten-KI: In 4 Schritten zur sicheren KI-Nutzung nach ISO 42001

Schatten-KI breitet sich getrieben von Effizienzdruck und unkontrolliertem Einsatz kostenloser KI-Tools rasant in Unternehmen aus. Fehlende KI-Governance öffnet Cyberrisiken, Datenschutzlücken und Haftungsfallen Tür und Tor. Der ISO/IEC 42001 ist kein Bürokratiemonster, sondern ein internationaler Standard für eine verantwortungsvolle und sichere KI-Nutzung. Vier Schritte zeigen, wie die Umsetzung gelingt.

Der Druck steigt: «Wir brauchen mehr Effizienz!» Die Stimmung im Büro von MysecureKI AG (* Name von der Redaktion geändert) ist angespannt. So infiltriert Schatten-KI schrittweise das Unternehmen. KI-Tools etablieren sich ausserhalb definierter Prozesse und entziehen sich jeder Auditierbarkeit. Die Folge sind Cyber-, Datenschutz- und Haftungsrisiken, die oft erst im Ernstfall sichtbar werden.

Lena klickt auf einen seriös wirkenden Banner: «KI-gestützte Vertragsanalyse – zehnmal schneller, kostenlose Testversion.» Zwei Minuten später meldet sie sich mit ihrer Dienst-E-Mail an und lädt den ersten Kundenvertrag hoch. Das Tool liefert sofort eine präzise Zusammenfassung.

Davide ist beeindruckt. «Das erinnert an D***box damals», sagt er – an jene Phase, als Mitarbeitende aus Frustration über umständliche interne Systeme auf externe Cloud-Dienste auswichen. Was als pragmatische Abkürzung begann, endete in Datenlecks, Compliance-Verfahren und erheblichem Reputationsschaden.

«Diesmal ist es anders», denken beide. «Es ist ja nur ein KI-Tool.» Genau hier liegt der Trugschluss.

Was ist Schatten-KI und wie infiltriert sie Unternehmen?

Was viele bei der verlockend einfachen Nutzung von KI-Systemen im Business-Alltag nicht wissen: Ihre Daten landen auf Servern in Ländern ohne DSG/DSGVO-konforme Verträge. Das KI-Tool speichert alle hochgeladenen Dokumente, um seine Modelle zu trainieren. Plötzlich sind vertrauliche Kundenverträge, interne Preislisten und sogar personenbezogene Daten veröffentlicht, ohne Kontrolle.

  1. Die IT-Abteilung bemerkt nichts. Doch eines Tages ruft ein Kunde an und fragt, warum seine Daten in einem öffentlichen KI-Forum auftauchen.
  2. Die Compliance-Abteilung gerät in Panik: Wo sind die Audit-Trails? Wer hat die Daten freigegeben? Wie soll das im nächsten ISO-27001-Audit erklärt werden?
  3. Die Geschäftsführung erfährt von dem Vorfall und stellt fest, dass nicht wenige Mitarbeitenden und die GL selbst vergleichbare Tools nutzen. Schatten-KI hat das Unternehmen infiltriert.

«Das ist wie bei Cloud! Nur geht es diesmal um KI, die wir nicht verstehen und nicht kontrollieren können», sagt der IT-Leiter in der Krisensitzung.

Schatten-KI: Zwischen KI-Governance, Regulierung und Angriffsfläche

KI ist keine «normale» Software

  • Aktive, automatisierte Datenverwertung: Daten werden nicht nur gespeichert, sondern aktiv genutzt, um Modelle zu trainieren, neue Inhalte zu generieren oder sogar Entscheidungen zu treffen.
  • Fehler sind schwer fassbar: Ein falsches KI-Ergebnis kann zu falschen Verträgen, Diskriminierung oder rechtlichen Verstössen führen – ohne dass es jemand sofort merkt.

KI-Compliance wird zum Minenfeld

  • CH AI Act, CH DDSG, DSGVO, EU AI Act, ISO 42001: Alle verlangen Transparenz, Dokumentation und Kontrolle über KI-Systeme. Doch wie soll das funktionieren, wenn niemand weiss, welche Tools genutzt werden – und klare Weisungen zum gewünschten Verhalten fehlen?
  • Audit-Trails fehlen: Wer hat welche Daten wann in welches KI-Tool eingegeben? Ohne Protokolle ein wahrer Albtraum für jede Compliance-Abteilung!

Cyber Security: Ein offenes Einfallstor für Cyberangreifer

  • KI-Tools ohne Sicherheitscheck: KI-Systeme können Malware enthalten, Phishing-Links generieren oder Daten an Dritte weitergeben.
  • KI als Angriffswerkzeug: Hacker nutzen KI, um realistischere Phishing-Mails zu schreiben oder Schwachstellen in Systemen zu finden – und mit Schatten-KI machen wir es ihnen noch leichter.

Ein strukturierter Abgleich mit ISO 42001 hilft, Governance, Prozesse und technische Massnahmen konsistent auszurichten.

AI-Gap-Analyse

Vier wirksame Massnahmen gegen Schatten-KI und Compliance-Risiken

1. Führung auf KI-Risiken sensibilisieren – offen und praxisnah.

  • Live-Demo: Ein IT-Sicherheitsexperte zeigt, wie schnell ein KI-Tool vertrauliche Daten preisgeben kann – und wie einfach es ist, gezieltes Social Engineering damit zu betreiben.
  • Botschaft: «Erinnert ihr euch an den D***box-Vorfall 2015? Damals haben wir gelernt, dass‚ einfach mal ausprobieren teuer werden kann. Bei KI ist das Risiko noch gravierender.»

2. Sichere und compliant geprüfte KI-Alternativen anbieten

  • Geprüfte und Genehmigte KI-Tools und Apps: Das Unternehmen führt unternehmensweite Lizenzen für sichere KI-Plattformen ein – mit CH AI Act, CH DDSG, DSGVO, EU AI Act, ISO 42001-konformen Verträgen und klaren Nutzungsrichtlinien.
  • Schnelle Freigabeprozesse: Mitarbeitende können neue Tools über ein Self-Service-Portal beantragen – statt sie heimlich zu nutzen.

3. Datenflüsse technisch überwachen und kontrollieren

  • CASB-Lösungen (Cloud Access Security Broker) überwachen den Datenverkehr zu KI-Tools und blockieren unautorisierte Uploads.
  • KI-spezifische Security-Tools wie Microsoft Purview analysieren, welche Daten in KI-Systeme fliessen – und alarmieren bei Verdachtsfällen.

4. KI-Governance strukturiert verankern – etwa nach ISO 42001

Das Unternehmen implementiert ein KI-System nach ISO 42001:

  • Risikobewertung: Welche KI-Tools dürfen genutzt werden? Welche Daten sind tabu?
  • Dokumentation: Jede KI-Nutzung wird protokolliert – für Audit-Sicherheit und Transparenz.
  • Regelmässige Schulungen: Mitarbeitende lernen, KI-Risiken zu erkennen und sichere Alternativen zu nutzen.

Drei Schritte zur KI-Strategie ohne Schatten-KI

Schatten-KI entsteht nicht aus böser Absicht, sondern aus Frustration und Zeitdruck und dem Wunsch nach effizienteren Arbeitsabläufen. Doch die Konsequenzen sind real und kostspielig: Datenverluste, Compliance-Verstösse, rechtliche Risiken und Reputationsschäden.
Wer KI produktiv nutzen will, braucht Sicherheit – und eine praktikable Lösung. Der richtige Ansatz verbindet Aufklärung, sichere Alternativen und klare Leitplanken für den Alltag.

Drei zentrale Säulen ermöglichen eine sichere Nutzung:

  1. Verständnis schaffen: Warum ist Schatten-KI riskant?
  2. Sichere Alternativen bieten: Schnelle, nutzerfreundliche KI-Tools, die Compliance und Sicherheit garantieren.
  3. Kontrolle & Transparenz: Mit Standards wie ISO 42001, CASB und Monitoring unsichtbare Risiken sichtbar machen.

Schatten-KI steuern mit ISO 42001: Struktur schafft Cyberresilienz

Schatten-KI ist kein Trendphänomen – sie ist längst Realität im Unternehmensalltag. Wer KI produktiv und sicher einsetzen will, braucht klare Leitplanken, verlässliche Prozesse und Transparenz über Datenflüsse. Mit einer fundierten KI-Security-Strategie, praxiserprobten Tools und einem strukturierten Vorgehen schaffen Unternehmen nicht nur Compliance, sondern verwandeln KI in einen echten Wertbeitrag für Sicherheit, Effizienz und Innovation.

Mit einer strukturierten und sicheren KI-Strategie gewinnen Sie:

  • Eine belastbare Roadmap für den sicheren KI-Einsatz,
  • Klarheit über den Reifegrad und konkrete Handlungsfehler,
  • Transparenz über Daten- und KI-Nutzung, auditfest und nachvollziehbar,
  • sowie eine nachhaltige Reduktion von Schatten-KI durch klare Regeln, sichere Plattformen und gezielte Kontrolle.

Unsere Erfahrung aus Strategie- und Sicherheitsprojekten zeigt: Wirksame KI-Governance entsteht dort, wo Führung, IT, Compliance und Security gemeinsam Verantwortung übernehmen. Nachhaltige Lösungen verbinden regulatorische Anforderungen – etwa aus dem EU AI Act oder ISO 42001 – mit bestehenden Prozessen und technischen Schutzmassnahmen.

So wird KI nicht zum Risiko, sondern zu einem kontrollierten Innovationsfaktor.

AI-Gap-Analyse

Firmenkontakt und Herausgeber der Meldung:

InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch

Ansprechpartner:
Estelle Ouhassi
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

Zero Trust ab 2026: 3 Praxisansätze für Cyberabwehr zwischen KI und Compliance

Zero Trust ab 2026: 3 Praxisansätze für Cyberabwehr zwischen KI und Compliance

Künstliche Intelligenz, Quantencomputing und neue regulatorische Vorgaben wie NIS2 und DORA verändern Zero-Trust-Strategien ab 2026 in IT-, Cloud- und OT-Umgebungen umfassend. Der erste Teil dieses Zweiteilers hat gezeigt, weshalb Zero Trust heute betrieblich notwendig ist und wo klassische Ansätze an ihre Grenzen stossen. Im zweiten Teil geht es um KI in Angriff und Abwehr, Zero Trust als künftige Pflicht und drei konkrete Praxistipps für die strategische Ausrichtung der Cyberabwehr.

Künstliche Intelligenz ist weder Fluch noch Segen – sie ist längst Realität, auch in der Cyberabwehr. Sie verändert grundlegend, wie Sicherheitsentscheidungen getroffen werden müssen. In diesem Kontext entwickelt sich Zero Trust ab 2026 zur strategischen Leitplanke der Cyberabwehr: KI automatisiert Zugriffs- und Risikoentscheidungen, während Regulierungen wie NIS2 und DORA den verbindlichen Rahmen für den Schutz von IT- und OT-Umgebungen setzen. Für den Gesamtzusammenhang lohnt es sich, den ersten Teil dieses Zweiteilers zu lesen.

AI & Zero Trust: Risiken und Chancen für moderne Cyberabwehr

KI als Angriffsvektor: Deepfakes, automatisierte Phishing-Angriffe & Co.

Generative KI wie etwa FraudGPT oder WormGPT ermöglicht hyper-personalisierte Phishing-Angriffe, die Multi-Faktor-Authentifizierung (MFA) umgehen. Angreifer nutzen KI-generierte Stimmen, um im Callcenter Zugriff auf Konten zu erhalten.

Praxistipp: Setzen Sie auf Continuous Authentication und nutzen Sie Tools wie «Microsoft Defender for Identity», um das Echtzeit-Verhalten zu analysieren.

KI in der Cyberabwehr: Automatisierte Zero-Trust-Entscheidungen

KI-gestützte Policy-Engines (EDR) treffen 90% der Zero-Trust-Entscheidungen automatisch. Zum Beispiel durch  Blockieren eines Logins, weil der Nutzer oder die Nutzerin plötzlich aus einem Hochrisikoland zugreift oder durch Isolieren eines Geräts, das ungewöhnliche Datenflüsse zeigt.

Kritische Reflexion:  KI ist kein Allheilmittel. Erst das fortlaufende Training mit kontextspezifischen Daten ermöglicht eine zuverlässige Erkennung ohne übermässige Fehlalarme. Nutzer:innen müssen verstehen, warum ein Zugriff blockiert wurde.

Quantencomputing: Die tickende Zeitbombe für Verschlüsselung

Post-Quantum-Kryptografie: Das Ende von RSA und ECC absehbar

Forschungen zeigen, dass leistungsfähige Quantencomputer voraussichtlich in den 2030er-Jahren gängige Verschlüsselungsverfahren wie RSA-2048 und ECC gefährden werden. Digitale Zertifikate, die auf RSA oder ECC basieren, könnten damit angreifbar werden – mit direkten Auswirkungen auf Zero-Trust-Architekturen.

Kritische Reflexion: Es gibt NIST-standardisierte Algorithmen wie etwas CRYSTALS-Kyber und NTRU als Ersatz für RSA/ECC. Hybride Verschlüsselung (klassisch + PQC) werden als Übergang genutzt. Die Planung und Umsetzung sollte frühzeitig mit den Herstellern von Zero-Trust-Tools erfolgen. Erste ZTNA-Lösungen unterstützen bereits PQC-Kryptografie, eine breite Marktdurchdringung steht jedoch noch aus.

Praxistipp: Erstellen Sie eine Planung für Ihre Organisation mit dem Fokus auf kritische Systeme (z. B. Finanzdaten, OT-Steuerung) und starten Sie 2026 mit Pilotprojekten.

Denn Stillstand erhöht das Cyberrisiko. Eine gezielte Überprüfung Ihrer Zero-Trust-Strategie unterstützt fundierte Entscheidungen zu MFA, Mikrosegmentierung sowie NIS2 und DORA.

Zero Trust Readiness Assessment

Deshalb treiben NIS2 und DORA Zero Trust voran

NIS2 & KRITIS: Zero Trust als neue Pflicht

Auch wenn NIS2 direkt nur für EU-Mitgliedstaaten gilt, sind viele Schweizer Unternehmen betroffen – insbesondere jene mit EU-Kunden oder Tochtergesellschaften. Kritische Infrastrukturen (Energie, Gesundheit, Transport, etc.) sind in der Pflicht, Zero Trust umzusetzen.

Für KRITIS-Organisationen ergeben sich daraus klare Kernanforderungen:

  • Risikoanalyse (welche Systeme sind kritisch)
  • MFA für alle Zugriffe (inkl. Alle Admin Konten)
  • Logmanagement
  • Mikrosegmentierung
  • Continuous Monitoring
  • Incident-Response-Plan mit MTTD

DORA (EU) im Finanzsektor: Zero Trust als Nachweis für den Finanzsektor

Der Digital Operational Resilience Act (DORA) verpflichtet Banken und Versicherungen zum Nachweis, dass sie Angriffe in Echtzeit erkennen (via SIEM + UEBA) und Third-Party-Risiken wie beispielsweise Cloud-Anbieter kontrollieren.

Praxistipp IT: «Nutzen Sie die Regulierung als Chance.» Verbinden Sie DORA/NIS2-Projekte mit der Zero-Trust-Roadmap. Führen Sie externe Audits (z. B. ISO 27001; Zero Trust) durch und nutzen Sie Zero Trust, Secure Access Service Edge (SASE), ZTNA und passwortlose Authentifizierung (FIDO2).

Praxistipp OT: «Nutzen Sie die Regulierung gezielt als Chance für die OT-Sicherheit.» Etablieren Sie externe Audits, etwa nach ISE 62443 oder Zero-Trust-Prinzipien, und priorisieren Sie technische Massnahmen wie OT-spezifische Mikrosegmentierung, Geräte-Zertifikate für alle PLCs sowie passive OT-Überwachung bis hin zu einem OT-SOC. Ergänzend bewähren sich hybride Konzepte aus Air Gap und ZTNA, um kritische Steuerungsnetze kontrolliert abzusichern.

Hypothese aus der Glaskugel

Lassen wir uns von den Gedanken treiben, wohin sich unsere Welt entwickeln könnte.

Weshalb Zero Trust durch KI «unsichtbar» wird

Nutzer:innen merken nicht mehr, dass sie in einer Zero-Trust-Umgebung arbeiten, weil KI-Modelle und Automatisierung alles im Hintergrund regeln. Mitarbeiter greifen auf eine Maschine in der Produktion zu. Die KI prüft automatisch: Ist das Gerät patchbar? Passt das Verhalten zur Nutzer:in? Gibt es Anomalien im Netzwerk? Je nachdem wird der Zugriff gewährt oder blockiert, ohne manuelle Eingabe. 

Zero Trust + Digital Twin = Self Healing Security

Digitale Zwillinge von OT-Systemen eröffnen perspektivisch die Möglichkeit, Angriffe virtuell zu simulieren und Sicherheitsregeln automatisiert anzupassen. Ziel ist eine zunehmend proaktive Cyberabwehr, die nicht erst auf Vorfälle reagiert, sondern Risiken frühzeitig antizipiert.

Wann wird Zero Trust zur Pflicht und für wen gilt diese Regulierung?

2030 wird Zero Trust in der EU und in kritischen Infrastrukturen verpflichtend. Cyberversicherungen verlangen bereits jetzt zunehmend Zero-Trust-Nachweise, während fehlende Zero-Trust-Standards entlang der Lieferkette die Risiko- und Kostenfaktoren für alle Beteiligten erhöhen

3 Praxistipps für Cyberabwehr als strategische Leitplanke in IT und OT

Damit Cyberabwehr in IT und OT als strategische Leitplanke wirkt, braucht es wenige, aber gezielt eingesetzte Massnahmen.

Diese drei praxisnahen Handlungsempfehlungen liefern dafür eine belastbare Orientierung:

  • Implementieren Sie klassische Multi-Faktor-Authentifizierung (MFA) und Mikrosegmentierung. Ihr Zugewinn ist enorm: Beide Massnahmen umgesetzt, liefern sie bereits rund 80% des gesamten Sicherheitsnutzens.
  • Planen Sie zudem frühzeitig den Einsatz von künstlicher Intelligenz (KI) und professionelles SOC Monitoring, denn ohne diese Technologien wird Ihre IT- und OT-Sicherheit nicht mehr ausreichend sein.
  • Nutzen Sie ausserdem aktuelle Regulierungen wie NIS2 und DORA gezielt als Hebel, um Budget und interne Akzeptanz für Ihre Sicherheitsmassnahmen zu gewinnen.

Die grösste Gefahr im Cyberraum? Abwarten und nichts tun.

Gern begleiten Sie unsere Expert:innen und unterstützen Sie mit über 350 Fachpersonen bei der Weiterentwicklung und Überprüfung Ihrer Zero-Trust-Strategie mit bewährten Methoden aus der Praxis:

  • Umsetzung zentraler Massnahmen wie Multi-Faktor-Authentifizierung (MFA), Mikrosegmentierung, Domain Tiering auf Basis von Best-Practice Baselining
  • Entwicklung tragfähiger Strategien für KI-Sicherheit oder Quantenresilienz
  • Konkretisierung und Überprüfung von NIS2- oder DORA-Roadmaps

Zero Trust ist wie ein Airbag, man merkt erst, wie wichtig ein Airbag ist, wenn man ihn braucht. Vereinbaren Sie jetzt ein unverbindliches Erstgespräch.

Zero Trust Readiness Assessment

Über weitere Entwicklungen und aktuelle Analysen zur Cybersicherheit können Sie informiert bleiben. Einfach unsere Blog-Updates abonnieren und die neuesten Artikel in Ihrem Postfach abrufen! Wir freuen uns auf Sie.

Blog Updates abonnieren

Firmenkontakt und Herausgeber der Meldung:

InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch

Ansprechpartner:
Estelle Ouhassi
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

Cyber Security Radar 2026: Die zentralen Traktanden für CISOs und CIOs

Cyber Security Radar 2026: Die zentralen Traktanden für CISOs und CIOs

Regulatorische Vorgaben verschärfen sich, KI verändert Angriffsmuster und der Kostendruck steigt. Eine Einordnung von 2025 zeigt: Cybersicherheit wird 2026 zur strategischen Führungsaufgabe, bei der Cyberresilienz, Governance und technologische Weitsicht entscheidend sind. Wer jetzt strukturiert priorisiert, reduziert Risiken, Kosten und regulatorische Reibung. Der Beitrag ordnet die Entwicklungen des vergangenen Jahres ein und skizziert die strategischen Weichen für CISOs und CIOs. Eine Checkliste fasst die drei zentralen Handlungsfelder zusammen.

Wie die Vorjahre war auch das vergangene Jahr geprägt von einer Vielzahl verschiedener Schwerpunktthemen, die im Zusammenhang mit neuen Technologien, steigenden regulatorischen Anforderungen und der wachsenden Bedrohungslage stehen.
Ein Blick nach vorne zeigt: Wer die Cybersicherheit 2026 verstehen will, kommt an einer präzisen Rückblende nicht vorbei.

FINMA und revDSG erklärt: Welche Pflichten gelten heute?

Das FINMA-Rundschreiben RS 2023/1 und das revidierte Datenschutzgesetz (revDSG) sind bereits länger in Kraft.

Die Anforderungen des FINMA-Rundschreibens RS 2023/1 werden durch aufsichtsrechtliche Prüfungen streng kontrolliert, und die FINMA veröffentlicht in unregelmässiger Frequenz Aufsichtsmitteilungen mit Hinweisen und Erläuterungen (z. B. FINMA-Aufsichtsmitteilung 05/2025 «Operationelle Resilienz bei Banken, Personen nach Art.1b BankG, Wertpapierhäusern und Finanzmarktinfrastrukturen»).

Finanzinstitute müssen ein Bündel von sich ergänzenden technischen und organisatorischen Massnahmen (TOMs) umsetzen, um ein ganzheitliches Management von Cyber- und IKT-Risiken, den Schutz von kritischen Daten, die durchgängige Incident-Behandlung (Erkennung, Analyse, Bewertung, Reaktion, Einhalten von Meldefristen) sowie ein effektives Risikomanagement von Dienstleistern nachzuweisen. Zusätzlich sind sie gefordert, die Resilienz zu stärken und diese regelmässig zu überprüfen.

Das revidierte Datenschutzgesetz (revDSG) warf medial keine allzu grossen Wellen. Jedoch verlangt dieses, dass die Verletzung der Datensicherheit (z. B. ein Datenabfluss im Rahmen einer Ransomware-Attacke) dem Eidgenössischen Öffentlichkeits- und Datenschutzbeauftragten (EDÖB) gemeldet werden muss, wenn ein hohes Risiko für betroffene Personen besteht.

NIS2 und DORA: Bekannte Anforderungen, verschärfte Durchsetzung in der Schweiz

Obwohl die Schweiz kein EU-Mitglied ist, werden NIS2 (Network and Information Security Directive 2) und DORA («Digital Operational Resilience Act» – NIS2 für den Finanzsektor) auch hierzulande relevant(er). Schweizer Unternehmen, welche in der EU tätig sind, müssen die entsprechenden Vorgaben wie strengere Meldepflichten, Resilienz-Tests, die durchgängige Ereignisbehandlung (Erkennung, Analyse, Bewertung, Reaktion) und ICT-Risikomanagement umsetzen.

Die nationale Umsetzung von NIS2 bringt diverse rechtliche, organisatorische und technische Herausforderungen für Unternehmen. Die Richtline ist bewusst technologieneutral und lässt den EU-Mitgliedsstaaten Interpretationsspielraum, was zu unterschiedlichen nationalen Mindeststandards führt. Aktuell haben diverse Staaten noch kein nationales Gesetz verabschiedet, was zu fehlender Rechtssicherheit führt.

CRA: Warum Produktsicherheit über den gesamten Lebenszyklus entscheidet

Unabhängig davon, dass die Schweiz kein EU-Mitglied ist und der Cyber Resilience Act (CRA) während einer Übergangsfrist zurzeit noch nicht verbindlich ist, müssen die Anforderungen im Lebenszyklus (von der Entwicklung über das Testen bis hin zur Wartung und Support) von Produkten berücksichtigt werden. Beschaffer in europäischen Unternehmen fordern bereits heute den Nachweis, dass die Sicherheit solcher Produkte während der gesamten Nutzungszeit sichergestellt ist.

KI im Alltag: Wenn Künstliche Intelligenz unsichtbar mitentscheidet

Der Einsatz von KI hat rapide zugenommen, sei es durch die Integration in Suchmaschinen, in Produktivitäts-Software (wie Microsoft Office) und Browser (z. B. Microsoft Edge) oder durch die Verwendung in Unternehmen zur Automatisierung bzw. Digitalisierung von Abläufen. Für Benutzer wird es zunehmend schwieriger zu erkennen, wo KI bereits Teil der Prozesse und Abläufe ist. Gleichzeitig befinden sich Unternehmen in dauerndem Wettlauf mit Anbietern von KI, um eine sichere und konforme Nutzung zu gewährleisten.

Cyberangriffe im Wandel: Automatisierte Ransomware trifft Gross und Klein

Angreifer setzen vermehrt auf KI, um Phishing-Emails und Schadsoftware zu erstellen oder Sicherheitslösungen zu umgehen. Die Folge davon sind hochgradig personalisierte und automatisierte Ransomware-Angriffe mit deutlich erhöhter Erfolgsquote. Vermehrt fanden auch eine doppelte oder dreifache Erpressung mit den entwendeten Daten statt. Nicht zu vernachlässigen sind opportunistische Angriffe, die (nicht gepatchte) Schwachstellen ausnutzen. Das Ökosystem der Angreifer funktioniert weiterhin erfolgreich, und die Spezialisierung unter den Angreifergruppen wird sich noch verstärken.

Supply Chain und Cloud: Third Party Risk Management ist Pflicht

Heute verlässt sich kaum ein Unternehmen noch ausschliesslich auf eigene Ressourcen. Ohne die Nutzung von IT-Anbietern, externen Dienstleistern oder Cloud-Diensten ist ein modernes Geschäftsmodell kaum mehr möglich. Gleichzeitig haben Angriffe über Zulieferer, Dienstleister und Partner in den letzten Jahren stetig zugenommen. Das systematische Third-Party-Risk-Management (TPRM) wurde zum «Muss» für Unternehmen und ist nicht zuletzt in den Fokus der Regulatoren gerückt.

Cyber-Hygiene: Schwachstellenmanagement, Backups und Awareness als Fundament

Bewährte Verfahren zur Sicherstellung einer Basis-Resilienz – kurz Cyber-Hygiene genannt – stehen nach wie vor im Fokus. Insbesondere wenn es darum geht, ein Sicherheitsdispositiv rasch und zielgerichtet aufzubauen, das Angriffen erfolgreich widerstehen kann. Auch letztes Jahr wurden erfolgreiche Angriffe häufig durch grundlegende Mängel wie unzureichendes Schwachstellenmanagement und fehlende Backups ermöglicht. Defizite in Sicherheitskultur, Security Awareness und Monitoring verstärkten diese Wirkung zusätzlich.

Inicident Response und BCM: Stillstand oder Business Continuity?

Der Ausbau der Fähigkeiten zur schnellen Erkennung, Eindämmung und Reaktion auf Cybervorfälle hat sich fortgesetzt. Parallel dazu rücken Massnahmen zur Erhöhung der Ausfallsicherheit in den Fokus mit dem Ziel, die Geschäftskontinuität ganzheitlich zu adressieren. Bestehende Notfallplanungen wurden vermehrt überprüft und vertieft analysiert sowie um die Einbindung von Dienstleistern und Cloud-Diensten erweitert. Dies trug wesentlich dazu bei, die Cyberresilienz der Unternehmen gegen Angriffe nachhaltig zu stärken.

Wie schon 2024 standen Themen wie verschärfte regulatorische Anforderungen, Stärkung der Resilienz gegen Angriffe sowie die rasant wachsende Bedeutung von KI im Fokus.

Strategischer Ausblick: Was prägt Cybersicherheit ab 2026?

Unternehmen sind gefordert, ihr Sicherheitsdispositiv laufend zu überprüfen und konsequent nachzuschärfen. Nur wer identifizierte Schwachstellen systematisch behebt, bleibt angesichts einer dynamischen Bedrohungslage reaktionsfähig und cyberresilient.

Der Ausblick auf 2026 ordnet die prägenden Trends, Herausforderungen und Innovationen ein.

Datenhoheit und Datensouveränität: Wo Cloud-Nutzung rechtliche Unsicherheiten schafft

Die Nutzung von internationalen Cloud-Diensten (Microsoft, Google, Amazon, etc.) führt dazu, dass nicht immer nachvollziehbar ist, wo Daten physisch verarbeitet und gespeichert werden. Gleichzeitig unterliegen Daten zunehmend mehreren Rechtsordnungen parallel, wie beispielsweise jener der Schweiz, der EU und den USA. Die Bestimmung des jeweils anwendbaren Rechts erschwert sich erheblich und kann zu Unsicherheiten führen.

Künstliche Intelligenz im Wandel: Wenn Angreifer und Verteidiger im selben Tempo lernen

Der Einsatz von generativer KI steigt kontinuierlich an, gleichzeitig nehmen Risiken durch unkontrollierte („Shadow“-)KI-Nutzung zu: Mitarbeitende setzen KI-Tools ein, die nicht von der IT/Security kontrolliert sind bzw. kontrolliert werden können (insbesondere bei Bring-Your-Own-Device, BYOD).

Der Druck, Governance und effektive Kontrollen für die Nutzung von KI zu etablieren, wird immer grösser. Will ein Unternehmen eine eigene KI-Infrastruktur aufbauen und betreiben, so müssen die damit einhergehenden Risiken identifiziert, bewertet und adressiert werden.

Gleichzeitig nutzen Angreifer generative KI und zunehmend auch die nächste Entwicklungsstufe, namentlich agentische KI, für autonome Angriffe. Diese Techniken kommen dabei insbesondere für massgeschneiderte Phishing-Kampagnen, Deepfake-Betrug und weitere Angriffstechniken zur Anwendung. Unternehmen sollten KI nicht nur als unterstützende Tools, sondern dringend als Teil des Risikoumfelds betrachten. Der Einsatz von KI-unterstützter Bedrohungserkennung und automatisierte Abwehrmechanismen sind unentbehrlich, um angemessen und zeitnah reagieren zu können.

Tool-Landschaften: Wie weniger Komplexität mehr Sicherheit schafft

In den vergangenen Jahren und Jahrzehnten haben Unternehmen eine Unzahl spezialisierter Tools und Technologien eingesetzt, um adäquat auf neue Bedrohungen und Risiken zu reagieren. Dies hat zu einer erhöhten Heterogenität und Komplexität, Redundanzen, eingeschränkter Effizienz und stetig steigenden Kosten geführt. Stagnierende oder gar sinkende finanzielle Mittel erhöhen den Druck, Tool-Landschaften zu konsolidieren und Abläufe stärker zu automatisieren.

Cloud, Identitäten und Zero Trust: Kontrolle über System- und Anbietergrenzen

Die Nutzung von Cloud-Infrastrukturen wird weiter zunehmen. Dies erfordert neue Governance- und Kontrollmechanismen, da klassische Kontrollmodelle an ihre Grenzen stossen. Gleichzeitig eröffnen sich neue Angriffsmodelle, die eine Weiterentwicklung bestehender Sicherheitsdispositive erfordern. Eine besondere Herausforderung stellt die Verwaltung von Identitäten über Systemgrenzen hinweg dar. Konzepte wie Zero Trust Architecture (ZTA) werden zunehmend zur Notwendigkeit.

Jüngste Ausfälle bei Amazon und CloudFlare haben die Risiken eines Vendor Lock-ins deutlich gemacht. Im Ernstfall sind Unternehmen nicht mehr in der Lage, ihre Dienste bereitzustellen oder zentrale Geschäftsprozesse aufrechtzuerhalten.

Regulatorik und Compliance in der Chefetage – Aufschub geht nicht!

Im Einklang mit der zunehmenden Digitalisierung, grenzüberschreitenden Datenflüssen und allgegenwärtigem KI-Einsatz entwickeln sich die Regulatorik- und Compliance-Anforderungen, die Unternehmen erfüllen müssen, weiter. Damit rücken Fragen der regulatorischen Steuerung und Haftung zunehmend auch in die Verantwortung von Geschäftsleitungen und Führungsgremien:

  • Stärkere Vorgaben für Kritische Infrastrukturen: Getrieben durch die laufenden Angriffe und Erpressungen dürften die Anforderungen an kritische Infrastrukturen weiter zunehmen (z. B. in den Bereichen Verkehr und Transport, EVU, Gesundheit, Wasserversorgung).
  • KI-Gesetze: Die KI-Regulierungen (u. a. die KI-Verordnung der CH und EU) fordern von Unternehmen, dass sie Risikobewertungen für KI-Systeme durchführen. Besonders bei hochriskanten Anwendungen wie biometrischer Identifikation werden diese verpflichtend.
  • NIS2: Mit der steigenden Anzahl an verabschiedeten nationalen Umsetzungsgesetzen wächst der Druck auf Unternehmen, die Konformität damit bestätigen zu können. Die teilweise unterschiedlichen Mindestanforderungen in den EU-Mitgliedstaaten werden zur Herausforderung, insbesondere für Unternehmen mit lokalen bzw. verteilten Infrastrukturen

Unternehmen müssen frühzeitig regulatorische Trends antizipieren und Massnahmen treffen, um rechtzeitig die geforderte Konformität sicherzustellen.

Lieferketten im Visier: Deshalb wird Vendor-Risk-Management unverzichtbar

Die wachsende Zahl erfolgreicher Angriffe auf Drittanbieter und Software-Lieferketten verschärft die Anforderungen an das Risikomanagement. Software-Bills-of-Material (SBOMs), Lieferketten-Transparenz und strukturierte Vendor-Risk-Management-Prozesse werden damit zur Voraussetzung.

Ransomware: Wenn die dauernde Bedrohung mehrere Eskalationsstufen erreicht

Ransomware-Angriffe bleiben eine dauerhafte Bedrohung. Ihre Ausprägung verändert sich jedoch durch die Verbreitung von Doppel- und Dreifach-Erpressungsmodellen, bei welchen Verschlüsselung, Datenveröffentlichung und DDoS-Attacken kombiniert werden. Besonders betroffen sind Kritische Infrastrukturen wie Banken, Spitäler und Energieversorger, wie Analysen des Bundesamts für Cybersicherheit (BACS) zeigen.

Quantencomputing: Deshalb will Post-Quantum-Kryptografie vorbereitet sein

Die Entwicklung von Quantencomputern schreitet stetig voran. Auch wenn zum heutigen Zeitpunkt nicht absehbar ist, wann Quantencomputer kommerziell verfügbar sein werden und somit aktuelle Verschlüsselungstechniken gefährden könnten, ist Vorsorge angezeigt. Unternehmen sind gefordert, Post-Quantum-Kryptographie zu evaluieren und Migrationspläne zu entwickeln.

Fachkräftemangel und Kompetenzen: Neue Fähigkeiten entscheiden über Resilienz

Der anhaltende Fachkräftemangel an Sicherheitsspezialist:innen stellt Unternehmen auch in Zukunft vor erhebliche Herausforderungen. Zusätzlich gewinnen neue Kenntnisse – etwa in den Bereichen KI-Sicherheit, Cloud-Identitäten und Threat Hunting – an Bedeutung, um auf aktuelle und künftige technologische Entwicklungen und Bedrohungen adäquat reagieren zu können. Gefragt sind deshalb gezielte Investitionen in die Weiterbildung der IT-Fachpersonen.

Alternativ lässt sich fehlende Fachkompetenz im Unternehmen durch einen punktuellen Einsatz externer Expertise sowie durch Organisationsmodelle kompensieren, die Defizite gezielt über Automatisierung und klare Priorisierung abfedern.

Identitätsmanagement: Authentifizierung via Passwort verliert an Bedeutung

Identitäten sind das digitale Gold für Angreifer: Gelangen Cyberkriminelle in den Besitz digitaler Identitäten einschliesslich Passwörtern, erhalten sie weitreichenden Zugriff auf Systeme und Daten. Ein grosses Risiko stellen insbesondere sogenannte Identitätsschulden. Dazu zählen übermässige Berechtigungen sowie veraltete, nicht deaktivierte oder gelöschte Konten, weshalb eine regelmässige Überprüfung von Identitäten und den damit verknüpften Berechtigungen zwingend ist.

Die passwortlose Authentifizierung wie Biometrie, FIDO2 oder Passkey wird sich mittelfristig durchsetzen und zum Standard werden. Aktuell steht dem noch die fehlende Interoperabilität im Weg.

Kostendruck: Trotz begrenzter Mittel bleibt Cyberresilienz unverhandelbar

Die herausfordernde Wirtschaftslage, geprägt durch die von den USA eingeführten Zölle, durch Inflation und steigende Arbeitslosigkeit, verschärft den Druck auf Unternehmen. Für nachhaltige Investitionen in die Informationssicherheit fehlen zunehmend die Mittel. Unabhängig von einer angespannten finanziellen Situation bleibt die Sicherstellung der Cyberresilienz gegenüber sich stetig weiterentwickelnden Angriffen eine nicht verhandelbare Aufgabe.

Eine strategische Checkliste: So handeln Sicherheitsverantwortliche proaktiv

Die kommenden Jahre bringen grosse Herausforderungen mit sich, die zugleich strategische Chancen eröffnen. Schweizer Unternehmen, welche die regulatorischen Vorgaben erfüllen, KI strategisch einsetzen und ihre Cyberresilienz systematisch stärken, reduzieren nicht nur inhärente Risiken, sondern sichern sich auch nachhaltige Wettbewerbsvorteile.

Für eine praxisnahe Orientierung benennt die folgende Checkliste die künftigen Prioritäten für CISOs, CIOs und IT-Sicherheitsverantwortliche.

  • Regulatorische Compliance sicherstellen
    ▪️ FINMA-, NIS2-, DORA- und CRA-Anforderungen umsetzen
    ▪️ Organisationen wie Energieversorgungsunternehmen (EVU) auf neue Vorgaben vorbereiten
    ▪️ Datenhoheit/Datensouveränität sicherstellen
  • KI und Automatisierung nutzen
    ▪️ KI-gestützte Abwehrsysteme einführen
    ▪️ Agentic KI und autonome Bedrohungen aktiv verfolgen
  • Ransomware- und Lieferkettenrisiken minimieren
    ▪️ Zero-Trust-Architekturen implementieren
    ▪️ Drittanbieter regelmässig prüfen
    ▪️ Unabhängigkeit von Lieferanten sicherstellen
  • Identitätsmanagement und Quantenresistenz vorbereiten
    ▪️ IAM-Systeme bereinigen
    ▪️ Zero Trust Architecture (ZTA) evaluieren, insbesondere für Cloud-Dienste
    ▪️ Post-Quantum-Kryptographie evaluieren
  • Kostendruck und Fachkräfte
    ▪️ Sicherstellung der finanziellen Mittel trotz der angespannten Wirtschaftslage
    ▪️ Reduktion der Komplexität und Kosten in den eingesetzten Technologien
    ▪️ Sicherstellen des Know-hows und der Kompetenzen im Unternehmen 

Die 3 Handlungsfelder der Cyber Security – eine Daueraufgabe auf C-Level

Die Informationssicherheit bleibt weiterhin ein dynamisches und sich ständig weiterentwickelndes Feld. Für die Führungsverantwortlichen ist es entscheidend, als Organisation agil zu bleiben und sich kontinuierlich über neue Bedrohungen und technologische Entwicklungen zu informieren.

Eine regelmässige Prüfung und Entwicklung des Sicherheitsdispositivs ist notwendig, um die Integrität, Vertraulichkeit und Verfügbarkeit von Informationen und Systemen und somit die Business Continuity zu gewährleisten. Annahmen sollten kritisch hinterfragt und Massnahmen konsequent nachgeschärft werden. Cybersicherheit ist kein abgeschlossener Zustand, sondern eine kontinuierliche Management- und Resilienzaufgabe.

Entscheidend ist dabei eine strukturierte, risikoorientierte Herangehensweise, die über punktuelle Sicherheitsmassnahmen hinausgeht.

In der Praxis bewährt, hat sich insbesondere der Fokus auf drei zentrale Handlungsfelder:

  • Regulatorische Konformität und Governance sicherstellen:
    Anforderungen aus FINMA-Rundschreiben, NIS2, DORA oder Datenschutzvorgaben systematisch einordnen, umsetzen und nachweisfähig verankern.
  • Cyberresilienz und Incident-Response-Fähigkeiten stärken:
    Erkennungs-, Reaktions- und Wiederherstellungsprozesse gezielt ausbauen, Business Continuity absichern und Abhängigkeiten von Dienstleistern und Cloud-Anbietern berücksichtigen.
  • Technologische Risiken priorisieren und Komplexität reduzieren:
    Identitätsmanagement, Cloud- und Lieferkettenrisiken sowie KI-basierte Bedrohungen ganzheitlich bewerten und Sicherheitsarchitekturen konsolidieren.

Verschaffen Sie sich Klarheit über den Sicherheitsstatus Ihrer Organisation. Mit einer fundierten Standortbestimmung identifizieren Sie den Handlungsbedarf. Unsere Sicherheitsspezialist:innen unterstützen Sie bei der Weiterentwicklung Ihrer Cyberresilienz, um Ihre Handlungsfähigkeit auch unter zunehmendem regulatorischem und wirtschaftlichem Druck zu sichern.

Cyber Security Assessment

Über weitere Entwicklungen und aktuelle Analysen zur Cybersicherheit können Sie informiert bleiben. Einfach unsere Blog-Updates abonnieren und die neuesten Artikel in Ihrem Postfach abrufen! Wir freuen uns auf Sie.

Firmenkontakt und Herausgeber der Meldung:

InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch

Ansprechpartner:
Estelle Ouhassi
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

counterpixel

Für die oben stehenden Pressemitteilungen, das angezeigte Event bzw. das Stellenangebot sowie für das angezeigte Bild- und Tonmaterial ist allein der jeweils angegebene Herausgeber verantwortlich. Dieser ist in der Regel auch Urheber der Pressetexte sowie der angehängten Bild-, Ton- und Informationsmaterialien. Die Nutzung von hier veröffentlichten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber.