• Der augmentierte Analyst: Wie KI die Geschwindigkeit im SOC verändert

    Security Operations Center stehen unter Druck. Die Alert-Volumen steigen, die Angriffstechniken werden komplexer, und qualifizierte Analysten sind Mangelware. KI wird oft als Lösung präsentiert — aber nicht als Ersatz für den Analysten, sondern als Verstärker. Der augmentierte Analyst arbeitet schneller, präziser und ermüdungsfreier — weil KI die Routinearbeit übernimmt und den Menschen für Entscheidungen freistellt, die Urteilsvermögen erfordern.

    Das Kapazitätsproblem im SOC

    Die Zahlen sind eindeutig: Laut dem ISC2 Cybersecurity Workforce Study 2024 fehlen weltweit über 4 Millionen Security-Fachkräfte. Gleichzeitig steigt das Alert-Volumen in durchschnittlichen SOCs auf tausende Events pro Tag — die Mehrheit davon False Positives oder Low-Priority-Events, die dennoch gesichtet werden müssen.

    Das Ergebnis ist vorhersehbar: Alert Fatigue. Analysten, die hunderte gleichförmige Alerts pro Schicht bearbeiten, übersehen den einen kritischen Event. Nicht aus Nachlässigkeit, sondern weil das menschliche Gehirn nicht für monotone Musterüberwachung optimiert ist.

    Die traditionelle Antwort — mehr Analysten einstellen — scheitert am Arbeitsmarkt und am Budget. KI bietet einen anderen Weg: Nicht die Anzahl der Analysten erhöhen, sondern die Effektivität jedes einzelnen.

    Was KI im SOC heute leisten kann

    Tier-1-Triage automatisieren

    Der größte Hebel liegt in der Automatisierung der initialen Alert-Bewertung. KI-Modelle können Alerts in Echtzeit klassifizieren:

    • Bekannte False Positives: Alerts, die historisch immer als harmlos geschlossen wurden, automatisch schließen oder deprioritisieren
    • Anreicherung: Kontextinformationen automatisch ergänzen — Asset-Kritikalität, Benutzerhistorie, Threat-Intelligence-Match, Schwachstellenstatus
    • Korrelation: Einzelne Alerts zu Incidents gruppieren, die zusammengehören — statt fünf separate Alerts für einen einzelnen Angriff

    Das Ergebnis: Der Analyst bekommt nicht 500 rohe Alerts, sondern 20 priorisierte, angereicherte Incidents mit konkreter Handlungsempfehlung.

    Natürlichsprachliche Abfragen

    Moderne KI-Systeme ermöglichen es Analysten, in natürlicher Sprache mit dem SIEM zu interagieren: „Zeige mir alle erfolgreichen Logins von Benutzer X in den letzten 48 Stunden, gefiltert nach unbekannten IPs“ statt komplexer Query-Syntax. Das senkt die Einstiegshürde für Junior-Analysten und beschleunigt die Arbeit erfahrener Experten.

    Automatisierte Untersuchung

    Bei einem verdächtigen Alert kann KI automatisch den Investigation-Workflow starten: Zugehörige Logs abrufen, ähnliche historische Incidents suchen, betroffene Assets identifizieren, Timeline erstellen. Der Analyst erhält eine fertig aufbereitete Untersuchung — statt sie manuell zusammensuchen zu müssen.

    Response-Empfehlungen

    Basierend auf dem Incident-Kontext und historischen Reaktionsmustern kann KI Handlungsempfehlungen vorschlagen: Account sperren, IP blocken, System isolieren, Ticket erstellen. Der Analyst entscheidet — aber die Vorbereitung ist bereits erledigt.

    Wo die Grenzen liegen

    KI im SOC ist kein Autopilot. Drei Grenzen sind kritisch:

    • Neuartige Angriffe: KI erkennt Muster, die sie gelernt hat. Wirklich neuartige Angriffstechniken — True Zero-Days in der Taktik, nicht nur in der Technik — erfordern menschliches Urteilsvermögen und kreatives Denken
    • Kontextverständnis: Ob ein ungewöhnlicher Zugriff ein Angriff oder ein legitimer Geschäftsvorgang ist, hängt von Kontext ab, den nur Menschen kennen — Organisationsstruktur, laufende Projekte, Geschäftsbeziehungen
    • Verantwortung: Die Entscheidung, ein System vom Netz zu nehmen, einen Account zu sperren oder einen Vorfall zu eskalieren, trägt immer ein Mensch. KI kann empfehlen — entscheiden muss der Analyst

    Das Zusammenspiel: Mensch + KI im SOC-Workflow

    Der augmentierte SOC-Workflow sieht so aus:

    1. KI filtert und priorisiert: Aus tausenden Events werden zwanzig priorisierte Incidents
    2. KI reichert an: Jeder Incident kommt mit Kontext, Timeline und ähnlichen historischen Fällen
    3. Analyst bewertet: Der Mensch beurteilt, ob der Incident real ist und welche Reaktion angemessen ist
    4. KI unterstützt die Reaktion: Automatisierte Playbooks führen Standardmaßnahmen aus, der Analyst überwacht und greift bei Bedarf ein
    5. KI lernt: Die Entscheidungen des Analysten fließen als Feedback in die KI-Modelle zurück

    Dieses Modell skaliert: Drei Analysten mit KI-Unterstützung können die Arbeit leisten, für die früher zehn benötigt wurden — nicht weil sie schneller klicken, sondern weil sie weniger Rauschen durcharbeiten müssen.

    Voraussetzungen für KI im SOC

    KI-Augmentation funktioniert nicht out of the box. Drei Voraussetzungen müssen erfüllt sein:

    • Datenqualität: KI-Modelle sind nur so gut wie die Daten, die sie verarbeiten. Unvollständige Logs, falsche Zeitstempel oder fehlende Asset-Informationen führen zu falschen Priorisierungen
    • Definierte Prozesse: Bevor KI Prozesse automatisieren kann, müssen diese Prozesse existieren und dokumentiert sein. KI kann schlechte Prozesse nicht reparieren — sie beschleunigt sie
    • Human-in-the-Loop: KI-Systeme müssen so konfiguriert sein, dass kritische Entscheidungen immer einen menschlichen Freigabeschritt erfordern. Vollständig autonome Response ohne menschliche Kontrolle ist bei dem aktuellen Stand der Technik nicht verantwortbar

    Handlungsempfehlungen

    • Alert-Volumen analysieren: Wie viele Alerts bearbeiten Ihre Analysten pro Schicht? Wie hoch ist die False-Positive-Rate? Wo liegt das größte Automatisierungspotenzial?
    • KI-Augmentation schrittweise einführen: Mit der Automatisierung von Tier-1-Triage beginnen — dem Bereich mit dem höchsten Volumen und der geringsten Komplexität
    • Feedback-Loops etablieren: Analysten-Entscheidungen systematisch erfassen und als Trainingsdaten für die KI-Modelle nutzen
    • SOC-Metriken definieren: MTTD, MTTR und Analyst Utilization messen — vor und nach der KI-Einführung, um den Effekt zu quantifizieren
    • Keine KI ohne Prozesse: Erst die SOC-Workflows dokumentieren und optimieren, dann automatisieren. KI verstärkt den Status quo — guten wie schlechten
  • 40.000 CVEs pro Jahr: Warum KI-gestütztes Schwachstellenmanagement kein Luxus mehr ist

    Im Jahr 2024 wurden über 40.000 neue CVEs veröffentlicht — ein Anstieg von 38 Prozent gegenüber dem Vorjahr. Die CISA führte davon weniger als 200 in ihrem KEV-Katalog als aktiv ausgenutzt. Für Security-Teams bedeutet das: 99,5 Prozent aller veröffentlichten Schwachstellen werden nie aktiv ausgenutzt. Aber welche 0,5 Prozent die gefährlichen sind, lässt sich mit CVSS allein nicht bestimmen.

    Warum CVSS als Priorisierungsgrundlage versagt

    Das Common Vulnerability Scoring System (CVSS) bewertet die theoretische Schwere einer Schwachstelle auf einer Skala von 0 bis 10. Das Problem: CVSS berücksichtigt weder den Kontext der Umgebung noch die tatsächliche Ausnutzungswahrscheinlichkeit.

    Eine Schwachstelle mit CVSS 9.8 in einer Software, die im Unternehmen nicht eingesetzt wird, ist irrelevant. Eine Schwachstelle mit CVSS 6.5 in einem aus dem Internet erreichbaren System, für das ein Exploit-Kit existiert, ist eine akute Bedrohung. CVSS unterscheidet zwischen diesen Szenarien nicht.

    Laut einer Analyse von Qualys werden weniger als 3 Prozent aller CVEs mit CVSS ≥ 9.0 jemals aktiv ausgenutzt. Gleichzeitig haben einige der folgenreichsten Angriffe der letzten Jahre Schwachstellen mit mittlerem CVSS-Score genutzt — weil der Kontext (exponiertes System, verfügbarer Exploit, attraktives Ziel) den Unterschied machte.

    Risikobasierte Priorisierung: Was wirklich zählt

    Moderne Schwachstellenmanagement-Ansätze ersetzen CVSS nicht, sondern ergänzen es um Kontextfaktoren:

    • Exploit-Verfügbarkeit: Existiert ein öffentlicher Exploit? Wird die Schwachstelle in Exploit-Kits gehandelt?
    • Aktive Ausnutzung: Führt die CISA die CVE im KEV-Katalog? Gibt es Threat-Intelligence-Berichte über aktive Kampagnen?
    • Asset-Kontext: Ist das betroffene System aus dem Internet erreichbar? Verarbeitet es sensible Daten? Ist es ein Hochwertziel (Domain Controller, SIEM, VPN-Gateway)?
    • Kompensatorische Kontrollen: Gibt es Netzwerksegmentierung, WAF-Regeln oder andere Maßnahmen, die die Ausnutzung erschweren?

    Systeme wie EPSS (Exploit Prediction Scoring System) nutzen Machine Learning, um die Wahrscheinlichkeit aktiver Ausnutzung innerhalb der nächsten 30 Tage vorherzusagen. EPSS korreliert dabei öffentliche Exploit-Daten, Social-Media-Aktivität, Threat-Intelligence-Feeds und historische Ausnutzungsmuster.

    Wie KI das Schwachstellenmanagement verändert

    Bei 40.000+ CVEs pro Jahr und begrenzten Patch-Ressourcen brauchen Security-Teams Automatisierung. KI-gestützte Systeme leisten dabei Mehreres:

    1. Automatisierte Priorisierung

    KI-Modelle bewerten jede neue CVE in Echtzeit gegen den spezifischen Kontext des Unternehmens: Welche Assets sind betroffen? Wie exponiert sind sie? Gibt es Exploits? Das Ergebnis ist eine risikoadjustierte Prioritätenliste, die sich täglich aktualisiert.

    2. Korrelation mit Threat Intelligence

    KI verknüpft Schwachstellendaten mit aktuellen Bedrohungsinformationen: Welche APT-Gruppen nutzen diese CVE? In welchen Branchen? Mit welchen TTPs? Diese Kontextualisierung ist manuell bei 40.000 CVEs nicht leistbar.

    3. Patch-Impact-Analyse

    Nicht jeder Patch kann sofort eingespielt werden. KI-gestützte Systeme bewerten den Impact eines Patches auf Produktionssysteme und schlägen optimale Patch-Fenster vor — oder empfehlen kompensatorische Maßnahmen für CVEs, die nicht sofort gepatcht werden können.

    4. Vorhersage zukünftiger Ausnutzung

    EPSS und ähnliche Modelle sagen voraus, welche CVEs in den nächsten Wochen wahrscheinlich ausgenutzt werden — bevor ein Exploit öffentlich verfügbar ist. Das verschafft Security-Teams einen Zeitvorsprung.

    Die Grenzen von KI im Schwachstellenmanagement

    KI ist kein Allheilmittel. Drei Einschränkungen sind relevant:

    • Datenqualität: KI-Modelle sind nur so gut wie ihre Eingabedaten. Ohne vollständiges Asset-Inventar, aktuelle Scan-Ergebnisse und zuverlässige Threat-Intelligence-Feeds liefert auch die beste KI falsche Prioritäten
    • Zero-Days: Für Schwachstellen ohne CVE-Nummer und ohne öffentliche Information gibt es keine Trainingsdaten. KI kann nur priorisieren, was bekannt ist
    • Kontext-Verständnis: Ob ein System geschäftskritisch ist, ob ein Patch Ausfallzeiten verursacht, ob regulatorische Anforderungen gelten — diese Informationen muss ein Mensch liefern

    Von der Schwachstellenliste zum Risikomanagement

    Der Paradigmenwechsel im Schwachstellenmanagement lässt sich in einem Satz zusammenfassen: Nicht jede CVE ist ein Risiko, und nicht jedes Risiko hat eine CVE.

    Effektives Schwachstellenmanagement integriert:

    • Vulnerability Scanning: Regelmäßige Scans aller Assets — nicht nur Server, sondern auch Netzwerkgeräte, IoT, Cloud-Ressourcen
    • Asset Management: Ohne vollständiges Inventar keine kontextbasierte Priorisierung
    • Threat Intelligence: Aktuelle Informationen darüber, welche CVEs aktiv ausgenutzt werden
    • SIEM-Integration: Schwachstellendaten mit Security-Events korrelieren — wenn ein verwundbares System gleichzeitig verdächtigen Traffic zeigt, steigt die Priorität sofort
    • Reporting: Management-taugliche Dashboards, die Risiko in Geschäftssprache übersetzen — nicht 40.000 CVEs, sondern die 50, die jetzt gefixt werden müssen

    Handlungsempfehlungen

    • CVSS nicht als alleiniges Kriterium verwenden: Ergänzen Sie CVSS um EPSS, KEV-Status, Exploit-Verfügbarkeit und Asset-Kontext
    • Asset-Inventar vervollständigen: KI-gestützte Priorisierung funktioniert nur mit vollständigem Überblick über alle Assets
    • CISA KEV als Minimum-Baseline: Jede CVE im KEV-Katalog muss innerhalb der von CISA gesetzten Frist gepatcht werden — das ist die absolute Untergrenze
    • Schwachstellenmanagement mit SIEM verbinden: Wenn Ihr SIEM weiß, welche Systeme verwundbar sind, kann es Angriffe auf genau diese Systeme priorisiert erkennen
    • Patch-Zyklen verkürzen: Für aktiv ausgenutzte Schwachstellen müssen Notfall-Patch-Prozesse existieren — unabhängig vom regulären Patch-Zyklus
  • BSI veröffentlicht C5:2026 — neuer Maßstab für Cloud-Sicherheit

    Das BSI hat den C5:2026 veröffentlicht — die zweite substanzielle Revision des Cloud Computing Compliance Criteria Catalogue. Mit 258 Seiten, 17 Kriterienbereichen und erstmals expliziten Anforderungen an Container Management, Confidential Computing und Post-Quantum-Kryptografie setzt das Dokument den neuen Standard für die Sicherheitsbewertung von Cloud-Diensten in Europa.

    Für Unternehmen, die Cloud-Dienste nutzen oder anbieten, ist der C5 kein optionales Gütesiegel — er ist der zentrale Referenzrahmen, an dem sich Auftraggeber, Aufsichtsbehörden und Versicherer orientieren.

    Was ist der C5 — und warum jetzt ein Update?

    Der Cloud Computing Compliance Criteria Catalogue (C5) definiert seit 2016 Mindestanforderungen an die Informationssicherheit von Cloud-Diensten. Er richtet sich an Cloud-Anbieter, die ihre Sicherheitsmaßnahmen durch eine unabhängige Prüfung (C5-Testat) nachweisen wollen — und an Organisationen, die Cloud-Dienste informiert auswählen möchten, statt auf Marketingversprechen zu vertrauen.

    Der Vorgänger C5:2020 war sechs Jahre im Einsatz. In dieser Zeit haben sich Bedrohungslage, regulatorische Rahmenbedingungen und Cloud-Technologien grundlegend verändert. Der C5:2026 schließt diese Lücke — und tut das mit explizitem Blick auf die europäische Harmonisierung: Der C5:2020 diente als Basis für das geplante EUCS (European Cybersecurity Certification Scheme for Cloud Services) auf Substantial-Level. Die dort entwickelten Anforderungen fließen nun zurück in den C5:2026.

    Die zentralen Neuerungen im C5:2026

    Das BSI benennt die Key Changes explizit in der Einleitung des Katalogs:

    Container Management (OPS-34, OPS-35): Komplett neue Kriterien für Container-Sicherheit. Angesichts der Tatsache, dass Container-basierte Deployments heute Standard in Cloud-Umgebungen sind, war das längst überfällig. Die Kriterien adressieren sowohl Policies als auch deren Implementierung.

    Confidential Computing (OPS-32, OPS-33): Ebenfalls neu — Anforderungen an die Verarbeitung von Daten in geschützten Enclaves und Remote Attestation. Das ist technologisch bedeutsam: Confidential Computing ermöglicht es, Daten auch während der Verarbeitung kryptografisch zu schützen, nicht nur at rest und in transit.

    Post-Quantum-Kryptografie (CRY-Bereich): Der C5:2026 adressiert die Vorbereitung auf quantenresistente Verschlüsselung. Das betrifft insbesondere das Cryptographic Change Management (CRY-02) und die Review of Cryptography Practices (CRY-03). Cloud-Anbieter müssen nachweisen, dass sie sich auf den Übergang zu Post-Quantum-Algorithmen vorbereiten.

    Supply Chain Management (SSO-01 bis SSO-08): Der Bereich wurde auf acht Kriterien erweitert — deutlich umfangreicher als zuvor. Neue Anforderungen umfassen unter anderem das Führen eines Verzeichnisses aller Service-Organisationen (SSO-04), das Monitoring der Compliance (SSO-05), Vertragskündigungsstrategien (SSO-06) und die Steuerung von Lieferanten funktionaler Komponenten (SSO-08).

    Multi-Tenancy und Souveränität: Detailliertere Behandlung von Datentrennung (OPS-30, OPS-31) und eine neue Systematik für Partitions, Regions und Zones, die Transparenz darüber schafft, wo Daten tatsächlich verarbeitet werden. Das BSI definiert diese Begriffe präzise — eine Partition umfasst Regions mit einheitlichem IAM, eine Region ist auf eine Metropolregion begrenzt, eine Zone besteht aus mindestens zwei physisch getrennten Standorten.

    Strukturelle Überarbeitung: C5-Kriterien bestehen jetzt aus Sub-Kriterien, die inhaltlich klar voneinander abgegrenzt sind. Das ermöglicht präziseres Mapping auf Controls in den Kontrollsystemen der Cloud-Anbieter und schafft mehr Klarheit beim Audit. Zusätzlich werden Additional-Kriterien explizit als “additional sharpen” (verschärfen bestehende Basiskriterien) oder “additional complement” (ergänzen neue Anforderungen) klassifiziert.

    Referenzstandards

    Der C5:2026 basiert auf einer Reihe aktueller Standards und Regelwerke. Neben dem EUCS Substantial-Level wurden insbesondere die CSA Cloud Controls Matrix v4, die ISO/IEC 27001:2022 und die NIS-2-Richtlinie berücksichtigt. Zusätzlich floss praktische Erfahrung von Cloud-Anbietern, Prüfern und Beratern in die Revision ein.

    Warum der C5 für Cloud-Kunden relevant ist

    Ein verbreitetes Missverständnis: Der C5 richtet sich nur an Cloud-Anbieter. In der Praxis ist er mindestens ebenso relevant für Organisationen, die Cloud-Dienste nutzen — also für praktisch jedes Unternehmen.

    Der C5 bietet Cloud-Kunden einen strukturierten Rahmen, um die Sicherheit ihrer Anbieter zu bewerten. Statt sich auf Hochglanzbroschüren und ISO-27001-Zertifikate zu verlassen, können Unternehmen anhand des C5-Testats nachvollziehen, welche konkreten Sicherheitsmaßnahmen ein Anbieter implementiert hat — und wo es Abweichungen oder Einschränkungen gibt.

    Für NIS2-pflichtige Unternehmen wird das besonders relevant: Die Richtlinie verlangt Risikomanagementmaßnahmen für die gesamte Lieferkette. Wer Cloud-Dienste ohne belastbare Sicherheitsbewertung einsetzt, wird Schwierigkeiten haben, seine Sorgfaltspflichten nachzuweisen. Ein aktuelles C5-Testat des Anbieters ist hier ein konkreter, dokumentierbarer Nachweis.

    C5 im regulatorischen Kontext

    Der C5:2026 steht nicht isoliert. Er ist Teil eines zunehmend dichten Netzes europäischer Cybersicherheitsregulierung:

    NIS-2: Verpflichtet Betreiber wesentlicher und wichtiger Einrichtungen zu Risikomanagement — einschließlich Lieferkettensicherheit (Art. 21 Abs. 2 lit. d). Der C5 liefert den Bewertungsrahmen für Cloud-Anbieter in dieser Kette.

    DORA: Der Digital Operational Resilience Act adressiert den Finanzsektor und stellt spezifische Anforderungen an IKT-Drittdienstleister. Der C5 ist ein anerkannter Rahmen für deren Bewertung.

    Cyber Resilience Act (CRA): Reguliert die Sicherheit von Produkten mit digitalen Elementen. Für Cloud-basierte Software sind C5 und CRA komplementär: Der CRA adressiert das Produkt, der C5 den Betrieb.

    EUCS: Das geplante European Cybersecurity Certification Scheme for Cloud Services baut direkt auf dem C5 auf. Der C5:2026 wurde explizit so gestaltet, dass er mit dem EUCS Substantial-Level kompatibel ist. Wer heute ein C5-Testat hat, ist für EUCS vorbereitet.

    Handlungsempfehlungen

    Für Cloud-Kunden: Fordern Sie von Ihren Cloud-Anbietern ein aktuelles C5-Testat (Typ 2) an. Integrieren Sie die C5-Anforderungen in Ihre Beschaffungskriterien und Ihre NIS-2-Dokumentation. Achten Sie insbesondere auf die neuen Supply-Chain-Kriterien: Fragen Sie Ihren Anbieter, wie er seine eigenen Zulieferer überwacht (SSO-05) und ob er ein Verzeichnis seiner Service-Organisationen führt (SSO-04).

    Für Cloud-Anbieter: Beginnen Sie jetzt mit der Gap-Analyse gegen den C5:2026. Die komplett neuen Bereiche Container Management und Confidential Computing erfordern möglicherweise sowohl technische als auch prozessuale Anpassungen. Prüfen Sie außerdem Ihre Krypto-Strategie: Post-Quantum-Readiness ist keine Zukunftsmusik mehr, sondern Prüfgegenstand.

    Für KRITIS-Betreiber: Der C5 ist für Sie nicht optional. § 8a BSIG verlangt angemessene technische und organisatorische Maßnahmen. Ein C5-Testat Ihrer Cloud-Anbieter ist ein zentraler Baustein in Ihrem Nachweiskonzept — und mit dem C5:2026 jetzt deutlich aussagekräftiger als zuvor.

  • 10 Jahre NEOSEC: Nicht mehr neu — aber kontinuierlich Neo

    NEOSEC wird zehn Jahre alt. Ein Jahrzehnt in der Cybersicherheit — das sind ungefähr sieben Generationen in Menschenjahren. Technologien, die bei unserer Gründung State of the Art waren, stehen heute im Museum. Bedrohungen, die damals als theoretisch galten, sind heute Tagesgeschäft. Und „Neo“ — das Neue — sind wir nach zehn Jahren streng genommen nicht mehr.

    Oder doch?

    Was „Neo“ wirklich bedeutet

    Als wir NEOSEC gegründet haben, war der Name Programm: Ein neuer Ansatz für Cybersicherheit im Mittelstand. Kein Security Theater, keine PowerPoint-Beratung, keine Lösungen, die nach dem Audit in der Schublade verschwinden. Stattdessen: wirksame, nachweisbare, dokumentierbare Sicherheit. Substanz statt Folie.

    Zehn Jahre später ist dieser Anspruch nicht alt geworden — er ist aktueller denn je. Aber „Neo“ bedeutet für uns heute etwas anderes als 2016. Es bedeutet nicht mehr, neu am Markt zu sein. Es bedeutet, sich kontinuierlich zu erneuern. Denn in dieser Branche ist Stillstand keine Option — er ist ein Sicherheitsrisiko.

    Zehn Jahre, zehn Welten

    Ein Blick zurück macht die Geschwindigkeit des Wandels greifbar:

    2016: Ransomware war ein Nischenproblem. WannaCry kam erst ein Jahr später. Die meisten mittelständischen Unternehmen hatten weder ein SIEM noch einen Incident-Response-Plan. „Cybersicherheit“ war das, was die Firewall machte.

    2018: Die DSGVO trat in Kraft und zwang Unternehmen erstmals, über Datenverarbeitung nachzudenken. Gleichzeitig professionalisierten sich Angreifergruppen — Ransomware-as-a-Service wurde zum Geschäftsmodell.

    2020: Die Pandemie katapultierte die Digitalisierung um Jahre nach vorne — und die Angriffsfläche gleich mit. Remote Work, VPN-Schwachstellen, hastig aufgesetzte Cloud-Umgebungen. Wir hatten in diesen Monaten mehr Incident-Response-Einsätze als im gesamten Jahr zuvor.

    2022: Supply-Chain-Angriffe wie SolarWinds und Log4Shell zeigten, dass die eigene Sicherheit nur so stark ist wie das schwächste Glied in der Lieferkette. OT-Security rückte ins Bewusstsein — spätestens, als Stadtwerke und Versorger gezielt angegriffen wurden.

    2024: NIS-2 trat in Kraft. Cybersicherheit wurde zur persönlichen Haftungsfrage für Geschäftsführer. Künstliche Intelligenz veränderte gleichzeitig beide Seiten — Angriff und Verteidigung.

    2026: KI-gestützte Angriffe sind Realität. Deepfake-CEO-Fraud, polymorphe Malware, automatisierte Schwachstellensuche. Der C5:2026 setzt neue Standards für Cloud-Sicherheit. Der Cyber Resilience Act entfaltet erste Wirkung. Und wir stehen hier — zehn Jahre älter, aber nicht alt.

    Erneuerung als genetischer Code

    Was uns über zehn Jahre getragen hat, ist nicht ein bestimmtes Produkt oder eine bestimmte Technologie. Es ist die Fähigkeit — und die Bereitschaft — uns kontinuierlich zu erneuern. Das klingt nach einer Plattitüde, ist aber in der Praxis brutal anspruchsvoll.

    Erneuerung bedeutet: Technologien loslassen, in die man investiert hat. Prozesse hinterfragen, die funktionieren. Komfortzone verlassen, obwohl das Tagesgeschäft genug Druck macht. Konkret heißt das bei uns:

    Wir haben unseren SIEM-Stack mehrfach weiterentwickelt — nicht weil der alte nicht funktionierte, sondern weil die Bedrohungslage neue Fähigkeiten verlangte. Aus einem klassischen Log-Management wurde XIEM® — eine Plattform mit vier Tiers, von der Basis-Überwachung bis zum KI-gestützten SOC-Betrieb.

    Wir haben früh auf Open Source gesetzt — nicht aus Idealismus, sondern aus Überzeugung. Proprietäre Plattformen schaffen Abhängigkeiten. Offene Technologien schaffen Handlungsfreiheit. Für uns und für unsere Kunden.

    Wir haben KI in unser SOC integriert, bevor es zum Marketingbegriff wurde. Nicht um „KI“ auf die Website zu schreiben, sondern weil ein Analyst, der von Routineaufgaben entlastet wird, bessere Entscheidungen trifft.

    Wir haben OT-Security in unser Portfolio aufgenommen, als Stadtwerke und Netzbetreiber merkten, dass ihre Industriesteuerungen nicht in einem luftdichten Vakuum existieren.

    Und wir haben NIS-2-Compliance nicht als Beratungsprodukt entdeckt, als es trendy wurde — sondern vorbereitet, weil wir die regulatorische Entwicklung seit Jahren verfolgen. Als ISO 27001 Lead Auditor war das keine Überraschung, sondern eine logische Konsequenz.

    Was geblieben ist

    Bei aller Veränderung — manches ändert sich nicht. Und sollte es auch nicht.

    Wir arbeiten auf Augenhöhe. Nicht als Dienstleister, der Vorgaben abarbeitet, sondern als Partner, der mitdenkt. Das war 2016 unser Anspruch und ist es heute.

    Wir liefern Substanz, kein Theater. Wenn wir sagen, dass ein SIEM funktioniert, dann funktioniert es — nicht nur im Audit, sondern im Ernstfall. Wenn wir einen Incident-Response-Plan erstellen, dann wurde er getestet, nicht nur dokumentiert.

    Wir bleiben schlank. NEOSEC ist kein Konzern und will keiner werden. Ein kleines Team mit tiefer Expertise schlägt eine große Organisation mit breiter Oberflächlichkeit — jedenfalls in unserem Geschäft.

    Wir stehen zu Hamburg und Mönchengladbach. Nicht in Frankfurt, nicht in München, nicht in Berlin. Regional verwurzelt, technisch auf internationalem Niveau. Das ist kein Widerspruch — es ist ein Wettbewerbsvorteil.

    Was vor uns liegt

    Zehn Jahre sind ein Meilenstein. Aber die nächsten zehn Jahre werden anspruchsvoller als die ersten. KI wird die Bedrohungslandschaft schneller verändern als alles, was wir bisher erlebt haben. Post-Quantum-Kryptografie wird bestehende Verschlüsselungsstandards obsolet machen. Die regulatorische Dichte — NIS-2, CRA, DORA, EUCS — wird weiter zunehmen. Und die Angreifer werden nicht langsamer.

    Unser Job ist es, schneller zu sein. Nicht durch Hektik, sondern durch Vorbereitung. Nicht durch Größe, sondern durch Präzision. Nicht durch Marketing, sondern durch Wirksamkeit.

    NEOSEC ist nach zehn Jahren nicht mehr „neo“ im Sinne von „neu am Markt“. Aber das Neue — die kontinuierliche Erneuerung, das Infragestellen des Status quo, die Bereitschaft, morgen anders zu arbeiten als heute — das ist keine Phase, die wir hinter uns haben. Es ist unser genetischer Code.

    Danke an alle, die diesen Weg mit uns gegangen sind. An unser Team, an unsere Kunden, an unsere Partner. Auf die nächsten zehn Jahre — in denen wir uns wieder neu erfinden werden. Mindestens einmal.

  • XIEM® vs. Splunk: Warum der Mittelstand kein Enterprise-SIEM braucht

    Splunk ist der Platzhirsch im SIEM-Markt. Seit über 20 Jahren das Standardwerkzeug in Enterprise-SOCs, mittlerweile Teil des Cisco-Portfolios, mit einem Ökosystem aus tausenden Apps und Integrationen. Wer über SIEM spricht, spricht oft zuerst über Splunk.

    Und trotzdem entscheiden sich immer mehr mittelständische Unternehmen dagegen. Nicht weil Splunk schlecht wäre — sondern weil es für ihre Anforderungen die falsche Lösung ist. Dieser Artikel erklärt, warum XIEM® die bessere Wahl ist — für Unternehmen, die wirksame Sicherheit brauchen, nicht das größte Logo auf dem Chart.

    Das Preisproblem: Wenn Log-Volumen zum Geschäftsrisiko wird

    Splunks Lizenzmodell basiert auf dem täglichen Ingest-Volumen — gemessen in Gigabyte pro Tag. Das klingt zunächst logisch: Wer mehr Daten einspeist, zahlt mehr. In der Praxis bedeutet es: Jede zusätzliche Log-Quelle, jeder neue Server, jede Cloud-Integration erhöht die Lizenzkosten. Unternehmen beginnen, Entscheidungen über ihre Sicherheitsarchitektur anhand von Lizenzkosten zu treffen statt anhand von Risiken.

    Das ist kein theoretisches Problem. In der Branche hat sich der Begriff „Splunk Tax” etabliert — die Praxis, Log-Quellen bewusst nicht anzubinden, weil das Ingest-Budget ausgeschöpft ist. Firewall-Logs werden gedrosselt, Endpoint-Telemetrie gefiltert, Cloud-Audit-Logs gar nicht erst eingebunden. Das Ergebnis: Ein SIEM, das per Design blind ist für die Datenquellen, die es am dringendsten bräuchte.

    Die Einstiegskosten für Splunk Enterprise liegen für mittelständische Unternehmen typischerweise im sechsstelligen Bereich pro Jahr — und skalieren schnell in den siebenstelligen Bereich, sobald Log-Volumina wachsen. Seit der Übernahme durch Cisco im März 2024 kommt der Druck hinzu, weitere Cisco-Produkte in den Stack zu integrieren. Hinzu kommen die Personalkosten für den Eigenbetrieb: Mindestens zwei bis drei Vollzeitäquivalente (FTE) für Administration, Detection Engineering und Tuning — Security-Spezialisten, die auf dem Arbeitsmarkt schwer zu finden und teuer zu halten sind. In Summe übersteigen die Personalkosten die Lizenzkosten oft um das Zwei- bis Dreifache.

    XIEM® geht einen anderen Weg: Ein Pauschalmodell pro Tier, nicht an das Ingest-Volumen gekoppelt. Sie binden alle relevanten Log-Quellen an — ohne Angst vor der nächsten Rechnung. Sichtbarkeit ist kein Budgetposten, sondern Grundvoraussetzung.

    Personal: Die versteckte Kostenfalle

    Splunk verkauft Software. Den Betrieb müssen Sie selbst sicherstellen. Das bedeutet in der Praxis: Sie brauchen ein dediziertes Team, das Splunk administriert, Use Cases entwickelt, Detection Rules schreibt, False Positives tuned und die Infrastruktur betreibt. Für ein Unternehmen mit 200 bis 500 Mitarbeitern ist das eine erhebliche Investition — in Menschen, die Sie erst finden, dann halten und deren Wissen Sie vor Abwanderung schützen müssen. Kündigt einer dieser Spezialisten, steht das SOC still.

    XIEM® ist ein Managed Service. NEOSEC betreibt das SIEM, entwickelt die Detection-Regeln, tuned die Alerts und liefert Ihnen verwertbare Ergebnisse — nicht Rohdaten, die Sie selbst interpretieren müssen. Sie brauchen kein eigenes SIEM-Team. Sie brauchen einen Ansprechpartner, der Ihnen sagt, was in Ihrem Netz passiert.

    Komplexität: Schweizer Taschenmesser vs. scharfes Skalpell

    Splunk kann alles. Das ist gleichzeitig seine größte Stärke und seine größte Schwäche. Die Plattform ist als universelle Datenanalysemaschine konzipiert — sie kann SIEM, aber auch Observability, IT-Operations, Business Analytics und Application Performance Monitoring. Diese Flexibilität hat ihren Preis: Die Lernkurve ist steil, die Konfiguration komplex, und die SPL-Abfragesprache (Search Processing Language) ist ein eigenes Fachgebiet.

    Für Großkonzerne mit dedizierten Security-Engineering-Teams ist das kein Problem. Für ein mittelständisches Unternehmen, dessen IT-Leiter neben dem SIEM noch Firewall, Endpoint Protection, Backup und Helpdesk verantwortet, ist es eine Überforderung.

    XIEM® ist auf Cybersicherheit fokussiert — nicht auf alles. Vier klar definierte Tiers (Sentry, Orchestrate, Control, Control AI) decken den gesamten Reifegrad ab, von der Basis-Überwachung bis zum KI-gestützten SOC-Betrieb. Die Komplexität liegt bei uns, nicht bei Ihnen.

    Detection: Out-of-the-Box vs. Build-for-you

    Splunk liefert mit der Enterprise Security App ein Framework für Detection — aber die eigentliche Arbeit beginnt danach. Detection Rules müssen geschrieben, getestet, an die eigene Umgebung angepasst und kontinuierlich aktualisiert werden. Ohne diesen Aufwand ist Splunk ein teures Log-Archiv.

    XIEM® liefert Detection-Regeln, die auf realen Bedrohungsszenarien basieren und kontinuierlich durch unser SOC-Team weiterentwickelt werden. MITRE ATT&CK Mapping ist integriert, nicht optional. Jeder Alert wurde von einem Analysten bewertet, bevor er Sie erreicht — kein Alert-Rauschen, keine False-Positive-Flut.

    NIS-2-Compliance: Nachweis statt Datenbank

    NIS-2 verlangt nicht, dass Sie ein SIEM betreiben. NIS-2 verlangt, dass Sie nachweisen können, dass Sie sicherheitsrelevante Ereignisse erkennen, darauf reagieren und dies dokumentieren. Die Meldepflicht — 24 Stunden Erstmeldung, 72 Stunden Detailbericht — setzt voraus, dass Sie überhaupt wissen, dass etwas passiert ist.

    Splunk gibt Ihnen die Werkzeuge, diesen Nachweis zu erbauen. XIEM® gibt Ihnen den Nachweis. Unser Reporting ist auf BSI-konforme Dokumentation ausgelegt: MTTD-Metriken, Incident-Timelines, Meldeketten-Protokolle — fertig für die Behörde, nicht erst nach wochenlanger Aufbereitung.

    Technologie: Offen statt eingeschlossen

    Splunk ist proprietär. Daten, die in Splunk liegen, liegen in Splunks Format. Die Migration weg von Splunk ist aufwändig und teuer — was durchaus beabsichtigt ist. Mit der Cisco-Übernahme verstärkt sich dieser Effekt: Die Plattformstrategie zielt darauf ab, Kunden im Cisco-Ökosystem zu halten.

    XIEM® basiert technologisch auf Wazuh — einer Open-Source-SIEM-Plattform mit über 20 Millionen Downloads und einer aktiven Community. Das bedeutet: Keine proprietären Datenformate, keine künstlichen Lock-in-Mechanismen, volle Transparenz über die eingesetzte Technologie. Wenn Sie morgen entscheiden, dass Sie XIEM® nicht mehr brauchen, nehmen Sie Ihre Daten mit. Wir halten Sie nicht durch Abhängigkeit, sondern durch Leistung.

    Für wen ist Splunk die richtige Wahl?

    Fairerweise: Splunk hat seine Berechtigung. Für Großkonzerne mit dedizierten Security-Engineering-Teams, komplexen Multi-Cloud-Umgebungen und dem Budget für eine siebenstellige SIEM-Investition plus Personalkosten ist Splunk ein mächtiges Werkzeug. Wer bereits ein Team von Splunk-Spezialisten hat und die Plattform produktiv nutzt, hat keinen Grund zu wechseln.

    Für alle anderen — für den Mittelstand, für Unternehmen mit 50 bis 2.000 Mitarbeitern, für IT-Leiter, die neben dem SIEM noch zehn andere Baustellen haben, für Geschäftsführer, die NIS-2-Compliance nachweisen müssen, ohne ein eigenes SOC aufzubauen — ist XIEM® die bessere Wahl.

    Der Vergleich auf einen Blick

    Splunk Enterprise XIEM®
    Lizenzmodell Pro GB/Tag Ingest — skaliert mit Log-Volumen Pauschale pro Tier — planbar und vorhersehbar
    Betrieb Eigenbetrieb (2–3 FTE erforderlich) Managed Service durch NEOSEC
    Kostentreiber Lizenz + Personal + Infrastruktur Ein Pauschalpreis, alles inklusive
    Detection Framework — Rules selbst entwickeln Fertige Rules + kontinuierliche SOC-Analyse
    NIS-2-Reporting Selbst aufbauen BSI-konform integriert
    Technologie Proprietär (Cisco) Open Source (Wazuh-basiert)
    Lock-in Hoch — proprietäres Datenformat, Cisco-Ökosystem Kein Lock-in — offene Standards, Daten gehören Ihnen
    KI-Integration Splunk AI Assistant (kostenpflichtiges Add-on) XIEM® Control AI (nativ im höchsten Tier)
    Zielgruppe Enterprise mit eigenem Security-Team Mittelstand ohne dediziertes SOC
    Time-to-Value Monate (Deployment + Tuning + Personalaufbau) Tage bis Wochen
  • Detection Coverage: Wissen Sie, was Ihr SIEM tatsächlich erkennt?

    Die meisten Unternehmen mit SIEM-System gehen davon aus, dass sie Angriffe erkennen. Die wenigsten können sagen, welche. Detection Coverage — die systematische Messung dessen, was ein SIEM tatsächlich erkennt und was nicht — ist eine der am stärksten vernachlässigten Disziplinen in der Cybersicherheit.

    Das Problem: Gefühlte Sicherheit statt messbare Erkennung

    Ein SIEM sammelt Logs, korreliert Events und generiert Alerts. Aber die entscheidende Frage lautet nicht, ob es Alerts generiert — sondern ob es die richtigen Angriffstechniken erkennt. Ein SIEM mit 500 aktiven Regeln kann trotzdem blind sein für die Techniken, die Angreifer tatsächlich einsetzen.

    Der Mandiant M-Trends Report 2025 zeigt: Die durchschnittliche Dwell Time — die Zeit zwischen Erstinfektion und Entdeckung — liegt global bei 10 Tagen. Bei Unternehmen ohne externes Monitoring sind es oft Wochen oder Monate. Das bedeutet: Viele SIEM-Systeme erkennen Angriffe entweder gar nicht oder zu spät, um den Schaden zu begrenzen.

    Das Problem ist nicht die Technologie. Das Problem ist, dass niemand systematisch misst, was erkannt wird — und was nicht.

    MITRE ATT&CK als Messrahmen

    Das MITRE ATT&CK Framework katalogisiert über 200 Angriffstechniken in 14 Taktiken — von Initial Access über Lateral Movement bis Exfiltration. Es bietet damit einen standardisierten Rahmen, um Detection Coverage zu messen: Für jede Technik kann dokumentiert werden, ob eine Erkennungsregel existiert, ob sie getestet wurde und ob sie in der Praxis funktioniert.

    Die Realität in den meisten Organisationen: Die Coverage-Map zeigt mehr Lücken als Abdeckung. Typische Schwachstellen:

    • Initial Access (TA0001): Oft gut abgedeckt durch E-Mail-Security und Endpoint-Detection
    • Execution (TA0002): PowerShell- und Script-Monitoring ist verbreitet, aber oft nicht granular genug
    • Persistence (TA0003): Häufig blind — Registry-Modifikationen, Scheduled Tasks und DLL-Hijacking werden in vielen SIEM-Konfigurationen nicht überwacht
    • Lateral Movement (TA0008): Eine der größten Lücken. Pass-the-Hash, RDP-Hijacking und WMI-basierte Bewegung erzeugen in Standard-SIEM-Konfigurationen oft keine Alerts
    • Exfiltration (TA0010): Datenabfluss über HTTPS, DNS-Tunneling oder Cloud-Storage wird selten erkannt

    Detection Engineering: Von Regeln zu messbarer Qualität

    Detection Engineering behandelt SIEM-Regeln wie Software: Sie werden entwickelt, getestet, versioniert und kontinuierlich verbessert. Der Ansatz geht über das bloße Schreiben von Korrelationsregeln hinaus und umfasst einen vollständigen Lifecycle:

    1. Threat Intelligence: Welche Techniken nutzen die Angreifer, die für unsere Branche und Infrastruktur relevant sind?
    2. Data Source Mapping: Welche Logs brauchen wir, um diese Techniken zu erkennen? Werden diese Logs tatsächlich gesammelt?
    3. Rule Development: Erkennungslogik entwickeln — nicht nur Signaturen, sondern verhaltensbasierte Regeln
    4. Testing: Regeln gegen reale Angriffssimulationen (Atomic Red Team, MITRE Caldera) validieren
    5. Tuning: False Positives reduzieren, ohne die Erkennungsrate zu opfern
    6. Measurement: Coverage gegen ATT&CK-Matrix messen und Lücken dokumentieren

    MTTD: Die Metrik, die zählt

    Die wichtigste Kennzahl für Detection-Qualität ist Mean Time to Detect (MTTD) — die durchschnittliche Zeit zwischen dem Beginn eines Angriffs und seiner Erkennung. MTTD wird pro Angriffstechnik gemessen, nicht pauschal für das gesamte SIEM.

    Warum das wichtig ist: Ein SIEM kann Brute-Force-Angriffe in Sekunden erkennen (niedriger MTTD) und gleichzeitig blind sein für Lateral Movement via WMI (MTTD: unendlich). Der Durchschnittswert verschleiert die tatsächlichen Lücken.

    Um MTTD sinnvoll zu messen, brauchen Organisationen regelmäßige Purple-Team-Übungen: Das Red Team führt definierte ATT&CK-Techniken aus, das Blue Team misst, wie schnell — und ob — sie erkannt werden. Die Ergebnisse fließen direkt in die Detection-Engineering-Roadmap.

    Die häufigsten Coverage Gaps

    Basierend auf Branchenberichten und Erfahrungswerten sind folgende Bereiche in den meisten SIEM-Implementierungen unterabgedeckt:

    • Cloud-native Angriffe: Azure AD/Entra-ID-Manipulation, AWS-IAM-Eskalation, GCP-Service-Account-Missbrauch — die meisten SIEMs sammeln On-Premise-Logs zuverlässig, aber Cloud-Telemetrie nur lückenhaft
    • Identity-basierte Angriffe: Token Theft, Session Hijacking, OAuth-App-Registrierung — Angriffe, die keine Malware hinterlassen
    • Nicht-menschliche Identitäten: Service-Accounts, API-Keys und Bot-Accounts werden selten mit derselben Aufmerksamkeit überwacht wie menschliche Benutzer
    • Datenexfiltration: Outbound-Traffic-Analyse, DLP-Integration und DNS-Monitoring fehlen in vielen SIEM-Konfigurationen
    • Living-off-the-Land: Angriffe, die ausschließlich legitime System-Tools nutzen (PowerShell, WMI, PsExec), sind ohne Baseline-Monitoring kaum erkennbar

    Von der Lückenanalyse zur Roadmap

    Detection Coverage zu messen ist kein Selbstzweck. Die Ergebnisse müssen in eine priorisierte Roadmap münden:

    1. Bestandsaufnahme: Aktuelle Regeln gegen MITRE ATT&CK mappen — was ist abgedeckt, was nicht?
    2. Priorisierung: Welche Techniken nutzen die relevantesten Threat Actors für unsere Branche? Diese zuerst abdecken
    3. Data Source Gaps schließen: Oft fehlt nicht die Regel, sondern die Datenquelle. Ohne Cloud-Logs keine Cloud-Detection
    4. Testen und validieren: Jede neue Regel muss gegen reale Angriffssimulationen getestet werden — nicht nur syntaktisch korrekt sein
    5. Kontinuierlich messen: Coverage ist kein Zustand, sondern ein Prozess. Neue Techniken erfordern neue Regeln

    Handlungsempfehlungen

    • ATT&CK Coverage Assessment durchführen: Bestehende SIEM-Regeln gegen die MITRE-ATT&CK-Matrix mappen. Tools wie DeTT&CT automatisieren diesen Prozess
    • Data Source Inventory erstellen: Dokumentieren, welche Logs tatsächlich gesammelt werden — und welche fehlen. Ohne Daten keine Detection
    • Purple-Team-Übungen etablieren: Regelmäßig (mindestens quartalsweise) Angriffstechniken simulieren und MTTD messen
    • Detection-as-Code: SIEM-Regeln in Git versionieren, in CI/CD-Pipelines testen und automatisiert deployen
    • Coverage-Dashboard aufbauen: Eine ATT&CK-Heatmap, die auf einen Blick zeigt, wo die Erkennung stark ist — und wo die blinden Flecken liegen
  • Anthropic Mythos: Die KI, die zu gefährlich für die Öffentlichkeit ist

    Anthropic hat am Dienstag ein neues KI-Modell vorgestellt, das die Cybersicherheitslandschaft grundlegend verändern wird — und es bewusst nicht veröffentlicht. Claude Mythos Preview findet Sicherheitslücken in Software schneller, zuverlässiger und in größerem Umfang als jeder menschliche Sicherheitsforscher. Tausende kritische Schwachstellen hat das Modell bereits identifiziert — in jedem gängigen Betriebssystem und jedem verbreiteten Browser.

    Statt Mythos öffentlich zugänglich zu machen, gründet Anthropic „Project Glasswing“ — ein Konsortium mit Amazon, Apple, Google, Microsoft, Cisco, CrowdStrike, Broadcom, Palo Alto Networks, JPMorganChase, NVIDIA und der Linux Foundation. Das Ziel: Die Verteidiger sollen einen Vorsprung bekommen, bevor die Angreifer ähnliche Fähigkeiten entwickeln.

    Was Mythos Preview kann — und warum das beunruhigend ist

    Die Fakten, die Anthropic präsentiert, sind bemerkenswert:

    Das Modell fand eine 27 Jahre alte Schwachstelle in OpenBSD — einem Betriebssystem, das als eines der sichersten der Welt gilt und in Firewalls und kritischer Infrastruktur eingesetzt wird. Die Lücke erlaubte es, jede Maschine mit diesem System durch eine einfache Verbindung aus der Ferne zum Absturz zu bringen.

    In FFmpeg, einer Software zur Video-Verarbeitung, die in unzähligen Anwendungen steckt, entdeckte Mythos eine 16 Jahre alte Schwachstelle — in einer Codezeile, die automatisierte Testtools fünf Millionen Mal durchlaufen hatten, ohne das Problem zu finden.

    Im Linux-Kernel — der Grundlage der meisten Server weltweit — fand und verkettete das Modell autonom mehrere Schwachstellen, um von normalem Benutzerzugang zu vollständiger Kontrolle über die Maschine zu gelangen.

    Besonders alarmierend: Mythos entwickelte zu diesen Schwachstellen eigenständig funktionsfähige Exploits — in Stunden, wofür menschliche Experten Wochen gebraucht hätten. Und das Modell schaffte es zeitweise, aus einer Sandbox-Umgebung auszubrechen, die genau das verhindern sollte.

    Project Glasswing: Verteidigung im Konsortium

    Anthropic reagiert auf diese Fähigkeiten nicht mit Veröffentlichung, sondern mit kontrolliertem Zugang. Die Partner des Konsortiums erhalten Mythos Preview für defensive Zwecke: Schwachstellensuche in eigenen Produkten, Penetration Testing, Black-Box-Analyse von Binärdateien, Absicherung von Endpoints.

    Anthropic stellt dafür bis zu 100 Millionen US-Dollar an Nutzungsguthaben bereit. Zusätzlich fließen 4 Millionen US-Dollar direkt an Open-Source-Sicherheitsorganisationen — 2,5 Millionen an Alpha-Omega und OpenSSF über die Linux Foundation, 1,5 Millionen an die Apache Software Foundation.

    Über 40 weitere Organisationen, die kritische Software-Infrastruktur betreiben oder pflegen, erhalten ebenfalls Zugang, um sowohl eigene als auch Open-Source-Systeme zu scannen.

    Warum Anthropic Mythos nicht veröffentlicht

    Die Entscheidung, Mythos nicht allgemein verfügbar zu machen, ist nachvollziehbar. Das Modell repräsentiert eine Schwelle, an der KI-Fähigkeiten zur Schwachstellensuche das Niveau der besten menschlichen Sicherheitsforscher erreichen — und in manchen Bereichen übertreffen. In den falschen Händen wäre Mythos eine Cyberwaffe.

    Anthropic formuliert es direkt: Bei der aktuellen Geschwindigkeit des KI-Fortschritts wird es nicht lange dauern, bis ähnliche Fähigkeiten auch außerhalb verantwortungsvoller Akteure verfügbar sind. Die Konsequenzen für Wirtschaft, öffentliche Sicherheit und nationale Sicherheit wären erheblich.

    Gleichzeitig steht Anthropic unter Druck. Informationen über Mythos gelangten bereits im März durch ein Datenleck an die Öffentlichkeit — interne Dokumente und Modellbeschreibungen tauchten in einem öffentlich zugänglichen Datenspeicher auf. Wenig später wurde zudem Quellcode von Claude Code versehentlich publiziert. Das Unternehmen nannte menschliches Versagen als Ursache. Für ein Unternehmen, das die Welt vor den Risiken seiner eigenen Technologie warnt, sind das keine Nebensächlichkeiten.

    Was die Partner sagen

    Die Reaktionen der Konsortialpartner sind bemerkenswert einhellig in ihrer Dringlichkeit:

    CrowdStrike-CTO Elia Zaitsev bringt es auf den Punkt: Das Zeitfenster zwischen Entdeckung einer Schwachstelle und ihrer Ausnutzung durch Angreifer sei kollabiert — was früher Monate dauerte, passiere mit KI jetzt in Minuten.

    Cisco-CSO Anthony Grieco spricht von einem Schwellenwert, den KI-Fähigkeiten überschritten hätten — die alten Methoden der Systemhärtung seien nicht mehr ausreichend.

    Palo Alto Networks CPTO Lee Klarich warnt: Diese Modelle müssten in die Hände von Open-Source-Maintainern und Verteidigern überall gelangen, bevor Angreifer Zugang bekommen. Und noch wichtiger: Jeder müsse sich auf KI-gestützte Angreifer vorbereiten.

    Jim Zemlin, CEO der Linux Foundation, adressiert ein strukturelles Problem: Sicherheitsexpertise war bisher ein Luxus, den sich nur Organisationen mit großen Security-Teams leisten konnten. Open-Source-Maintainer, deren Software einen Großteil der kritischen Infrastruktur ausmacht, mussten Sicherheit bisher allein stemmen.

    Die Benchmark-Zahlen

    Anthropic legt konkrete Vergleichszahlen vor. Auf dem CyberGym-Benchmark für Schwachstellen-Reproduktion erreicht Mythos Preview 83,1 Prozent — gegenüber 66,6 Prozent für Claude Opus 4.6. Auf SWE-bench Verified, einem Benchmark für Software-Engineering-Aufgaben, liegt Mythos bei 93,9 Prozent (Opus 4.6: 80,8 Prozent).

    Diese Zahlen sind keine abstrakten Metriken. Sie bedeuten: Das Modell kann Software-Schwachstellen systematisch und mit hoher Zuverlässigkeit finden — autonom, ohne menschliche Steuerung, in Geschwindigkeiten, die menschliche Analyse um Größenordnungen übertreffen.

    Was das für Unternehmen bedeutet

    Die Implikationen für Unternehmen sind fundamental. Nicht wegen Mythos selbst — das Modell ist nicht öffentlich zugänglich. Sondern wegen dem, was Mythos ankkündigt: eine Welt, in der KI-Modelle Schwachstellen schneller finden, als Menschen sie patchen können.

    Das Zeitfenster schrumpft weiter. Was das Zaitsev-Zitat beschreibt, ist bereits Realität. Die mittlere Zeit von der Veröffentlichung eines CVE bis zum ersten Exploit-Versuch liegt heute bei Stunden, nicht mehr bei Wochen. Mit Mythos-Klasse-Modellen könnten Zero-Days gefunden und ausgenutzt werden, bevor überhaupt ein Advisory existiert.

    Patch-Management wird zur Überlebensfrage. Wer heute noch monatliche Patch-Zyklen fährt, operiert in einer Realität, die es nicht mehr gibt. Automatisierte, risikobasierte Patch-Priorisierung ist nicht mehr optional.

    Detection muss schneller werden. Wenn Angreifer KI-gestützt Schwachstellen finden und Exploits entwickeln, muss die Erkennung mit derselben Geschwindigkeit arbeiten. Ein SIEM, das Alerts erst nach Stunden korreliert, ist in dieser Welt zu langsam. Verhaltensbasierte Erkennung, kontinuierliches Monitoring und KI-gestützte Triage werden zur Pflicht.

    Open Source ist kein Freifahrtschein. Die Linux-Foundation-Beteiligung an Glasswing zeigt: Open-Source-Software, die den Kern moderner IT ausmacht, war bisher chronisch unterfinanziert in Sachen Sicherheit. Unternehmen, die Open-Source-Komponenten einsetzen, müssen ihre Lieferkette aktiver überwachen — SBOM-Management und Dependency-Monitoring sind keine Kür mehr.

    Die größere Frage

    Project Glasswing ist ein Versuch, den Verteidigern einen Vorsprung zu geben. Ob das gelingt, hängt davon ab, wie schnell die Erkenntnisse aus dem Konsortium in die breite Praxis fließen. Anthropic verspricht, innerhalb von 90 Tagen öffentlich über die Ergebnisse zu berichten und Empfehlungen für die Weiterentwicklung von Sicherheitspraktiken im KI-Zeitalter zu veröffentlichen.

    Die unbequeme Wahrheit bleibt: Mythos Preview zeigt, was heute möglich ist. In zwölf Monaten werden ähnliche Fähigkeiten breiter verfügbar sein. Die Frage ist nicht, ob KI-gestützte Schwachstellensuche in die Hände von Angreifern gelangt. Die Frage ist, ob die Verteidiger bis dahin aufgeholt haben.

  • Cybersicherheit ist Chefsache: Warum NIS-2 die Geschäftsführung in die Pflicht nimmt

    Cybersicherheit ist längst kein reines IT-Thema mehr — sie ist Chefsache. Das wird spätestens mit NIS-2 und dem EU AI Act auch regulatorisch unmissverständlich. In einem aktuellen Beitrag für contentway bringt Dr. Andreas Herch, CEO der Business Unit accompio Enterprise, die zentrale Botschaft auf den Punkt: Wer Cyberresilienz will, braucht Führung — nicht nur Technik.

    NIS-2 macht Cybersicherheit zur Pflichtaufgabe der Geschäftsführung

    Die NIS-2-Richtlinie und der EU AI Act heben das Schutzniveau in Europa auf ein verbindlicheres Level. Was früher als freiwillige Kür galt — Risikomanagement, Incident Response, Business Continuity, Audits — wird jetzt Pflicht. Und die Verantwortung liegt nicht mehr bei der IT-Abteilung allein, sondern direkt bei der Geschäftsführung. Inklusive persönlicher Haftung.

    Dr. Herch formuliert es klar: Cybersicherheit ist eine strategische Führungsaufgabe geworden. Unternehmen müssen Prozesse, Governance und Verantwortlichkeiten strukturell verankern. NIS-2 zwingt dazu — und das ist im Kern keine Bedrohung, sondern eine Chance.

    Der blinde Fleck: Fokus auf Technik statt auf Menschen

    Ein zentraler Punkt des Artikels verdient besondere Aufmerksamkeit: Häufig liegt der Fokus von IT-Organisationen zu stark auf der Technik. Die Mitarbeitenden, deren Verhalten oft die Haupteinfallstore sind, werden dagegen häufig vergessen. Firewalls und Endpoint Protection sind notwendig — aber ohne Awareness-Programme, klare Governance-Strukturen und definierte Verantwortlichkeiten bleiben sie Lösungen für nur die Hälfte des Problems.

    Organisatorische Maßnahmen sind neben den technischen Schritten genauso wichtig: Governance-Strukturen aufbauen, Verantwortlichkeiten klar definieren, zentrale Aufgaben so verteilen, dass sie nicht in Zuständigkeitslücken fallen.

    Der richtige Startpunkt: Security-IST-Analyse

    Dr. Herch empfiehlt Unternehmen, zunächst einen erfahrenen Dienstleister mit einer Security-IST-Analyse zu beauftragen — Status quo und Benchmark ermitteln, bevor investiert wird. Das klingt selbstverständlich, wird aber in der Praxis oft übersprungen. Stattdessen wird in teure Software investiert, ohne zu wissen, wo die tatsächlichen Lücken liegen.

    Erst ein Audit, das die komplette Bandbreite einer möglichen Cyberstrategie durchspielt, deckt NIS-2-Lücken auf und lenkt den Fokus auf die relevanten Baustellen. Darauf aufbauend lässt sich ein passendes Sicherheitskonzept ableiten.

    Schlüsselführungsfragen für die Geschäftsführung

    Der Artikel nennt eine Reihe von Fragen, die jede Geschäftsführung beantworten können sollte — und die in der Praxis erschreckend oft unbeantwortet bleiben:

    Wie sind wir IT-technisch für einen Produktionsausfall vorbereitet? Wie aktuell ist unser Notfallkonzept? Wurden alle NIS-2-Vorgaben umgesetzt? Wo haben wir noch Lücken? Deckt unsere Cyber-Versicherung unser Geschäftsmodell ab?

    Wenn diese Fragen nicht spontan und substanziell beantwortet werden können, ist das ein klares Signal: Es besteht Handlungsbedarf — und zwar auf Führungsebene, nicht in der IT-Abteilung.

  • Cyberrisiken finanziell messbar machen: Warum Cybersicherheit in die Sprache des Vorstands übersetzt werden muss

    Was man nicht messen kann, kann man auch nicht steuern. Dieser Grundsatz gilt in der Betriebswirtschaft seit Jahrzehnten — nur in der Cybersicherheit wird er konsequent ignoriert. Unternehmen investieren jährlich erhebliche Mittel in Security-Maßnahmen, ohne ein echtes Verständnis dafür zu haben, welche Risiken sie damit tatsächlich adressieren — und welche nicht.

    In einem aktuellen Interview für contentway erläutert Asdrúbal Pichardo, Managing Director und CEO von Squalify, warum die finanzielle Quantifizierung von Cyberrisiken ein zentraler Hebel für bessere Sicherheitsentscheidungen ist.

    Cyberrisiken als betriebswirtschaftliche Größe

    Das Kernproblem: Cybersicherheit wird in den meisten Unternehmen weiterhin als Angelegenheit der IT-Abteilung behandelt. Investitionen orientieren sich an Checklisten oder subjektiven Einschätzungen statt an messbaren Auswirkungen auf das Geschäft. Die Folge: Vorstände und Geschäftsführer können nicht beurteilen, ob jeder investierte Euro dort wirkt, wo er das Unternehmen tatsächlich schützt.

    Squalify verfolgt einen anderen Ansatz: Das Unternehmen übersetzt Cyberrisiken in finanzielle Kennzahlen — ROI, EBIT, Cashflow. Damit sprechen IT und Vorstand endlich die gleiche Sprache. Das Cyberrisiko wird auf Unternehmensebene betrachtet: die Konsequenzen eines Cyber-Vorfalls auf das Unternehmen quantifiziert, mit direkter Relevanz für die Geschäftsführung.

    42 Datenpunkte für belastbare Risikoaussagen

    Bemerkenswert ist die Effizienz des Ansatzes: Anhand von nur 42 Datenpunkten berechnet die Squalify-Plattform bereits belastbare Zahlen mit Vorstandsrelevanz. Das Quantifizierungsmodell basiert auf historischen Daten zu tatsächlichen Cyber-Verlusten von mehr als 100.000 Unternehmen weltweit und der Expertise von Munich Re, einem der führenden Cyber-Rückversicherer.

    Die Ergebnisse werden auf Basis eines standardisierten, an Unternehmensdaten angepassten Modells in finanzielle Kennzahlen übersetzt. Das ermöglicht präzise Risikoaussagen mit minimalem Aufwand — ein entscheidender Vorteil gegenüber klassischen Risk-Assessments, die oft Monate dauern und trotzdem abstrakt bleiben.

    Typische Anwendungsfälle

    Unternehmen nutzen die Plattform laut Pichardo vor allem, um festzustellen, welche Investitionen in Cybersicherheit den größten Effekt haben und das Risiko am stärksten reduzieren. Gerade Großunternehmen setzen Squalify außerdem zur transparenten Steuerung von Tochtergesellschaften oder für objektive Benchmarks mit Wettbewerbern ein. Darüber hinaus unterstützt die Plattform bei der Auswahl geeigneter Cyberversicherungen.

    Warum das für die Geschäftsführung relevant ist

    Die finanzielle Quantifizierung von Cyberrisiken adressiert ein Problem, das mit NIS-2 akuter denn je ist: Geschäftsführer haften persönlich für die Angemessenheit ihrer Sicherheitsmaßnahmen. Doch wie weist man Angemessenheit nach, wenn man die Risiken nicht beziffern kann? Wer seine Cyberrisiken in Euro ausdrücken kann, trifft bessere Entscheidungen — und kann diese gegenüber Aufsichtsbehörden, Versicherern und Geschäftspartnern belegen.

    Der Ansatz zeigt, wohin sich die Branche entwickelt: Weg vom Bauchgefühl, hin zu datengetriebenen Sicherheitsentscheidungen auf Vorstandsebene.

  • Wenn KI die Seiten wechselt: 6 Wege, wie Angreifer KI-Dienste gegen Ihr Unternehmen einsetzen

    Künstliche Intelligenz verändert die Cybersecurity-Landschaft — aber nicht nur auf der Verteidigerseite. Angreifer nutzen dieselben KI-Dienste, die Unternehmen für Produktivität und Innovation einsetzen, als Angriffsinfrastruktur. Dabei geht es längst nicht mehr nur um KI-generierte Phishing-Mails. Die Methoden sind systematischer, kreativer und gefährlicher geworden.

    Der CSO-Online-Autor Roger Grimes hat sechs zentrale Missbrauchsmuster identifiziert, die wir hier mit zusätzlichen Quellen und unserer Einschätzung einordnen.

    1. KI-gestütztes Social Engineering und Phishing

    Large Language Models erzeugen Phishing-Mails, die sprachlich, kontextuell und stilistisch kaum noch von legitimer Kommunikation zu unterscheiden sind. Angreifer nutzen ChatGPT, Claude oder lokale Open-Source-Modelle, um in Sekunden hunderte individualisierte Nachrichten zu generieren — in jeder Sprache, in jedem Tonfall. Laut einer Studie von SlashNext stieg die Zahl KI-generierter Phishing-E-Mails allein 2024 um über 1.200 Prozent. Harvard Business Review berichtet, dass 60 Prozent der Empfänger auf KI-generierte Phishing-Mails hereinfallen — eine Rate, die mit manuell erstellten, gezielten Spear-Phishing-Angriffen vergleichbar ist.

    Besonders perfide: Die Modelle werden mit öffentlich verfügbaren Informationen aus LinkedIn, Unternehmenswebsites und Pressemitteilungen gefüttert. Das Ergebnis sind hochgradig personalisierte Nachrichten, die gezielt Vertrauensverhältnisse ausnutzen.

    2. Deepfake-Audio und -Video für CEO-Fraud

    Deepfake-Technologie ist kein Zukunftsszenario mehr — sie ist operatives Angriffswerkzeug. Angreifer klonen Stimmen von Geschäftsführern und Vorständen aus öffentlich verfügbaren Aufnahmen (Podcasts, Konferenz-Talks, YouTube-Videos) und setzen sie für CEO-Fraud ein. Der prominenteste Fall: Ein Finanzangestellter in Hongkong überwies 25 Millionen US-Dollar, nachdem er in einer Videokonferenz von Deepfake-Versionen seiner Kollegen und seines CFOs überzeugt wurde.

    Laut dem BSI-Lagebericht 2024 nimmt die Qualität von Deepfake-Angriffen rapide zu. Voice-Cloning benötigt heute nur noch wenige Sekunden Audiomaterial und ist mit frei verfügbaren Tools realisierbar. Für Unternehmen bedeutet das: Jede telefonische oder videobasierte Freigabe-Anforderung ohne Out-of-Band-Verifikation ist ein Sicherheitsrisiko.

    3. KI-generierter Schadcode und polymorphe Malware

    Angreifer nutzen KI-Modelle, um Malware zu erzeugen, die sich bei jeder Ausführung verändert — sogenannte polymorphe Malware. Sicherheitsforscher von Hoxhunt und Picus Security haben nachgewiesen, dass aktuelle LLMs in der Lage sind, funktionsfähige Exploit-Codes, Obfuscation-Layer und Evasion-Techniken zu generieren. Picus Security dokumentierte im “Red Report 2025”, dass KI-gesteuerte Malware-Kampagnen um 500 Prozent zugenommen haben.

    Selbst wenn die großen Anbieter Schutzmechanismen einbauen (Guardrails), werden diese systematisch umgangen — durch Prompt Injection, Jailbreaks oder durch den Einsatz unzensierter Open-Source-Modelle wie WormGPT oder FraudGPT, die explizit für kriminelle Zwecke trainiert wurden.

    4. Automatisierte Schwachstellensuche und Reconnaissance

    Was früher Wochen manueller Arbeit erforderte, erledigen KI-gestützte Tools in Minuten. Angreifer setzen Large Language Models ein, um öffentlich zugängliche Informationen (OSINT) systematisch auszuwerten, Angriffsflächen zu kartieren und bekannte Schwachstellen automatisch mit Exploit-Code zu verknüpfen. Google DeepMind zeigte mit Project Naptime, dass KI-Agenten eigenständig Schwachstellen in Software finden können — und das mit einer Erfolgsrate, die menschliche Analysten in bestimmten Szenarien übertrifft.

    Für Angreifer senkt das die Eintrittsbarriere massiv: Technisch weniger versierte Akteure können mit KI-Unterstützung Angriffe durchführen, die früher APT-Gruppen vorbehalten waren. Das NCSC (National Cyber Security Centre, UK) bestätigte in seinem 2024-Assessment, dass KI die Geschwindigkeit und Effektivität von Cyberangriffen nachweislich erhöht.

    5. Missbrauch legitimer KI-Infrastruktur

    Ein besonders unterschätzter Angriffsvektor: Angreifer nutzen die API-Infrastruktur legitimer KI-Dienste als Teil ihrer Angriffskette. Dazu gehört die Nutzung von KI-Plattformen zur Datenexfiltration (Zusammenfassungen sensibler Dokumente generieren lassen), die Verwendung von KI-Code-Assistenten zur Identifikation von Schwachstellen in gestohlenem Quellcode, sowie die Nutzung von KI-Übersetzungsdiensten für mehrsprachige Angriffskampagnen.

    Microsoft und OpenAI dokumentierten bereits 2024, dass staatlich unterstützte Hackergruppen — darunter Gruppen aus Russland (Forest Blizzard/APT28), China (Charcoal Typhoon), Nordkorea (Emerald Sleet) und dem Iran (Crimson Sandstorm) — aktiv ChatGPT für Reconnaissance, Skripting und Social Engineering nutzen.

    6. Prompt Injection und Manipulation von KI-Agenten

    Mit der zunehmenden Integration von KI-Agenten in Geschäftsprozesse (Kundensupport, Datenanalyse, automatisierte Workflows) entsteht eine neue Angriffsfläche: Prompt Injection. Angreifer schleusen manipulierte Anweisungen in Datenquellen ein, die von KI-Agenten verarbeitet werden — etwa in E-Mails, Dokumente oder Webseiten. Der Agent führt dann Aktionen im Kontext seiner Berechtigungen aus, ohne dass ein Mensch eingreift.

    OWASP hat Prompt Injection in seine Top-10-Liste der LLM-Sicherheitsrisiken aufgenommen (Platz 1). Forscher von Anthropic, Google und Microsoft haben unabhängig voneinander demonstriert, wie Indirect Prompt Injection in Enterprise-Szenarien zu Datenabfluss, unautorisiertem Zugriff und Manipulation von Geschäftsentscheidungen führen kann.

    Was bedeutet das für Unternehmen?

    Die Konvergenz von KI und Cyberangriffen verschärft eine ohnehin angespannte Bedrohungslage. Unternehmen müssen ihre Sicherheitsarchitektur anpassen — und zwar nicht irgendwann, sondern jetzt. Drei Handlungsfelder sind dabei zentral:

    Sichtbarkeit schaffen: Wer nicht sieht, was in seinem Netz passiert, erkennt weder KI-generierte Phishing-Mails noch den Missbrauch interner KI-Dienste. Ein funktionierendes SIEM ist die Grundvoraussetzung.

    Prozesse härten: Freigabeprozesse müssen gegen Deepfake-Angriffe abgesichert werden. Das bedeutet: Multi-Faktor-Verifikation für kritische Transaktionen — nicht nur technisch, sondern auch organisatorisch (Callback-Verfahren, Out-of-Band-Bestätigung).

    KI-Nutzung regulieren: Unternehmen brauchen klare Richtlinien für den Einsatz von KI-Diensten — inklusive Monitoring, welche Daten an externe KI-Plattformen fließen. Shadow AI ist das neue Shadow IT.

Keine weiteren News.

Keine weiteren News.

Sicherheitslücken schließen. Risiken senken. Jetzt handeln!

Unsere Experten zeigen Ihnen live, wie wir Angriffe erkennen, stoppen und Ihr Unternehmen schützen.

Blog

Aktuelle Sicherheitsereignisse