Durch die wachsende Autonomie von KI-Systemen darf Vertrauen kein Bauchgefühl bleiben. Unternehmen müssen wissen, welche KI-Systeme aktiv sind, welche Rechte sie besitzen und ob ihre Ergebnisse nachvollziehbar bleiben. Klassische Security- und Governance-Modelle stossen hier an Grenzen. Sie wurden vor allem für Menschen, Geräte, Applikationen und bekannte Softwareprozesse entwickelt.

KI-Systeme verhalten sich jedoch dynamischer. Sie können Daten verarbeiten, Aktionen auslösen, externe Tools einbinden und über Systemgrenzen hinweg agieren. Unternehmen brauchen deshalb eine neue Vertrauensarchitektur: AI Trust. Gemeint ist ein Ansatz, der Identität, Berechtigungen, Integrität und Herkunft von KI-Systemen und KI-generierten Inhalten technisch überprüfbar macht.

Von Digital Trust zu AI Trust

Digital Trust basiert seit Jahren auf bewährten Prinzipien wie Public Key Infrastructure, Zertifikaten, DNS und Verschlüsselung. Diese Mechanismen sorgen dafür, dass digitale Kommunikation geschützt, Identitäten überprüft und Systeme authentifiziert werden können.

Mit KI erweitert sich dieser Vertrauensraum. Unternehmen müssen künftig nicht nur wissen, wer auf ein System zugreift, sondern auch:

• Welche KI-Agenten aktiv sind
• Welche Daten sie verarbeiten
• Welche Berechtigungen sie besitzen
• Ob ein Inhalt echt, verändert oder KI-generiert wurde

AI Trust überträgt bewährte Vertrauensmechanismen auf KI. Ziel ist es, KI-Agenten, Modelle und Inhalte nicht nur zu regulieren, sondern technisch kontrollierbar zu machen.

Shadow AI: Wenn KI der Governance davonläuft

Viele Unternehmen nutzen KI bereits produktiv – teils offiziell, teils informell. Besonders kritisch ist sogenannte Shadow AI: der Einsatz von KI-Tools oder Agenten ausserhalb freigegebener Prozesse.

Dadurch entstehen blinde Flecken. Sensible Daten können unkontrolliert verarbeitet werden. Agenten erhalten möglicherweise zu weitreichende Rechte. Und Security-Teams wissen nicht immer, welche KI-Systeme tatsächlich im Einsatz sind.

Für CISOs wird Shadow AI damit zum Transparenztest. Entscheidend sind fünf Fragen:

1. Welche KI-Agenten werden im Unternehmen genutzt?
2. Welche Daten fliessen an diese Systeme?
3. Welche Agenten besitzen Zugriff auf interne Systeme?
4. Können kompromittierte Agenten sofort gestoppt werden?
5. Lässt sich ein Vorfall nachvollziehbar dokumentieren?

Die Antwort darauf kann nicht allein in Richtlinien liegen. KI-Governance muss technisch durchsetzbar werden.

Drei Bereiche, in denen Vertrauen neu gedacht werden muss

AI Trust betrifft vor allem drei Ebenen: Agenten, Modelle und Inhalte.

1. Vertrauen in KI-Agenten – AI Agent Passport
   KI-Agenten sind keine menschlichen Benutzer. Passwörter oder klassische Login-Prozesse greifen hier zu kurz. Agenten benötigen eindeutige, kurzlebige und überprüfbare Identitäten. So lässt sich kontrollieren, welche Aktionen sie ausführen dürfen, auf welche Daten sie zugreifen können und wann ein Zugriff beendet werden muss.
   Ein Ansatz dafür ist der AI Agent Passport. Er verbindet die Identität eines Agenten kryptographisch mit seinen Berechtigungen. Damit wird nachvollziehbar, was ein Agent tun darf, in welcher Umgebung er aktiv ist und wer dafür verantwortlich ist.
2. Vertrauen in KI-Modelle – Confidential Computing
   KI-Modelle werden zunehmend zu kritischen Unternehmensressourcen. Sie unterstützen Diagnosen, erkennen Betrug, automatisieren Compliance-Prozesse oder beeinflussen geschäftsrelevante Entscheidungen.
   Deshalb müssen Unternehmen sicherstellen, dass Modelle nicht manipuliert, unerlaubt verändert oder in unsicheren Umgebungen ausgeführt werden. Dazu braucht es unter anderem kryptographisches Signieren, Integritätsprüfungen und nachvollziehbare Modellherkunft. Besonders relevant ist Confidential Computing. Dabei werden Modelle in geschützten Ausführungsumgebungen betrieben. So bleiben Daten und Modellinformationen auch während der Verarbeitung geschützt.
3. Vertrauen in KI-generierte Inhalte – C2PA
   KI kann heute Texte, Bilder, Videos und strukturierte Daten in hoher Qualität erzeugen oder verändern. Für Unternehmen wird deshalb die Frage zentral: Woher stammt ein Inhalt? Wurde er verändert? Und kann seine Echtheit unabhängig geprüft werden? Metadaten oder Plattformhinweise reichen dafür nicht aus. Sie können entfernt oder verändert werden. Standards wie C2PA schaffen eine Grundlage, um digitale Inhalte mit signierten Herkunftsnachweisen zu versehen. So wird überprüfbar, wer einen Inhalt erstellt hat und ob er seitdem verändert wurde.

Identität, Kryptographie und DNS als Vertrauensanker

Eine tragfähige AI-Trust-Architektur braucht technische Kontrollpunkte. Dazu gehören DNS-basierte Richtlinien, kryptographische Identitäten, kurzlebige Credentials, Attestation und Integritätsnachweise.

Ein Beispiel: Bevor ein KI-Agent eine externe Verbindung aufbaut, kann geprüft werden, ob die Ziel-Domain erlaubt ist. Ist sie nicht freigegeben, wird die Verbindung blockiert, bevor Daten abfliessen oder unerlaubte Aktionen ausgelöst werden.

Solche Mechanismen machen aus abstrakter Governance konkrete Kontrolle. Unternehmen können festlegen, welche Agenten was tun dürfen – und diese Regeln technisch durchsetzen.

Von Transparenz zu Kontrolle: 5 Schritte für AI Trust

Am Anfang steht die Bestandesaufnahme. Unternehmen sollten erfassen, welche KI-Tools, Agenten und Modelle bereits genutzt werden und welche Datenflüsse damit verbunden sind.

Darauf aufbauend sollten sie definieren:

• Welche KI-Systeme erlaubt sind
• Welche Daten verarbeitet werden dürfen
• Welche Identitäten und Berechtigungen erforderlich sind
• Wie Modelle geschützt und überprüft werden
• Wie KI-generierte Inhalte gekennzeichnet und verifiziert werden können

So wird AI Trust zu einem praktischen Sicherheits- und Governance-Thema – nicht zu einem theoretischen Konzept.

DigiCert als Leader für Intelligent Trust

Moderne Ansätze für Digital Trust setzen genau hier an. DigiCert positioniert sich als globaler Leader für Intelligent Trust und erweitert bewährte Prinzipien wie PKI, DNS, Certificate Lifecycle Management, Attestation und kryptographische Identität auf die Anforderungen moderner KI-Umgebungen.

Die Plattform DigiCert ONE vereint zentrale Trust-Funktionen in einer integrierten Architektur und unterstützt Unternehmen dabei, digitale Vertrauensanker sichtbar, steuerbar und automatisierbar zu machen. Dazu gehören unter anderem PKI, DNS, Zertifikatsmanagement, Software Trust, Device Trust und Content Trust.

Für AI Trust entsteht daraus eine technische Grundlage, mit der Organisationen KI-Systeme nicht nur nutzen, sondern kontrolliert, nachvollziehbar und verantwortungsvoll betreiben können. 

InfoGuard & DigiCert – Vertrauen für die nächste KI-Ära

Mit DigiCert erweitert InfoGuard bewährte Digital-Trust-Prinzipien auf die Anforderungen moderner KI-Umgebungen. Bereits beim automatisierten Zertifikatsmanagement zeigt sich, wie wichtig Transparenz, Automatisierung und Krypto-Agilität für stabile und sichere digitale Infrastrukturen sind. Im KI-Kontext gewinnen dieselben Prinzipien zusätzlich an Bedeutung: Identitäten müssen überprüfbar, Berechtigungen kontrollierbar und Integrität kontinuierlich nachweisbar sein.

So entsteht die Grundlage, um KI nicht nur produktiv einzusetzen, sondern sicher, nachvollziehbar und kontrollierbar zu betreiben. Erfahren Sie im Whitepaper, wie die «Trust Architecture for AI» von DigiCert Unternehmen dabei unterstützt, Vertrauen in KI-Systeme technisch überprüfbar zu machen. 

Zum Whitepaper

InfoGuard begleitet Unternehmen, ihre AI Trust von Anfang an als Sicherheits- und Architekturthema zu denken – von Governance-Fragestellungen über technische Integration bis zur Absicherung von Identitäten, Daten, Cloud- und KI-Umgebungen. Unsere Expert:innen freuen sich auf den unverbindlichen Austausch!

AI-Gap-Analyse nach ISO 42001 

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

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

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.

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

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

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. Tabletop. Mindestens 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

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 Architektur, Lieferkette 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

• NIST AI Risk Management Framework:
• https://www.nist.gov/itl/ai-risk-management-framework MITRE ATLAS:
• https://atlas.mitre.orgCRISP-ML(Q):
• https://arxiv.org/pdf/2003.05155.pdfCloud Security Alliance AI Controls Matrix:
• https://cloudsecurityalliance.org/artifacts/ai-controls-matrixEU AI Act: Regulation 2024/1689
• ISO/IEC 23894:2023 – AI Risk Management
• ISO/IEC 42001:2023 – AI Management Systems

Bildlegende: mit KI generiertes Bild

Cyberoperationen sind längst Teil geopolitischer Konflikte. Iranische Hacktivisten, chinesische APT-Gruppen und russische Angreifer erhöhen den Druck auf europäische Organisationen. Der InfoGuard Threat Intelligence Report Q1/2026 analysiert die aktuelle Bedrohungslage und ihre Konsequenzen für Unternehmen.

Die Cyber-Bedrohungslage in Europa: angespannt wie nie

Die europäische Cyber-Bedrohungslage ist auf einem historischen Höchststand. Laut ENISA Threat Landscape 2025 (Berichtszeitraum Juli 2024 bis Juni 2025) entfielen 76,7 % aller Vorfälle auf DDoS-Angriffe, getrieben durch staatlich gelenkten Hacktivismus. Der öffentliche Sektor war mit 38,2 % am stärksten betroffen, doppelt so hoch wie im Vorjahr. Phishing bleibt mit 60 % der häufigste Initialvektor, wobei über 80 % der Kampagnen nachweislich KI-generierte Inhalte nutzen.

Der CrowdStrike European Threat Landscape Report 2025 zeigt: Ransomware trifft die Region auf Rekordniveau, während staatlich gesteuerte Angriffe (nation-state) um 150 % gestiegen sind. ENISA identifiziert 46 staatlich gesteuerte Intrusion-Sets, die aktiv gegen EU-Mitgliedstaaten operieren. Die Grenzen zwischen Cyberkriminalität, Hacktivismus und Staatsakteuren verschwimmen zusehends. Was früher klar trennbar war, ist heute ein komplexes Ökosystem aus Auftragsarbeit, ideologischer Motivation und staatlicher Instrumentalisierung.

Iran: Vom Cyber-Dschihad zur offenen digitalen Front – Lage März 2026

Der Eskalationspfad: Juni 2025 bis heute

Zum Verständnis der aktuellen Situation ist ein Blick auf den Eskalationspfad notwendig. Der zwölftägige Israel-Iran-Konflikt im Juni 2025 war die erste grosse Probe für Irans koordiniertes Cyber-Ökosystem im Kriegsfall. Das Center for Strategic and International Studies (CSIS) analysierte über 250.000 Telegram-Nachrichten aus mehr als 178 Hacktivist- und Proxygruppen und dokumentierte eine rasche Mobilisierung synchron zu den kinetischen Luftangriffen. Gruppen wie Fatimion Cyber Team, Cyber Fattah und Cyber Islamic Resistance koordinierten Aufklärung, DDoS-Angriffe, Website-Defacement und Datendiebstahl in direkter Abstimmung mit dem militärischen Geschehen – ein Muster, das auf institutionelle Führung hindeutet, nicht auf organischen Hacktivismus.

Parallel dazu setzte die iranische Regierung staatlich gesponserte Ransomware-Kampagnen ein und zahlte Prämien für Infektionen gegen US- und israelische Organisationen. MuddyWater (MOIS) initiierte mit Operation Olalampo eine strukturierte Cyber-Offensive gegen die META-Region (Naher Osten, Türkei, Afrika) mit Überlappungen zu einer parallel laufenden Kampagne namens RedKitten – ein Hinweis auf koordinierte Infrastruktur iranisch ausgerichteter Akteure.

28. Februar 2026: Operation «Epic Fury» und die digitale Reaktion

Am 28. Februar 2026 starteten die USA und Israel die koordinierte Militäroperation «Epic Fury» / «Operation Roaring Lion» mit Strikes auf iranische Führungsstrukturen, IRGC-Einrichtungen und nukleare Infrastrukturen. Innerhalb von Stunden begann Iran eine mehrstufige Vergeltungskampagne – sowohl kinetisch als auch im Cyberraum.

Ein technisch bemerkenswerter Faktor: Die israelische Gegenmassnahme war auch eine der grössten Cyberoperationen der Geschichte gegen Iran selbst und reduzierte die iranische Internetkonnektivität auf 1–4 % (Unit 42 / Palo Alto Networks, März 2026). Das bedeutet: Irans hochspezialisierte APT-Gruppen sind kurzfristig im Inland operativ eingeschränkt.

Daraus ergeben sich zwei parallele Bedrohungsszenarien:

• Ausserhalb Irans operierende Zellen und Proxy-Gruppen handeln jetzt mit taktischer Autonomie – ohne direkte Befehlsstruktur aus Teheran. Das macht ihre Aktionen schwerer vorhersagbar.
• Mittelfristig – wenn die Konnektivität wiederhergestellt ist – ist mit einer intensivierten Welle staatlicher APT-Operationen zu rechnen, da die IRGC-Einheiten Zeit hatten, Prioritäten zu setzen und Zugänge zu aktivieren, die schon länger «dormant» vorhanden waren.

Der «Electronic Operations Room» – koordinierter Cyber-Dschihad

Noch am 28. Februar 2026 wurde der «Electronic Operations Room» gegründet – ein Koordinationsgremium, das pro-iranische Hacktivist-Kollektive in einem strukturierten Cyber-Dschihad bündelt. Das Umbrella-Netzwerk «Cyber Islamic Resistance» (auch: Islamic Cyber Resistance Axis) koordiniert Gruppen wie RipperSec, Cyb3rDrag0nzz und zahlreiche weitere für synchronisierte DDoS-Wellen, Datenlöschoperationen und Defacements. Bis Anfang März 2026 wurden über 150 dokumentierte Hacktivismus-Vorfälle gezählt, wobei ca. 60 einzelne Gruppen aktiv sind – darunter auch pro-russische Kollektive (CloudSEK Situation Report, März 2026).

Europol warnte am 6. März 2026 explizit vor einer erhöhten Bedrohung für die EU: «Key risks are an elevated threat of terrorism and violent extremism, increased cyber-attacks targeting EU infrastructure, a rise in conflict-themed online fraud schemes, and the spread of disinformation and influence campaigns.» Frankreich, Deutschland und andere EU-Staaten haben ihre Sicherheitsmassnahmen erhöht, da iranische Netzwerke auch in Europa operativ sind.

Welche konkreten Cyberrisiken entstehen daraus für europäische Organisationen?

Das UK National Cyber Security Centre (NCSC) hat Anfang März 2026 eine explizite Warnung herausgegeben: Auch wenn derzeit kein signifikanter Anstieg direkter Cyberangriffe auf britische Netzwerke zu beobachten ist, warnen die Behörden: Die Lage kann sich jederzeit und mit nur geringer Vorwarnung ändern. Historisch gesehen hat Irans Cyberaktivität Europa immer wieder getroffen – Deutschland, Frankreich, Niederlande, und das vereinigte Königreich – oft als Kollateralschaden oder gezielter Sekundärangriff auf Organisationen mit Nahostbezug.

Das primäre Cyberrisikoprofil für europäische Organisationen im aktuellen Kontext:

• Kritische Infrastruktur (Energie, Wasser, OT/ICS): Iran hat nachweislich ICS/SCADA-Systeme als Ziele priorisiert. Die Schwachstelle CVE-2025-1960 in Schneider Electric EcoStruxure WebHMI ist bereits in iranisch-affiliierten Kampagnen ausgenutzt worden.
• Rüstung, Luft- und Raumfahrt, Telekommunikation: UNC1549 (Tortoise Shell) war im zweiten Halbjahr 2025 der viertaktivste iranische Akteur mit Fokus auf genau diese Sektoren.
• Regierungsstellen und diplomatische Einrichtungen: MuddyWater verbrachte 8 Monate unentdeckt in einem nahöstlichen Regierungsnetzwerk – ähnliche Muster sind bei europäischen Stellen zu erwarten.
• Supply-Chain-Risiko: Organisationen, die israelische OT-Komponenten einsetzen (z. B. bestimmte Unitronics-Systeme), gelten als indirekte Ziele nach dem Angriffsmuster der CyberAv3ngers-Kampagnen von 2023–2024.
• Organisationen mit Iran-nahen Mitarbeitern oder Diaspora: Iranische Akteure führen aktiv Verfolgungsoperationen gegen Regime-Gegner in Europa durch, inklusive physischer Bedrohungen nach Cyber-Kompromittierung.

Typische Angriffstechniken iranischer Cyberoperationen

Irans Cyberarsenal ist heterogen: Es reicht von hochkomplexen APT-Kampagnen bis zu kriminell genutzten Ransomware-Frameworks. Das Besondere ist die strukturelle Vermischung: Staatlich gesteuerter Zugang wird für kriminelle Zwecke monetarisiert, während gleichzeitig plausible Abstreitbarkeit staatlicher Beteiligung gewahrt bleibt. Sicarii – eine seit Dezember 2025 aktive RaaS-Operation – hat einen kritischen Defekt: Die Malware löscht ihre eigenen Entschlüsselungsschlüssel nach der Verschlüsselung, was eine Wiederherstellung dauerhaft unmöglich macht, unabhängig von einer Lösegeldzahlung (Halcyon, März 2026).

Technisch operieren iranische Gruppen bevorzugt über: Ausnutzung von VPN-Gateways und Firewalls (Pulse Secure, Fortinet, Palo Alto, F5, Citrix), ASPX-Webshells auf exponierten Servern, Living-off-the-Land-Techniken (LOLBins) für Persistenz und laterale Bewegung sowie KI-gestützte Spear-Phishing-Kampagnen mit hohem Personalisierungsgrad.

China: Stille Präsenz in staatlichen Netzwerken – eine unterschätzte Bedrohung

Während der Iran mit lautem Hacktivismus und politisch aufgeladenen Operationen auffällt, agiert China nach dem gegenteiligen Prinzip: maximale Stille, minimale Spuren, langfristige Positionierung. Dieser Paradigmenwechsel ist in den letzten zwei Jahren immer deutlicher geworden: China verschiebt seinen Fokus von klassischer Industrie- und IP-Spionage hin zu staatlichen Organisationen und kritischer Infrastruktur.

Volt Typhoon – die bekannteste chinesische APT-Gruppe für Infrastruktur-Targeting – wurde in einigen US-Netzwerken über fünf Jahre unentdeckt betrieben. CISA-Direktorin Jen Easterly formulierte es klar: Was bisher gefunden wurde, ist «wahrscheinlich nur die Spitze des Eisbergs.» Volt Typhoon nutzt ausschliesslich Living-off-the-Land-Techniken – keine Malware, nur native Systemtools. Das macht traditionelle signaturbasierte Erkennung weitgehend wirkungslos.

In Europa sind chinesische Cyberoperationen längst angekommen: Die niederländischen Dienste MIVD und AIVD bestätigten 2024 den ersten öffentlich attribuierten chinesischen Angriff auf das Verteidigungsministerium («Coathanger»-Malware für Fortinet FortiGate). Tschechien machte APT31 im Mai 2025 für die Kompromittierung des Aussenministeriums während der EU-Ratspräsidentschaft 2022 verantwortlich. Die EU-Aussenbeauftragte Kaja Kallas erklärte, die EU sei «bereit, Peking Kosten aufzuerlegen».

Salt Typhoon – eine weitere chinesische Gruppe – infiltrierte die Infrastruktur der Telekommunikation von über acht US-Anbietern, darunter CALEA-Abhörsysteme, und blieb in einigen Umgebungen bis zu drei Jahre unentdeckt. Das FBI informierte über 600 Organisationen in mehr als 80 Ländern über mögliche Kompromittierungen. ENISA warnt 2025 explizit vor sechs chinesischen APT-Gruppen (APT27, APT30, APT31, Ke3chang, GALLIUM, Mustang Panda) als «bedeutende und andauernde Bedrohungen für die EU». CrowdStrike identifiziert Vixen Panda als «die produktivste Bedrohung für europäische Regierungs- und Verteidigungseinrichtungen» (November 2025).

Der geopolitische Rahmen: Chinas zunehmende Abkopplung vom Westen und sein Anspruch auf Taiwan machen diese Positionierung strategisch: «Pre-Positioning» bedeutet, Zugänge zu kritischer Infrastruktur anzulegen, die im Ernstfall eines Taiwan-Konflikts aktiviert werden könnten – zur Ablenkung, Demoralisierung oder direkten Sabotage westlicher Unterstützungsstrukturen. Ein chinesischer Beamter deutete bei einem geheimen Treffen in Genf im Dezember 2024 an, dass die Infrastruktur-Hacks direkt mit der US-Militärunterstützung für Taiwan zusammenhingen.

Russland: Hybride Kriegsführung als Dauerzustand

Russland bleibt laut ENISA 2025 die aktivste staatlich gelenkte Bedrohung für die EU. APT28 (Fancy Bear, GRU) hat 2024 die SPD-Zentrale, tschechische Regierungsstellen und die Deutsche Flugsicherung (DFS) angegriffen, wobei letzteres allein Kosten von ca. 9 Mio. Euro verursachte. Frankreich machte im April 2025 die Gruppe APT28 für Cyberangriffe auf ein Dutzend Einrichtungen seit 2021 verantwortlich. Zu den betroffenen Zielen zählten unter anderen auch Strukturen der Olympischen Spiele 2024.

Sandworm (APT44) operiert mit seiner «BadPilot»-Kampagne seit 2022 global und war bis Dezember 2025 für destruktive Wiper-Angriffe auf Wind- und Solarparks sowie Kraftwerke in Polen verantwortlich – der erste bestätigte destruktive Angriff auf eine EU-Energieinfrastruktur. APT29 (Cozy Bear) nutzt weiterhin raffinierte Social-Engineering-Angriffe gegen EU-Diplomaten, zuletzt mit gefälschten Weinverkostungseinladungen und der neuen WINELOADER-Backdoor. Pro-russischer Hacktivismus durch NoName057(16) – im Juli 2025 durch Europol/Eurojust in «Operation Eastwood» teilweise zerschlagen – hat in Deutschland allein 14 mehrtägige DDoS-Wellen gegen ca. 230 Organisationen verursacht.

Die geopolitische Lage hat sich in wenigen Wochen grundlegend verschärft. Iranische Cybermobilisierung, chinesisches Pre-Positioning und russische hybride Kriegsführung erhöhen den Cyberdruck auf Europa. Organisationen sollten nicht darauf warten, bis Angriffe entdeckt werden. Threat Hunting bringt Klarheit, bevor ein Angriff sichtbar wird.

Proaktives Threat Hunting

Die unbequeme Wahrheit: Wie staatlich gesteuerte Cyberangriffe tatsächlich entdeckt werden

Im Alltag eines Incident Responders bestätigt sich immer wieder, was die Daten zeigen: Staatliche APT-Angriffe werden selten durch eigene Sicherheitssysteme erkannt. Mandiant M-Trends 2025 (basierend auf 450.000+ Untersuchungsstunden) zeigt: 57 % aller Kompromittierungen wurden durch externe Quellen entdeckt – nicht durch das eigene SOC oder die eigene Sicherheitsinfrastruktur. Nur 43 % der Fälle wurden intern detektiert.

Die mediane Verweildauer (Dwell Time) eines Angreifers im Netzwerk lag 2024 global bei 11 Tagen – in der EMEA-Region sogar bei 22 Tagen. Das bedeutet: Ein Angreifer bewegt sich im Schnitt fast drei Wochen unbemerkt durch Netzwerke, bevor eine Kompromittierung entdeckt wird. Bei Intrusionen, die erst durch externe Hinweise auffliegen, steigt die Dwell Time auf 26 Tage.

Warum viele Cyberangriffe nicht entdeckt werden?

Dafür gibt es drei strukturelle Ursachen:

• LOTL-Techniken: 62 % aller Bedrohungserkennungen 2024 nutzten keine Malware (CrowdStrike). Angreifer verwenden native Systemtools – PowerShell, WMI, WMIC – die signaturbasierte Systeme schlicht nicht als bösartig flaggen.
• Blinde Flecken an Perimetern: 44 % der im Jahr 2024 ausgenutzten Zero-Days zielten auf Edge-Geräte wie VPNs und Firewalls – Systeme, auf welchen typischerweise kein EDR installiert ist (Mandiant M-Trends 2025).
• Supply-Chain-Kompromittierungen: Drittanbieter-bezogene Breaches haben sich 2025 laut Verizon DBIR auf 30 % aller Fälle verdoppelt. Die Kontrollen beim Endopfer werden vollständig umgangen.

Das Präzedenzbeispiel schlechthin ist Volt Typhoon: Über fünf Jahre operierte die Gruppe unentdeckt in US-Infrastrukturen. Entdeckt wurde sie nicht durch ein SIEM, nicht durch ein EDR – sondern durch dedizierte Threat-Hunting-Teams der CISA, die aktiv nach Kompromittierungsindikatoren gesucht haben. Der SolarWinds-Angriff (Verweildauer 8–9 Monate, 18.000 kompromittierte Organisationen) flog auf, weil FireEye beim Untersuchen eines anderen Sicherheitsvorfalls zufällig auf die Supply-Chain-Kompromittierung stiess.

Auch in realen Incident-Response-Einsätzen zeigt sich dasselbe Muster: Nation-State-Vorfälle werden fast nie durch Alarme der eigenen Sicherheitssysteme aufgedeckt. Sie werden meist im Zuge eines anderen Cybervorfalls entdeckt. Etwa wenn ein Incident-Response-Team im Zusammenhang mit einem Ransomware-Angriff gerufen wird und sich in der Analyse dann ein zweiter, deutlich älteren Zugangspfad zeigt. Nicht selten erfolgt die Entdeckung auch durch Hinweise von aussen: Ein CERT, eine Behörde oder ein ausländischer Partner meldet, dass die eigene Infrastruktur als Command-and-Control-Relay missbraucht wird. Das sind keine Ausnahmen, das ist der Normalfall.

Threat Hunting durch Incident Responder: Der proaktive Ausweg

Wenn reaktive Detektion systematisch versagt, braucht es einen anderen Ansatz: proaktives Threat Hunting. Threat Hunting ist die hypothesengetriebene, aktive Suche nach bösartiger Aktivität, die bestehende Sicherheitskontrollen umgangen hat – ohne auf einen Alarm zu warten.

Der Unterschied liegt im grundlegenden Ansatz: Statt «Wir reagieren, wenn etwas auffällt» gilt «Wir gehen davon aus, dass wir bereits kompromittiert sein könnten und suchen systematisch danach.»

Warum sind gerade Incident Responder die besten Threat Hunter? Weil sie wissen, wie Angreifer denken und agieren. IR-Teams kennen die Taktiken und Techniken realer Angreifer aus zahlreichen Einsätzen und verfügen über forensische Untersuchungskompetenz bei der Analyse  subtiler Anomalien. Gleichzeitig verstehen sie Persistenzmechanismen, die herkömmliche Sicherheitsteams oft übersehen. Aus demselben Grund gelang es dem Threat-Hunting-Team der CISA – einem Kreis erfahrener Incident Responder – die Gruppe Volt Typhoon zu entdecken, während automatisierte Sicherheitssysteme versagten.

Threat Hunting durch erfahrene Incident Responder erhöht in der aktuellen Lage die Chance, laufende APT-Angriffe zu entdecken – ob iranisch, chinesisch oder russisch.

Die zentrale Frage jeder Lagebeurteilung: «Sind wir kompromittiert?»

Incident Response beantwortet die Frage «Sind wir kompromittiert?» – forensisch, systematisch und mit Kenntnis der Taktiken, Techniken und Verfahren staatlicher Angreifer-TTPs.

IR-Teams suchen gezielt nach:

• LOTL-Artefakten und anomalem Verhalten nativer Systemtools, das durch signaturbasierte Systeme nicht detektiert wird.
• Dormante Backdoors und C2-Channels in Perimeter-Geräten, Edge-Systemen und OT/ICS-Umgebungen.
• Persistenzmechanismen nach iranischem, chinesischem und russischem TTP-Muster (MITRE ATT&CK-basiert).
• Supply-Chain-Kompromittierungen und vertrauensmissbräuchlichen Zugangspfaden über Drittanbieter.
• Daten-Staging und Exfiltrations-Vorbereitung, oft wochenlang vor dem eigentlichen Angriff.

Fazit: Proaktive Aufklärung statt reaktiver Sicherheit

Die Ergebnisse dieser Analyse bestimmen die nächsten Schritte. Organisationen, die in den kommenden Wochen und Monaten unter erhöhter Cyberbedrohung stehen – und das gilt angesichts der aktuellen geopolitischen Lage für jeden kritischen Sektor in Europa –, sollten nicht darauf warten, bis Behörden oder externe Partner sie auf eine Kompromittierung hinweisen.

Was Organisationen jetzt brauchen, ist keine weitere Schicht reaktiver Sicherheitstools, sondern der proaktive Blick erfahrener Incident Responder, die Kompromittierungen gezielt aufdecken.

Proaktives Threat Hunting