Stellen Sie sich folgende Situation vor. Ein Gebäudemanager erhält das Prüfprotokoll des Brandschutzbeauftragten: alle Melder montiert, alle Leitungen geprüft, Zentrale empfangsbereit. Das Zertifikat ist ausgestellt, der Ordner abgeheftet. Sechs Monate später kommt ein Wartungstechniker für eine Routinebegehung, drückt den Prüfknopf an einem Melder im dritten Obergeschoss – und an der Zentrale geschieht: nichts.
Die Untersuchung dauert drei Stunden. Das Ergebnis: Vor vier Monaten wurde im zweiten Untergeschoss ein Netzwerkverteiler ausgetauscht. Der Techniker wusste nicht – konnte nicht wissen –, dass dieser Verteiler Teil des Signalweges für die Brandmeldanlage war. Die Melder funktionieren. Die Kabel sind angeschlossen. Irgendwo im zweiten Untergeschoss bricht das Signal ab. Seit vier Monaten überwacht der Detektor im dritten Obergeschoss pflichtgemäß jede Rauchpartikel – und wird dabei von niemandem gehört.
Im Brandschutz ist das ein klar definierbarer Mangel, der sofortige Abhilfe und eine Überprüfung aller übrigen Signalwege verlangt. Nicht weil Fahrlässigkeit vorliegt, sondern weil ein System, das seinen eigenen Betriebszustand nicht meldet, kein Schutzsystem ist – es ist eine Schutzsystem-Attrappe. Kein Brandschutzingenieur würde akzeptieren, dass Detektor und Zentrale für sich korrekt funktionieren, wenn der Weg dazwischen ungeprüft ist.
In Security Operations Centern ist derselbe Zustand heute der Normalfall.
Ein SOC-Analyst, der seit Wochen keine Alarme zu einem bestimmten Angriffsmuster sieht, hat keine verlässliche Grundlage für die Einschätzung, ob das an ruhigem Bedrohungsgeschehen liegt oder daran, dass die zuständige Erkennungsregel seit dem letzten Infrastruktur-Update keine Daten mehr erhält. Das Dashboard zeigt grün. Die Regel ist aktiv. Niemand weiß, ob der Signalweg noch intakt ist.
Betriebsdegradierung: Die mathematisch vorhersagbare Konsequenz von Komplexität ohne Selbstbeobachtung
Ein Security Operations Center ist keine abgeschlossene Appliance. Es ist eine lebende Infrastruktur, die in modernen Unternehmensumgebungen typischerweise aus zehn bis fünfzehn aktiven Werkzeugkategorien besteht: SIEM-Instanzen, teils verschiedener Generationen parallel betrieben, SOAR-Plattformen mit hunderten von Playbooks, Log-Kollektoren an Netzwerkgrenzen, Endpunkt-Agenten auf zehntausenden Systemen, Cloud-Connectoren zu Diensten, die sich selbst quartalsweise verändern, Datenpipelines, die Ereignisse normalisieren, filtern, transformieren, weiterleiten – und jetzt zunehmend KI-Agenten, die auf all diesen Datenschichten operieren. Eine Microsoft-Studie vom Februar 2026 („State of the SOC: Unify Now or Pay Later“, in Kooperation mit Omdia) ermittelte im Schnitt 10,9 parallel betriebene Sicherheitskonsolen pro Unternehmen.
Jede dieser Schichten verändert sich. Nicht dramatisch, nicht alle auf einmal – aber kontinuierlich, täglich, durch Kräfte, die weit außerhalb der Kontrolle des SOC-Teams liegen: ein Lieferant, der sein Protokollformat im Rahmen eines Firmware-Updates ändert; ein IT-Team, das eine Netzwerksegmentierung anpasst und dabei eine Log-Weiterleitungsroute kappt; ein Betriebssystem-Update, nach dem ein Endpunkt-Agent seinen Dienst nicht mehr startet; ein API-Token, dessen Ablaufdatum niemand im SOC kannte, weil er von einem Kollegen vor zwei Jahren konfiguriert wurde.
Das entscheidende Merkmal dieser Veränderungen ist ihre Stille. Sie erzeugen keine Alarme. Sie hinterlassen keine Einträge in Ticketsystemen. Sie verringern die Erkennungsfähigkeit des SOC um einen bestimmten Betrag – und dieser Betrag bleibt unsichtbar, weil das SOC keine Rückmeldefunktion für seinen eigenen Betriebszustand hat. Die Regel läuft. Die Regel findet nichts. Das System bucht das als Ruhe.
Was dieses Muster systemisch macht – und das ist der Kern des Arguments –, ist seine Unvermeidlichkeit. Betriebsdegradierung ist keine Frage von Nachlässigkeit oder schlechtem Management. Sie ist die mathematisch vorhersagbare Konsequenz wachsender Systemkomplexität ohne Selbstbeobachtung. Jede neue Integration, jede neue Datenquelle, jeder neue Connector erhöht die Anzahl der Abhängigkeitspfade, entlang derer ein stiller Ausfall entstehen kann. Gleichzeitig wächst die Unübersichtlichkeit dieser Pfade schneller als die Kapazität des Teams, sie manuell zu verfolgen. Das ist kein linearer, sondern ein kombinatorischer Effekt: Bei fünfzehn Werkzeugkategorien mit je fünf relevanten Integrationspunkten ergeben sich nicht 75, sondern tausende mögliche Ausfallstellen.
Die Integration von KI-Agenten verschärft das Problem auf eine neue Weise. Ein Analyst, dem eine fehlerhaft konfigurierte Regel auffällt, bemerkt das im manuellen Review. Ein KI-Agent, der auf einer still degradierten Datenpipeline operiert, produziert nicht weniger Ausgabe – er produziert Ausgabe auf Basis unvollständiger Eingabe, mit hohen Konfidenzwerten, ohne Markierung der fehlenden Grundlage. Die Automatisierung beschleunigt den Betrieb; sie skaliert dabei aber auch die Konsequenzen stiller Infrastrukturausfälle, die vorher lokaler geblieben wären.
Die Fachbegriffe für die häufigsten Ausfallmodi sind präzise genug, um das Ausmaß zu illustrieren. Schema-Drift beschreibt den Fall, in dem geänderte Protokollformate nachgelagerte Parser entwerten – die Regel läuft, erkennt aber nicht mehr, weil die Feldnamen nicht mehr stimmen. Telemetrie-Lücken entstehen, wenn Quellen aufhören zu senden, ohne dass jemand informiert wird. Pipeline-Brüche treten auf, wenn Korrelationsregeln, die auf Ereignisketten angewiesen sind, an einem fehlenden Glied scheitern und alle abhängigen Erkennungen still mitreißen. Gemeinsam ist ihnen, dass sie sich nicht selbst melden – und dass in einem System ohne Selbstbeobachtung niemand sonst sie meldet.
Was die Messungen zeigen
Das ist keine theoretische Gefährdung. Die empirische Datenlage ist konsistent.
Der CardinalOps-Bericht 2025 analysierte über 13.000 SIEM-Erkennungsregeln aus hunderten realer Produktionsumgebungen – Splunk, Microsoft Sentinel, IBM QRadar, Google SecOps. Im Schnitt sind 13 Prozent aller Regeln im laufenden Betrieb vollständig defekt: Sie lösen nie einen Alarm aus, unter keinen Umständen. Nicht in veralteten Umgebungen, sondern in Organisationen mit aktuellen, signifikanten Investitionen in ihre Erkennungsfähigkeiten. Dieselbe Untersuchung ermittelte eine durchschnittliche Abdeckung von 21 Prozent der im MITRE-ATT&CK-Framework definierten Angriffstechniken – bei den zehn Techniken, die in realen Angriffen am häufigsten eingesetzt werden, gerade einmal vier.
Der Picus-Blue-Report 2025, der auf über 160 Millionen durchgeführten Angriffssimulationen beruht, zeigt: Unternehmen erkennen im Schnitt einen von sieben simulierten Angriffen. In der Hälfte der Erkennungsausfälle lag die Ursache nicht in fehlerhafter Regellogik, sondern in vorgelagerten Infrastrukturproblemen – fehlende Protokollquellen, unterbrochene Weiterleitungen, stille Übertragungsausfälle. Derselbe Befund, der im Brandschutzbeispiel für sofortige Nachforschung sorgen würde, wird im SOC-Betrieb als normaler Hintergrundrauschen eingeordnet – wenn überhaupt bemerkt. Die erwähnte Microsoft-Studie ergänzt das Bild: Nur 59 Prozent aller eingesetzten Sicherheitswerkzeuge liefern überhaupt Daten an das SIEM. 42 Prozent aller Alarme werden nicht untersucht.
Diese Zahlen beschreiben keine Ausreißer. Sie beschreiben den statistischen Normalzustand einer Architekturklasse, die Selbstbeobachtung nicht als eingebaute Funktion kennt.
Die fehlende Kategorie: Observability für die Erkennungsinfrastruktur
Jede ausgereifte IT-Organisation wendet Observability auf ihre Produktionssysteme an: kontinuierliche Überwachung des Systemzustands, proaktive Drift-Erkennung, vollständige Abhängigkeitskartierung, Auswirkungsanalyse vor Änderungen. Das ist seit Jahren keine Premiumdisziplin mehr – es ist die Mindestvoraussetzung für verantworteten Betrieb in komplexen Umgebungen.
Im SOC fehlt diese Kategorie. Sicherheitsorganisationen überwachen Bedrohungen. Sie überwachen nicht, ob ihre Bedrohungsüberwachung noch funktioniert. Sie betreiben hochkomplexe Erkennungsinfrastrukturen ohne Rückmeldefunktion für den eigenen Betriebszustand – und behandeln das als akzeptablen Zustand, weil kein Werkzeug auf dem Markt bisher diese Lücke strukturell adressiert hat.
Was ein tragfähiger Ansatz leisten müsste, lässt sich präzise aus der Problemstruktur ableiten. Er müsste Erkennungsregeln nicht als isolierte Objekte verstehen, sondern als Endpunkte von Abhängigkeitsketten – und diese Ketten vollständig kartieren: von der Datenquelle über Ingestion-Pipeline, SIEM und Data Lake bis zu SOAR-Plattform und KI-Agenten. Er müsste Veränderungen an diesen Pfaden erkennen und bewertbar machen, bevor sie sich als Erkennungsausfall manifestieren. Er müsste den Gesundheitszustand der Erkennungsinfrastruktur kontinuierlich messbar machen – durch synthetische Telemetrie, Pipeline-Integritätsprüfungen und kontinuierliche Angriffssimulation, die nicht Angreifer abwehren, sondern den Betrieb der Abwehr selbst verifizieren. Und er müsste Korrekturen simulierbar machen, bevor sie in Produktion gehen – eine Anforderung, die BSI-Grundschutz-Baustein OPS.1.1.3 als Grundprinzip des Änderungsmanagements seit Jahren verankert, aber auf die Sicherheitsinfrastruktur selbst kaum angewendet wird.
Damit entsteht erstmals eine eigenständige Produktkategorie: Detection Infrastructure Observability. Erste Ansätze finden sich in angrenzenden Bereichen wie Continuous Security Validation oder Detection Engineering Platforms – sie adressieren jedoch meist einzelne Teilaspekte: die Regelqualität, die Abdeckung, die Simulation. Die Beobachtbarkeit der gesamten Pipeline als durchgehende Funktion – vom Sensor bis zum Agenten, über alle Abhängigkeitsschichten hinweg – ist als eigenständiges Produkt bisher nicht besetzt. Ich verfolge diesen Bereich aktiv und sondiere die internationale Startup-Szene nach Ansätzen, die hier ansetzen – nicht mit weiteren Erkennungsregeln, sondern mit Beobachtbarkeit der Erkennungsinfrastruktur als primärer Funktion. In der israelischen Startup-Szene entstehen erste Unternehmen, die genau diese Kategorie als Produkt begreifen. Das Feld ist jung, aber die Investmentthese schärft sich.
Wirksamkeit ist keine Einschätzungssache mehr – und das hat haftungsrechtliche Konsequenzen
Das deutsche NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz ist am 6. Dezember 2025 ohne Übergangsfrist in Kraft getreten und hat den Kreis regulierter Unternehmen in Deutschland von rund 4.500 auf etwa 30.000 Einrichtungen ausgeweitet. Das KRITIS-Dachgesetz wurde am 29. Januar 2026 vom Bundestag verabschiedet; die Zustimmung des Bundesrats und die Verkündung im Bundesgesetzblatt stehen zum Zeitpunkt dieses Artikels noch aus. Beide Regelwerke schärfen eine Anforderung, die formal bereits im alten BSIG stand, aber in der Aufsichtspraxis lange als Beschaffungspflicht behandelt wurde: die Pflicht, nicht nur den Einsatz von Systemen zur Angriffserkennung nachzuweisen, sondern deren Wirksamkeit.
Das BSI hat unmittelbar nach Inkrafttreten – am 10. Dezember 2025 – ein eigenes Infopaket zur Bewertung der Wirksamkeit von Risikomanagementmaßnahmen veröffentlicht. Das ist keine redaktionelle Randnotiz. Es ist eine behördliche Positionierung: System angeschafft bedeutet nicht System funktionierend, und diese Unterscheidung wird in Prüfungen nach § 39 BSIG – künftig im Drei-Jahres-Turnus – ausdrücklich bewertet.
Hier liegt ein Punkt, der haftungsrechtlich unmittelbare Relevanz hat. § 31 Abs. 2 BSIG verpflichtet Betreiber kritischer Anlagen zum Einsatz von Systemen zur Angriffserkennung. Die Formulierung ist funktional, nicht komponentenbezogen. Ein Sensor, der Ereignisse generiert, die das SIEM nie erreichen – wegen einer unterbrochenen Weiterleitung, einer geänderten Netzwerkkonfiguration, eines stillen Pipeline-Ausfalls –, erkennt nichts. Er ist keine Komponente eines Systems zur Angriffserkennung im Sinne des Gesetzes. Er erweckt den Anschein, eine zu sein. Die BSI-Orientierungshilfe zu Systemen zur Angriffserkennung bewertet die Funktionskette – Protokollierung, Übertragung, Korrelation, Alarmierung – als Einheit. Eine unterbrochene Übertragungsstrecke lässt diese Kette kollabieren, auch wenn Sensor und SIEM für sich einwandfrei funktionieren. Das Argument „die Komponente hat gesendet“ greift nicht, weil die gesetzliche Pflicht nicht beim Senden endet.
Nach § 38 Abs. 2 BSIG haften Mitglieder der Geschäftsleitung persönlich für Schäden durch schuldhafte Pflichtverletzungen bei der Umsetzung der Risikomanagementmaßnahmen – ein Verzicht der Einrichtung auf diese Ansprüche ist in der Regel unwirksam. Entscheidend ist dabei eine Besonderheit, die in der Branchendiskussion kaum Beachtung findet: Im Haftungsfall trifft die Geschäftsleitung eine besondere Darlegungspflicht. Sie muss nachweisen können, dass sie ihre Organisations- und Überwachungspflichten erfüllt hat – nicht die Behörde oder der Kläger muss das Gegenteil beweisen. Wer keine kontinuierliche Dokumentation des Betriebszustands seiner Erkennungsinfrastruktur führt, hat diesen Nachweis strukturell nicht. Die Pflichtverletzung entsteht damit nicht erst, wenn ein konkreter Schaden eingetreten ist. Sie liegt bereits dann vor, wenn kein Nachweis geführt werden kann, dass die Erkennungskette vom Sensor bis zum Analysten zu einem bestimmten Zeitpunkt durchgehend funktioniert hat. Wer kein Monitoring der Signalwege betreibt, hat kein technisches Defizit. Er hat ein Organisationsverschulden.
Das BSI selbst zieht an dieser Stelle den Vergleich zur DSGVO-Rechenschaftspflicht nach Artikel 5 Absatz 2 der Datenschutzgrundverordnung: Einrichtungen sind verpflichtet, die Umsetzung und Einhaltung von Maßnahmen angemessen zu dokumentieren. Das ist keine externe Analogie. Es ist die Aufsichtsbehörde, die in ihren eigenen Infopaketen erklärt, wie sie den Nachweis der Wirksamkeit bewertet – und die dabei auf denselben Rechenschaftsrahmen verweist, der in der DSGVO-Praxis bereits zu substanziellen Sanktionen geführt hat.
Warum israelische Gründer dieses Problem früher sehen
Das israelische Cybersicherheitsökosystem bringt Produktkategorien nicht aus Marktanalysen hervor, sondern aus kondensierter operativer Erfahrung in Umgebungen, in denen stille Infrastrukturausfälle Konsequenzen haben, die im kommerziellen Betrieb selten sichtbar werden. Wer Jahre in den komplexesten SOC-Umgebungen der Welt gearbeitet hat – staatlich wie kommerziell –, entwickelt eine andere Intuition für die Stellen, an denen Signale still verschwinden.
Der empirische Beleg dafür ist selbst ein israelisches Produkt: CardinalOps, mit Sitz in Tel Aviv und Boston, liefert seit fünf Jahren die schärfsten Produktionsdaten zur Broken-Rules-Problematik – die 13-Prozent-Zahl in diesem Artikel stammt aus ihrer Analyse realer SIEM-Umgebungen. Was das Marktbild dabei zeigt, ist analytisch aufschlussreich: Continuous Security Validation testet, ob ein simulierter Angriff einen Alert erzeugt – nicht, warum er es tut oder nicht tut. Detection Engineering Platforms verbessern Regelqualität und Coverage-Mapping. Beide Kategorien setzen an den Enden der Pipeline an. Die Mitte – Telemetrie-Integrität, Dependency-Chain, strukturelles Pipeline-Monitoring – bleibt methodisch unbesetzt. Dass Gartner im Hype Cycle for Security Operations 2025 erstmals Telemetry Pipelines als eigenständige Innovationskategorie aufführt, deutet darauf hin, dass diese Lücke auch im Analyst-Umfeld erkannt wird – ohne dass bislang eine Produktkategorie dafür existiert.
Für den deutschen und europäischen Markt ist das ein konkreter Vorteil. KRITIS-Betreiber in Energie, Telekommunikation, Finanzmarktinfrastruktur und Gesundheitsversorgung betreiben historisch gewachsene, multi-vendor-SOC-Umgebungen, in denen Betriebsdegradierung der strukturelle Normalfall ist – nicht die Ausnahme. NIS-2 und BSI-Grundschutz machen den Wirksamkeitsnachweis zu einer nicht delegierbaren Pflicht. Welche Produkte diese Pflicht technisch unterstützen – und welche das nur behaupten –, wird eine der zentralen Beschaffungsfragen der nächsten Jahre. Ich verfolge das als Teil meiner Tech-Due-Diligence-Arbeit für Family Offices und institutionelle Investoren, die israelische Cyber-Startups in regulierten europäischen Märkten bewerten.
Der Techniker im zweiten Untergeschoss hat keinen Fehler gemacht. Er hat seinen Auftrag korrekt ausgeführt. Er wusste nicht, dass sein Auftrag Konsequenzen für ein System hatte, das niemand im Blick hatte. Im SOC-Betrieb ist das die Regel, nicht die Ausnahme – und das NIS-2-Umsetzungsgesetz sowie der Haftungsrahmen des § 38 BSIG haben begonnen, das von einem betrieblichen Problem zu einem persönlichen zu machen.
Ich sondiere aktiv israelische Startups, die in diesem Bereich strukturell tragfähige Ansätze entwickeln – und begleite Family Offices sowie institutionelle Investoren bei der unabhängigen technischen und regulatorischen Bewertung genau dieser Kategorie. Wenn Sie als Investor in diesem Feld positioniert sind oder als CISO das Problem aus dem eigenen Betrieb kennen: Sprechen Sie mich direkt an.
Dieser Artikel ist Teil der laufenden Analyse zu Security Operations und israelischen Cybersicherheitstechnologien für den europäischen Markt. Verwandte Beiträge: Decision-Grade KI im SOC · Sicherheit am Kipppunkt: Warum KRITIS seine Sicherheitslogik neu ordnen muss · Israel 2026: Die Cyber-Nation als strategischer Faktor für Sicherheit, Regulierung und Resilienz
Anmelden zu unserem Newsletter:
Schreibe einen Kommentar