Sicherheitsbeobachtbarkeit erklärt: Von den „bekannten Unbekannten“ der Überwachung bis hin zu Abfragen mit hoher Kardinalität

Sicherheitsbeobachtbarkeit ist die Disziplin, Systeme so auszustatten, dass Sicherheitsteams beliebige, unerwartete Fragen anhand umfangreicher Telemetriedaten mit hoher Kardinalität beantworten können – und so die „unbekannten Unbekannten“ aufdecken, die vordefinierte Regeln niemals vorhergesehen haben. Während die Überwachung auf bekannte Signale achtet, ermöglicht die Beobachtbarkeit, nach dem „Warum“ zu fragen und Fragen zu stellen, für deren Beantwortung kein Dashboard konzipiert wurde.

Diese Unterscheidung ist wichtig, da Angreifer sich selten so verhalten, wie es vordefinierte Erkennungsmechanismen erwarten. Sie kombinieren legitime Anmeldedaten, neuartige Tools und mehrstufige Vorgehensweisen, die von keinem einzelnen Schwellenwert erkannt werden. Die Fähigkeit, vorhandene Telemetriedaten zu analysieren – also eine Frage zu stellen, die einem erst nach einem Alarm in den Sinn gekommen ist –, verwandelt „Wir haben einen Alarm erhalten“ in „Wir können genau rekonstruieren, was der Angreifer getan hat“. Dieser Leitfaden erläutert, was Sicherheitsobservabilität ist, wie sie sich von Überwachung, Transparenz und SIEM unterscheidet, auf welche Telemetrie-Säulen sie sich stützt, welche moderne Datenarchitektur dahintersteckt und wohin sich das Fachgebiet mit „Detection-as-Code“ und der Observabilität von KI-Agenten entwickelt. Er baut auf dem übergreifenden Rahmen der Sicherheitsüberwachung auf, den die meisten SOCs bereits nutzen.

Was versteht man unter Sicherheitstransparenz?

Sicherheitsbeobachtbarkeit ist die Disziplin, Systeme so auszustatten, dass sicherheitsrelevante, beliebige und unerwartete Fragen anhand umfangreicher Telemetriedaten mit hoher Kardinalität beantwortet werden können – wodurch „Unbekanntes im Unbekannten“ aufgedeckt wird –, anstatt sich ausschließlich auf vordefinierte Signale, Dashboards und Warnmeldungen der Überwachung zu verlassen, die „Bekanntes im Unbekannten“ beantworten.

Der Begriff hat sowohl akademische als auch operative Wurzeln. Forscher haben die Beobachtbarkeit als einen Weg zur Stärkung der Sicherheitsarchitektur komplexer digitaler Ökosysteme definiert und betrachten dabei die Fragen, die man an ein System stellen kann, als Maßstab dafür, wie gut es verteidigt werden kann (arXiv). In der Praxis lehnt sich das Fachgebiet an das Site Reliability Engineering an, wo Beobachtbarkeit beschreibt, wie gut man den internen Zustand eines Systems anhand der von ihm ausgegebenen Daten nachvollziehen kann. In der Cybersicherheit wendet die Observability dieselbe Eigenschaft auf Sicherheitsfragen an: Wie umfassend und wie flexibel kann man die Telemetriedaten auswerten, um zu verstehen, was ein Angreifer getan hat?

Der Unterschied zur Überwachung ist genau der springende Punkt. Die Überwachung liefert Antworten auf „bekannte Unbekannte“ – Fragen, die Sie vorausgesehen und für die Sie im Voraus Warnmeldungen eingerichtet haben. Die Beobachtbarkeit liefert Antworten auf „unbekannte Unbekannte“ – Fragen, die Ihnen erst in den Sinn gekommen sind, als ein Vorfall Sie dazu gezwungen hat. Ein Überwachungssystem ist nur so gut wie die Regeln, die jemand gestern geschrieben hat; ein beobachtbares System bleibt auch für die Fragen nützlich, die Sie morgen stellen werden.

Warum Observability in der Cybersicherheit wichtig ist

Die Überwachung basiert auf Fragen, die Sie bereits stellen können. Sie legen einen Schwellenwert fest – fehlgeschlagene Anmeldeversuche pro Minute, ausgehende Bytes pro Host, einen bekannten malware – und das System gibt eine Warnmeldung aus, sobald dieser Schwellenwert überschritten wird. Dies funktioniert gut bei „bekannten Unbekannten“: Problemen, die Sie im Voraus erwartet und für die Sie entsprechende Maßnahmen ergriffen haben. Der Haken daran ist, dass eine Warnmeldung Ihnen lediglich mitteilt, dass etwas passiert ist, nicht aber, warum es passiert ist oder was derselbe Akteur sonst noch beeinflusst hat.

Das Problem ist, dass raffinierte Angriffe fast schon per Definition genau das sind, womit man nicht gerechnet hat. Eine neuartige „Living-off-the-Land“-Technik, ein mehrstufiger Pfad, der bei jedem einzelnen Schritt harmlos erscheint, oder ein Muster des Missbrauchs von Anmeldedaten, bei dem kein einzelnes Signal die vordefinierten Regeln umgeht. Dies ist das Kernargument für Sicherheitsobservabilität: Wenn die Telemetriedaten umfangreich und ausreichend abfragbar sind, kann ein Analyst eine völlig neue Frage stellen – „Zeige mir jeden Prozess, der in dieses Verzeichnis geschrieben und anschließend eine ausgehende Verbindung zu einer neuen Region hergestellt hat“ –, ohne dafür zuvor eine Regel erstellt zu haben. Diese Fähigkeit, das Unbekannte zu ergründen, ist es, die es der Observabilität ermöglicht, neuartige und mehrstufige Angriffe über eine weitläufige Angriffsfläche hinweg aufzudecken.

Es gibt noch einen zweiten Vorteil: Geschwindigkeit und Sicherheit bei der Untersuchung. Wenn alle relevanten Signale an einem Ort abrufbar sind, kann ein Analyst innerhalb von Minuten statt Tagen von einem einzelnen Indikator zum Gesamtbild gelangen – den Umfang bestätigen, falsche Spuren ausschließen und den zeitlichen Ablauf rekonstruieren. Das ist der Unterschied zwischen der bloßen Kenntnis, dass ein Alarm ausgelöst wurde, und dem genauen Wissen darüber, was ein Angreifer getan hat. Deshalb ist Observability zu einer entscheidenden Fähigkeit des modernen Security Operations Center geworden.

Entscheidend ist, dass Sicherheitstransparenz ein allgemeiner Begriff ist und keine Funktion eines bestimmten Anbieters. Die obige Definition ist bewusst anbieterunabhängig gehalten: Es geht um die Eigenschaft eines Systems und die Vorgehensweisen eines Teams, nicht um eine Produktkategorie.

Sicherheitsbeobachtbarkeit im Vergleich zu Überwachung, Transparenz und SIEM

Die Überwachung zeigt Ihnen, dass etwas nicht stimmt; die Beobachtbarkeit ermöglicht es Ihnen, nach dem „Warum“ zu fragen – und Fragen zu stellen, die keine Regel vorhersagen konnte. Da diese Begriffe oft recht locker verwendet werden, ist es hilfreich, jeden Unterschied genau zu betrachten, denn diese Unterscheidungen beeinflussen konkrete Entscheidungen hinsichtlich Architektur und Personalbesetzung. Die Beobachtbarkeit steht nicht im Widerspruch zur Sicherheitsüberwachung, sondern erweitert diese.

Eine nützliche Analogie stammt aus der Medizin. Die Überwachung ist wie ein Vitalparameter-Monitor, der einen Signalton abgibt, wenn ein Wert den sicheren Bereich verlässt – er signalisiert, dass sich ein Patient in einer Notlage befindet. Observabilität ist die diagnostische Abklärung, die es einem Arzt ermöglicht, den Grund dafür zu ergründen, indem er den Symptomen auf den Grund geht, wohin auch immer sie führen, selbst auf Wege, die niemand vorhergesehen hat. Beides ist wichtig; keines ersetzt das andere.

Die Unterschiede lassen sich in vier Bereiche einteilen: Umfang (vordefinierte Signale gegenüber beliebigen Fragen), Analyse (Schwellenwerte gegenüber Erkundung), Problembewusstsein (bekannte Unbekannte gegenüber unbekannten Unbekannten) und Tiefe der Fähigkeiten (Alarmierung gegenüber Untersuchung). Die folgende Tabelle fasst zusammen, in welchem Zusammenhang Überwachung, Beobachtbarkeit und Transparenz stehen.

Tabelle: Wie sich Überwachung, Beobachtbarkeit und Transparenz unterscheiden – bei der Überwachung werden bekannte Signale überwacht, bei der Beobachtbarkeit wird alles abgefragt, und die Transparenz liefert die zugrunde liegenden Daten.

Ist Monitoring ein Teilbereich der Observability?

Eine klarere Sichtweise ist, dass es sich um komplementäre Eigenschaften handelt und nicht darum, dass die eine eine strenge Teilmenge der anderen ist. Überwachung ist die Ebene der vordefinierten Signale – also das Beobachten bestimmter Metriken. Observabilität ist die Eigenschaft eines Systems, die es ermöglicht, beliebige Fragen zu beantworten. Ausgereifte Programme nutzen beides: Die Überwachung erfasst bekannte Probleme schnell, und die Observabilität kümmert sich um alles, was die Überwachung nicht vorhersehen kann. Beobachtbarkeit ersetzt die Überwachung nicht; sie erweitert den Frageraum eines Teams, sodass die richtige Frage selten „welches von beiden“ lautet, sondern „wie sie sich gegenseitig verstärken“.

Beobachtbarkeit vs. Sichtbarkeit

Transparenz ist die Datenquellenschicht – also welche Daten Sie aus einer bestimmten Domäne, wie beispielsweise dem Netzwerk, tatsächlich sehen und erfassen können. Die Netzwerktransparenz ist zum Beispiel eine Datenquelle; Observability ist die Analysedisziplin, die diese zusammen mit allen anderen Telemetrie-Streams abfragt. Einfach ausgedrückt: Die Transparenz liefert die Eingaben, und Observability ist das, was Sie damit machen. Die Mechanismen zur Erfassung von Netzwerkdaten – wie Pakete, TAP, SPAN und East-West-Erfassung – gehören zur Netzwerktransparenz; die Observability nutzt diese Ergebnisse als eine von vielen Eingaben neben Logs, Metriken, Traces, Identitätsdaten und cloud . Ohne Einblick in die zugrunde liegenden Daten ist keine aussagekräftige Observability möglich – doch Transparenz allein, ohne die Möglichkeit, diese Daten abzufragen, lässt die schwierigen Fragen unbeantwortet.

Observability vs. SIEM

SIEM-Systeme (Security Information and Event Management) zentralisieren Sicherheitsdaten und korrelieren diese anhand vordefinierter Erkennungsregeln. Observability ist der übergeordnete Begriff für das Stellen beliebiger Fragen an Telemetriedaten mit hoher Kardinalität. Anstatt eines „Winner-takes-all“-Urteils lässt sich die Beziehung am besten als Spektrum verstehen: Observability kann ein SIEM ergänzen, kostengünstigen Speicher von der Analyseebene des SIEM entkoppeln oder – in einigen cloud Fällen – ein Legacy-SIEM vollständig ersetzen. Ob Sicherheitsbeobachtbarkeit eine tragfähige SIEM-Alternative darstellt, hängt von cloud , den Aufbewahrungsanforderungen und dem Kostenmodell eines Unternehmens ab – nicht von einer pauschalen Antwort. Viele Teams entscheiden sich für einen Mittelweg: Sie behalten das SIEM als Abfrage- und Korrelationsschicht bei, verlagern den Massenspeicher jedoch auf eine kostengünstigere, entkoppelte Ebene, sodass sie weitaus mehr Telemetriedaten aufbewahren und auswerten können, als es eine nach Erfassungsvolumen berechnete Indizierung zulassen würde.

Die Säulen der Sicherheitstransparenz

Die drei Säulen – Protokolle, Metriken und Traces – erstrecken sich im Sicherheitsbereich auf Ereignisse, Erkennungen, Netzwerkflüsse sowie Identitäts- und cloud . Das kanonische Modell aus dem breiteren Bereich der Observability umfasst genau drei Komponenten: Protokolle zeichnen auf, was geschehen ist, Metriken quantifizieren, in welchem Umfang und wie oft, und Traces zeigen, wie sich eine Anfrage durch ein verteiltes System bewegt hat.

Aus Sicherheitsgründen wird dieses Modell üblicherweise zu MELT – Metriken, Ereignisse, Protokolle und Traces – erweitert, wobei Ereignisse als „First-Class“ behandelt werden. Die drei Säulen bleiben weiterhin maßgeblich; MELT ist die sicherheitsorientierte Erweiterung, da einzelne Sicherheitsereignisse wie das Auslösen einer Erkennung, eine Richtlinienänderung oder die Gewährung von Berechtigungen einen „First-Class“-Status verdienen, anstatt in allgemeinen Protokollen unterzugehen. Eine neuere Kritik unter dem Begriff „Wide Events“ argumentiert, dass reichhaltige Ereignisdatensätze mit hoher Kardinalität möglicherweise wichtiger sind als die starre Dreisäulen-Einteilung – eine Debatte, die es zu verfolgen gilt, doch die Säulen bleiben ein nützlicher Einstieg für Teams, die neu in diesem Bereich sind.

Der eigentliche Mehrwert für Sicherheitsteams liegt darin, jede der generischen Säulen auf den jeweiligen Sicherheitskontext auszuweiten, sodass Sicherheitssignale zu erstklassigen Inputdaten für die Observability werden und nicht nur nachträgliche Überlegungen sind. Ein Protokoll ist nicht nur eine Anwendungsmeldung, sondern ein Prüfpfad; eine Metrik ist nicht nur ein Latenzwert, sondern die Rate fehlgeschlagener Anmeldeversuche; eine Ablaufverfolgung ist nicht nur eine Leistungsübersicht, sondern eine Aufzeichnung von Ost-West-Datenverkehr, den ein Angreifer ausnutzen könnte. Die folgende Tabelle ordnet jede Säule ihrer Sicherheitserweiterung zu und nennt jeweils ein Beispielsignal.

Tabelle: Die drei Säulen der Beobachtbarkeit, erweitert um den Bereich Sicherheit, mit jeweils einem Beispielsignal.

Welche Datenquellen fließen in die Sicherheitsüberwachung ein?

In der Praxis ist das Spektrum der Eingabedaten breit gefächert. Anwendungs- und Systemprotokolle liefern die Rohdaten der Aktivitäten; Sicherheitsereignisse und Erkennungen fügen die einzelnen Vorfälle hinzu, die am wichtigsten sind; Netzwerk- und Fluss-Telemetrie erfasst, wie Hosts und Dienste miteinander kommunizieren; Identitäts- und Audit-Protokolle zeigen, wer was getan hat; und endpoint cloud runden das Bild über alle Workloads hinweg ab. Verhaltenssignale – die Grundlage der Erkennung von Netzwerkanomalien – sind besonders wertvoll, da sie beschreiben, wie sich Entitäten tatsächlich verhalten, anstatt nur mit einer Liste bekannter Bedrohungen abgeglichen zu werden; genau das macht sie so effektiv gegen neuartige Techniken. Das charakteristische Merkmal all dieser Datenquellen ist, dass sie als abfragbare Telemetriedaten behandelt werden und nicht als isolierte Alarmströme, sodass ein Analyst bei Bedarf Korrelationen zwischen ihnen herstellen kann, anstatt zwischen unverbundenen Konsolen hin- und herwechseln zu müssen. Das Ziel ist ein einziger logischer Telemetrie-Bestand, auf den jede Abfrage zugreifen kann, unabhängig davon, welches Tool die Daten ursprünglich erzeugt hat.

So funktioniert die Sicherheitstransparenz: die moderne Datenarchitektur

Moderne Sicherheitsobservability erfasst Daten mit OpenTelemetry, normalisiert sie mit OCSF, speichert sie in einem entkoppelten Data Lake und führt bei Bedarf Abfragen durch. Das Verständnis dieser Pipeline ist entscheidend, um ein Schlagwort von einer tatsächlich funktionierenden Fähigkeit zu unterscheiden, und genau diese Ebene hebt Observability am deutlichsten von den umliegenden Disziplinen der Überwachung und Transparenz ab.

Die einzelnen Schritte laufen wie folgt ab:

• Erfassung. OpenTelemetry (OTel) ist der offene Standard für die Erfassung von Telemetriedaten – Logs, Metriken und Traces – über heterogene Systeme hinweg. Es wurde am 21. Mai 2026 von der Cloud Computing Foundation (CNCF) als eigenständiges Projekt anerkannt und ist mittlerweile auf mehr als 12.000 Mitwirkende aus über 2.800 Unternehmen angewachsen, wodurch es seinen Status als de-facto-Open-Source-Standard für Observability gefestigt hat (CNCF, OpenTelemetry-Sicherheitsdokumente). Extended Berkeley Packet Filter (eBPF) ist ein ergänzender Mechanismus auf Kernel-Ebene, der umfangreiche System- und Netzwerktelemetriedaten mit geringem Overhead erfasst und diese häufig in dieselbe Pipeline einspeist.
• Normalisierung. Das Open Cybersecurity Schema Framework (OCSF) ordnet Telemetriedaten zahlreicher Anbieter einem herstellerunabhängigen Schema zu, sodass ein Anmeldevorgang unabhängig von seiner Quelle immer dasselbe bedeutet (OCSF). OCSF hat die Version 1.8.0 (Changelog vom 16. März 2026) veröffentlicht, mit der eine ai_operation Profil zur Modellierung von KI-Workloads als erstklassige Sicherheitstelemetrie (OCSF-Veröffentlichungsprotokoll). Der Standard erhielt im Dezember 2025 auch die Unterstützung der Mitgliedstaaten der Internationalen Fernmeldeunion (ITU), um bis Juni 2026 als internationaler Standard ratifiziert zu werden (AWS-Open-Source-Blog).
• Speicherung. Moderne Architekturen entkoppeln die Speicherung von der Analyse, sodass Rohdaten aus der Telemetrie in einem kostengünstigen Objekt-Speicher-Sicherheits-Data-Lake statt in einem teuren, durch die Datenaufnahme kostenintensiven Index gespeichert werden. Ein Sicherheits-Data-Lake speichert Daten mit hoher Kardinalität kostengünstig und in großem Maßstab, wobei die Analyse-Engine als Abfrageebene darüber fungiert (Software Analyst Market Guide).
• Abfragen und Analysen. Sobald die Daten normalisiert und gespeichert sind, führen Analysten und Sicherheitsingenieure beliebige Abfragen durch – das Herzstück der Observability.
• Erkennung als Code. Die Erkennungen werden dann als versionsverwalteter, testbarer Code ausgedrückt, der über dieselbe Pipeline bereitgestellt wird.

„Schema-on-Read“ und entkoppelte Speicherung

Der entscheidende Faktor, der dies ermöglicht, ist „Schema-on-Read“. Herkömmliche SIEM-Systeme arbeiten nach dem „Schema-on-Write“-Prinzip – sie strukturieren und indizieren Daten bereits bei der Erfassung, was starr und kostspielig ist. Bei „Schema-on-Read“ hingegen wird die Struktur erst zum Zeitpunkt der Abfrage angelegt, sodass Teams Rohdaten mit hoher Kardinalität kostengünstig speichern und später flexibel auswerten können. Dies ist der einzige Kostenaspekt, der hier im Fokus steht: Im Gegensatz zu den wirtschaftlichen Überlegungen „Build versus Buy“, die im Rahmen der Bereitstellungsmodelle für Cybersicherheitsüberwachung behandelt werden, dreht sich die Kostenfrage bei der Observability um den Kompromiss zwischen Speicherung und Analyse sowie um die Aufbewahrungsdauer. Eine Plattform für Sicherheitsdatenpipelines ist zwischen Erfassung und Speicherung geschaltet, um die Telemetriedaten vor der Speicherung weiterzuleiten, anzureichern und zu reduzieren.

cloud Flecken in cloud reduzieren

Cloud Umgebungen – kurzlebige Container, Kubernetes-Workloads, kurzlebige Identitäten – erzeugen genau jene Telemetriedaten mit hoher Kardinalität und hoher Veränderungsrate, mit denen die Schwellenwertüberwachung zu kämpfen hat. Hier spielt Observability ihre Stärke aus und steht in direktem Zusammenhang mit cloud . Die Hindernisse sind real: In der SANS-Umfrage „Detection & Response Survey 2025“ nannten 58 % der Befragten begrenzte cloud und 53 % die Komplexität von Multicloud-Umgebungen als größte cloud (Bericht zur SANS-Umfrage). Da cloud von Natur aus eine hohe Kardinalität aufweisen und kurzlebig sind, reduziert Observability blinde Flecken, indem sie diese Daten auch nach dem Ende der Workload abfragbar hält. Beachten Sie, dass sich die Landschaft der Sicherheitsdatenpipelines und die Konventionen von OpenTelemetry im Bereich der generativen KI rasch weiterentwickeln, sodass Architekturentscheidungen regelmäßig überprüft werden sollten.

„Detection-as-Code“ und Analysen mit hoher Kardinalität

„Detection-as-Code“ verwaltet Erkennungen wie Software über Versionskontrolle; Abfragen mit hoher Kardinalität decken Angriffe auf, die vordefinierte Regeln niemals vorhergesehen hätten. Zusammen verbinden sie den Bereich der Observabilität mit den täglichen Arbeitsabläufen der Praktiker.

„Detection-as-Code“ wendet die „Infrastructure-as-Code“-Philosophie auf Erkennungsregeln an. Anstatt Regeln per Mausklick in eine Konsole einzugeben, schreiben Teams Erkennungsregeln als Code, der:

• Versionsverwaltet, sodass jede Änderung nachverfolgt und überprüft werden kann.
• CI/CD-gestützt, sodass Erkennungen über eine getestete Pipeline bereitgestellt werden.
• Testbar, d. h., eine Erkennung wird vor der Produktion anhand bekannter Proben validiert.
• Portabel, sodass die Logik nicht an das proprietäre Format eines bestimmten Tools gebunden ist.

Dies ist das technische Rückgrat der modernen Erkennungstechnik und lässt sich nahtlos mit threat hunting, bei der Analysten explorative Abfragen nutzen, um das zu finden, was noch von keiner Regel erfasst wurde. Beides trägt zu umfassenderen Ergebnissen bei der Bedrohungserkennung bei.

Was sind Daten mit hoher Kardinalität?

Daten mit hoher Kardinalität sind Telemetriedaten mit vielen eindeutigen Werten – Benutzer-IDs, Container-IDs, Sitzungstoken, Quell-IPs. Gerade diese hohe Kardinalität ermöglicht beliebige Abfragen: Wenn Sie Telemetriedaten nach jedem beliebigen der Tausenden von eindeutigen Attributen filtern können, können Sie eine Frage stellen, die Ihnen gerade erst in den Sinn gekommen ist. „Wide Events“ – umfangreiche Datensätze mit vielen Attributen pro Ereignis – sind das Format, das die Beantwortung von Fragen mit hoher Kardinalität ermöglicht. Genau so hilft Observability dabei, unbekannte Bedrohungen zu erkennen: Dank der Abfragbarkeit können Analysten Fragen stellen, die in keiner vordefinierten Regel kodiert sind.

Warum vordefinierte Erkennungsmuster von Natur aus unvollständig sind

Die Argumente für explorative Beobachtbarkeit stützen sich auf konkrete Daten. Unternehmens-SIEMs decken etwa 21 % der MITRE ATT&CK ab, 79 % werden jedoch nicht erfasst, obwohl die Infrastruktur so ausgelegt ist, dass sie theoretisch mehr als 90 % der Techniken erkennen könnte (CardinalOps, Juni 2025; Berichterstattung von Help Net Security). Dieselbe Untersuchung ergab, dass durchschnittlich 13 % der Erkennungsregeln nicht eingehalten werden, was einem Rückgang von 5 % gegenüber 2024 entspricht. Die Schlussfolgerung lautet nicht „Ihre Überwachung versagt“ – vielmehr sind vordefinierte Erkennungsregeln strukturell unvollständig, sodass Sie eine Observability mit hoher Kardinalität benötigen, um Fragen zu stellen, die die Regeln nie vorhergesehen haben. MITRE ATT&CK hier der Maßstab: Der Wert der Observability liegt in der Abfrage über verschiedene Techniken hinweg, wie beispielsweise „Discovery“ (0007) und Network Service Discovery (T1046), dass vordefinierte Lücken in der Abdeckung (MITRE ATT&CK).

Zwei anschauliche Anwendungsbeispiele

Die Log4Shell-Sicherheitslücke (CVE-2021-44228) ist ein anschauliches Beispiel für den Einsatz von Observability-Daten als Untersuchungsquelle. Analysten, denen verdächtige Java-Tochterprozesse auffielen, konnten den Exploit-Pfad anhand von Traces aus der Anwendungsleistungsüberwachung – ein Backend-Dienst, der kurzzeitig in der Servicekarte erschien – sowie anhand von Anwendungsprotokollen rekonstruieren, die Base64-kodierte Payloads in den Request-Headern zeigten, wodurch sich die anfälligen Bibliotheken bestätigten (CISA AA21-356A). Dieser Fall ist ein Beispiel für eine Methodik aus dem Jahr 2021 und keine aktuelle Statistik, doch die Erkenntnis bleibt bestehen: Eine einheitliche Telemetrie verwandelt eine Warnmeldung in eine vollständige Rekonstruktion.

Ein aktuelleres Muster ist die cloud laterale Bewegung aufgrund einer durchgesickerten Anmeldeinformation. Ein einzelnes Signal – ein fehlgeschlagener Anmeldeversuch, eine Netzwerkverbindung – wirkt zunächst unauffällig. Observability deckt die Sicherheitsverletzung auf, indem sie fehlgeschlagene Anmeldeversuche, ungewöhnlichen Netzwerkverkehr, Dateizugriffsmuster und Lesezugriffe aus einer ungewöhnlichen Region in einer Abfrage mit hoher Kardinalität miteinander korreliert. Durch diese Korrelation verbessert Observability die Reaktionszeiten bei Vorfällen und unterstützt die proaktive Erkennung von Bedrohungen: Sie erkennt mehrstufige Angriffe, die bei einer Schwellenwertüberwachung einzelner Signale übersehen würden. Eine Analyse der Reaktion auf Vorfälle aus dem Jahr 2026, die vom Unit-42-Forschungsteam an mehr als 750 Vorfällen durchgeführt wurde, kommt zu dem gleichen Ergebnis – die Ermittler mussten häufig Daten aus unzusammenhängenden Quellen zusammenfügen, was die Erkennung verlangsamte, und der Bericht führte 90 % der Sicherheitsverletzungen auf Fehlkonfigurationen oder Sicherheitslücken zurück (PR Newswire).

KI und Beobachtbarkeit von Agenten

Die Observability für KI erweitert die Säulen um Prompts, Tool-Aufrufe und Traces – denn 48 % der KI-Agenten laufen ohne Überwachung. Dies ist die neueste Erweiterung dieses Fachgebiets, und die Entwicklung schreitet rasch voran.

Die Beobachtbarkeit von KI-Agenten bedeutet, die Säulen der Beobachtbarkeit auf KI-spezifische Signale auszuweiten: Eingabeaufforderungen, Tool-Aufrufe, Herkunft der abgerufenen Daten, Metriken zu Tokens und Interaktionsrunden, die während einer Aktion geltenden Berechtigungen sowie End-to-End-Verläufe der Schlussfolgerungen und Aktionen eines Agenten. Die Beobachtbarkeit von KI-Systemen basiert auf demselben Konzept, das auf jede probabilistische KI-Komponente angewendet wird, nicht nur auf autonome Agenten.

Der Grund, warum hierfür eine neue Telemetrie erforderlich ist, liegt darin, dass probabilistische KI-Systeme die deterministischen Annahmen durchbrechen, auf denen die Überwachung beruht. Ein Angriff auf einen KI-Agenten kann unbemerkt gelingen – indem der Agent zu einer schädlichen Aktion manipuliert wird –, ohne dass dabei jemals eine Standard-Fehlermetrik oder Latenzschwelle ausgelöst wird. Nur eine KI-native Telemetrie ermöglicht es, zu ermitteln, was der Agent getan hat, warum er es getan hat und welche Tools und Berechtigungen dabei eine Rolle gespielt haben, sodass ein Verteidiger den Vorfall im Nachhinein rekonstruieren kann.

Das Risiko ist erheblich. Im Februar 2026 setzten rund 80 % der Fortune-500-Unternehmen aktive KI-Agenten ein. Dennoch lag die durchschnittliche Überwachungsabdeckung für KI-Agenten bei lediglich 52 % – was bedeutet, dass 48 % der Agenten ungesichert liefen (Gravitee, 2026). Um einen KI-Agenten für die Beobachtbarkeit auszustatten, erfassen Teams in der Regel folgende Daten:

• Eingabeaufforderungen und Antworten, einschließlich Systemaufforderungen.
• Tool- und Funktionsaufrufe mit Argumenten und Ergebnissen.
• Herkunft der Abrufdaten – welche Dokumente oder Daten einer Antwort zugrunde lagen.
• Metriken zu Tokens und Turn im Verlauf einer Konversation.
• Die Identität und die für jede Aktion geltenden Berechtigungen.

Normen und Vorschriften holen auf. Die OCSF ai_operation profile (v1.8.0, März 2026) bietet KI-Workloads eine erstklassige Schemaabdeckung (OCSF-Veröffentlichungsprotokoll). Das NIST hat am 17. Februar 2026 seine „AI Agent Standards Initiative“ ins Leben gerufen, die unter anderem die Erforschung der Sicherheit und Identität von KI-Agenten umfasst (NIST), und im Rahmen des damit verbundenen NIST-COSAiS-Projekts werden SP 800-53-Kontrollüberlagerungen zur Absicherung von KI-Systemen mit einem oder mehreren Agenten entwickelt (NIST COSAiS). Da sich diese Zahlen und Standards rasch weiterentwickeln, sollten Sie davon ausgehen, dass sie sich innerhalb von etwa sechs Monaten ändern werden, und alle Angaben, die Sie wiederverwenden, mit einem Datum versehen.

Moderne Ansätze zur Beobachtbarkeit von Sicherheitsprozessen

Eine ausgereifte Sicherheitsbeobachtbarkeit geht über die reine Überwachung hinaus und umfasst nun korrelierte, hochgradig komplexe und KI-gestützte Erkennung – wobei sie sich in den bestehenden Stack integriert, anstatt ihn zu ersetzen. Zu wissen, in welche Richtung sich dieser Bereich entwickelt, hilft Teams dabei, einen realistischen Plan zu entwerfen.

Die typischen Herausforderungen bei der Implementierung sind immer dieselben: Die auf der Datenerfassung basierende Abrechnung verteuert die Erfassung in großem Maßstab, cloud Umgebungen schaffen blinde Flecken, und eine Flut von Fehlalarmen überfordert die Analysten – 73 % der Fachleute nannten in der SANS-Umfrage 2025 Fehlalarme als ihre größte Herausforderung bei der Erkennung (Bericht zur SANS-Umfrage). Die herstellerneutralen Best Practices zur Bewältigung dieser Herausforderungen sind ebenso einheitlich: Beginnen Sie mit einer durchdachten Datenerfassungsstrategie und klaren Basiswerten, bevor Sie sich nach Tools umsehen; richten Sie das System auf hohe Kardinalität aus, damit beliebige Fragen weiterhin beantwortbar bleiben; und integrieren Sie die Lösung in den bestehenden SIEM- und endpoint , anstatt alles komplett zu ersetzen, wobei Sie die Observability als Analyseebene über einer einheitlichen Telemetrie betrachten. Sollte die nächste Frage des Lesers die Wirtschaftlichkeit der Bereitstellung oder die Sicherheitslage betreffen, so gehören diese zu angrenzenden Disziplinen – Sicherheitslage-Management für die Sicherheitslage und Bereitstellungsmodelle für die Entscheidung „selbst entwickeln oder kaufen“.

In Bezug auf Compliance lassen sich umfassende Protokollierung und Erkennung klar anerkannten Rahmenwerken zuordnen: Funktionen des NIST CSF 2.0, darunter DETECT (DE.CM – Kontinuierliche Überwachung und DE.AE – Analyse von Sicherheitsvorfällen), RESPOND und IDENTIFY, während DSGVO, HIPAA, PCI DSS, SOX und NIS2 die Anforderungen an die Protokollierung und Aufbewahrung von Audit-Protokollen vorgeben (NIST Cybersecurity Framework). Dies ist eine Übersicht, kein Katalog – die vollständige Taxonomie des Frameworks finden Sie unter „Sicherheits-Frameworks“.

Eine Reifegradskala für die Beobachtbarkeit der Sicherheit

Teams können sich auf einer einfachen fünfstufigen Skala einordnen, die gleichzeitig als Maßstab dafür dient, wie sich die Sicherheitstransparenz entwickelt:

1. Überwachung – vordefinierte Warnmeldungen bei bekannten Signalen.
2. Zentrale Protokollierung – Telemetriedaten an einem Ort zusammengefasst.
3. Korrelierte Telemetrie – Signale, die über verschiedene Datenquellen hinweg miteinander verknüpft sind.
4. Explorative Beobachtbarkeit bei hoher Kardinalität – beliebige Abfragen in großem Maßstab.
5. KI-gestützte Observability nach dem „Detection-as-Code“-Prinzip – versionsverwaltete, automatisierte Erkennung.

Wie Vectra AI das Thema Sicherheitsüberwachbarkeit Vectra AI

Vectra AI Observability als Grundlage für Resilienz – Vectra AI Kombination aus Observability, Signalen und Maßnahmen. Das bedeutet eine flächendeckende Überwachung der modernen Angriffsfläche, sodass Angreifer sich nirgendwo verstecken können, KI-gesteuerte Signale, die echte Angriffe gegenüber Störsignalen priorisieren, sowie fundierte Maßnahmen, die Erkenntnisse in Reaktionen umsetzen. Der Schwerpunkt liegt auf der Methodik, nicht auf den Tools: Umfangreiche Telemetriedaten schaffen nur dann Resilienz, wenn die daraus resultierenden Signale klar genug sind, um mit Sicherheit darauf zu reagieren.