Sicherheitstelemetrie: Die Datenebene, auf der jede Erkennung basiert

Unter Sicherheitstelemetrie versteht man die kontinuierliche, automatisierte Erfassung und Übertragung sicherheitsrelevanter Daten (Protokolle, Ereignisse, Metriken, Traces, Datenströme und Metadaten) von Endgeräten, Netzwerken, cloud , Identitäten und Anwendungen an die Systeme, die diese Daten analysieren. Sie bildet die Grundlage für jede Erkennung, jede Suche, jede Untersuchung und jede forensische Rekonstruktion.

Diese Datenebene ist zu einem zentralen Designproblem geworden. Die Datenmengen steigen stetig an, Angreifer nutzen gezielt die Lücken aus, und die Aufsichtsbehörden legen immer wieder neu fest, welche Daten erfasst und aufbewahrt werden müssen. Dieser Leitfaden erläutert die Arten und Quellen von Sicherheitstelemetrie, wie die Erfassung und Normalisierung funktionieren, woher blinde Flecken stammen, welche Kosten bei der Aufbewahrung der Daten entstehen und wie Rahmenwerke von MITRE ATT&CK bis OMB M-26-14 die Anforderungen prägen.

Was ist Sicherheitstelemetrie?

Sicherheitstelemetrie ist eher ein Ergebnis als ein Produkt: Es handelt sich um den Strom von Signalen, den Endpunkte, Netzwerksensoren, cloud , Identitätsanbieter und Anwendungen während ihres Betriebs aussenden. Wird dieser Strom erfasst und korreliert, bildet er die Faktengrundlage für die Erkennung von Bedrohungen und stellt die oberste Ebene des gesamten nachgelagerten Prozesses dar, denn was nie erfasst wurde, kann auch nie abgefragt werden. Die auf dieser Datenebene aufbauenden Abfrage- und Untersuchungsverfahren, einschließlich der Sicherheitsbeobachtbarkeit, werden auf eigenen Seiten behandelt.

Warum ist Sicherheitstelemetrie wichtig?

Denn moderne Angriffe erstrecken sich über mehrere Domänen hinweg, und die Spuren finden sich selten nur an einer Stelle. Ein Angreifer kann im Rahmen eines einzigen Vorfalls eine Identität durch Phishing erlangen, sich im Netzwerk weiterbewegen und Daten in einem cloud zwischenspeichern. Telemetriedaten aus einer einzigen Domäne reichen für diese Realität strukturell nicht aus, und die Zahlen zeigen, dass Fälle mit mehreren Domänen mittlerweile die Norm sind.

Der aussagekräftigste Beleg ist der Data Breach Report“ (DBIR) 2026 von Verizon, der Vorfälle im Zeitraum vom 1. November 2024 bis zum 31. Oktober 2025 erfasst. Die 19. Ausgabe wurde am 19. Mai 2026 veröffentlicht (Pressemitteilung zum DBIR 2026) und stützt sich auf mehr als 31.000 Vorfälle und mehr als 22.000 bestätigte Datenschutzverletzungen in 145 Ländern (Zusammenfassung des DBIR 2026).

Innerhalb dieses Datensatzes trat das mehrstufige Systemintrusionsmuster bei 61 % der Sicherheitsvorfälle auf – ein Anstieg gegenüber 53 % und 36 % in den beiden vorangegangenen Ausgaben –, und ransomware 48 % der Sicherheitsvorfälle ransomware , ein Anstieg gegenüber 44 % (DBIR-Zusammenfassung 2026). Angriffe, die mehrere Domänen betreffen, hinterlassen ihre Spuren in mehreren Telemetrie-Streams – oder gar nirgendwo. Das ist das Hauptargument dafür, Telemetrie als Portfolio und nicht als einzelnen Feed zu betrachten.

Was ist der Unterschied zwischen Telemetrie, Protokollierung, Überwachung und Beobachtbarkeit?

Beginnen wir mit dem Punkt, über den sich Fachleute tatsächlich uneinig sind. Einige Quellen betrachten Telemetrie als Echtzeit-Datenstrom und Protokollierung als nachträgliche Aufzeichnung – zwei miteinander verbundene, aber unterschiedliche Konzepte. Andere betrachten Protokolle als eine von mehreren Formen der Telemetrie. In der Fachwelt geht der Trend in Richtung dieser zweiten, übergeordneten Sichtweise: Telemetrie umfasst Metriken, Ereignisse, Protokolle und Traces, und die Protokollierung ist die Vorgehensweise, die eine dieser Formen hervorbringt. Diese Seite folgt der übergeordneten Sichtweise und geht an den entscheidenden Stellen auf die Debatte ein.

Überwachung und Observability finden nicht innerhalb der Daten statt, sondern auf einer übergeordneten Ebene. Bei der Sicherheitsüberwachung werden bekannte Signale kontinuierlich auf bekannte Angriffs- und Ausfallzustände hin überwacht, während die Cybersicherheitsüberwachung diesen Ansatz auf die gesamte Umgebung ausweitet. Observability beschreibt, was ein Team mit der Datenebene tun kann: neue Fragen stellen, ohne zuvor neue Messinstrumente implementieren zu müssen. Telemetrie ist das Rohmaterial, auf das alle drei Bereiche zurückgreifen; die folgende Tabelle fasst dies zusammen.

Telemetrie ist die Datenschicht, die Protokollierung stellt eine ihrer Ausprägungen dar, und Überwachung sowie Beobachtbarkeit sind darauf aufbauende Verfahren.

Arten und Quellen von Sicherheitstelemetrie

Sicherheitstelemetrie tritt in vier gängigen Formen auf und stammt aus mindestens fünf Bereichen. Keine einzelne Form und kein einzelner Bereich erfasst einen Angriff in seiner Gesamtheit, daher beginnt die Planung der Abdeckung mit einer Übersicht darüber, was die einzelnen Quellen zeigen können und was nicht.

Die MELT-Taxonomie

Die in der Branche gebräuchliche Abkürzung für die verschiedenen Arten von Telemetriedaten lautet MELT: Metriken, Ereignisse, Protokolle und Traces.

• Metriken sind numerische Messwerte, die über einen bestimmten Zeitraum erfasst werden, wie beispielsweise die Anzahl der Authentifizierungsfehler pro Minute auf einem VPN-Konzentrator. Sie sind kompakt und lassen sich kostengünstig speichern, was sich gut für die Ermittlung von Basiswerten und die Erkennung von Trends eignet.
• Ereignisse sind einzelne Aufzeichnungen von Vorgängen, die zu einem bestimmten Zeitpunkt stattfinden, wie beispielsweise der Start eines Prozesses oder das Blockieren einer Verbindung durch eine Firewall. Der Großteil der Erkennungslogik basiert auf Ereignissen.
• Protokolle sind mit einem Zeitstempel versehene Datensätze, die von Betriebssystemen, Anwendungen und Diensten ausgegeben werden – von Windows-Ereignisprotokollen bis hin zu cloud . Sie enthalten die umfangreichsten Kontextinformationen und verursachen die höchsten Speicherkosten.
• Traces verfolgen eine einzelne Anfrage oder Transaktion über verteilte Dienste hinweg. Im Sicherheitsbereich helfen sie dabei, nachzuvollziehen, wie sich eine Aktion durch verbundene Systeme ausgebreitet hat.

Telemetrie nach Domäne

• Endpoint EDR-Telemetrie. Von Host-Agenten erfasste Prozessstarts, Datei- und Registrierungsänderungen, das Laden von Modulen sowie Skriptaktivitäten. Dies ist die umfassendste Übersicht über das Verhalten auf dem Host, die jedoch nur dort verfügbar ist, wo ein Agent installiert ist und ausgeführt wird.
• Netzwerktelemetrie. Datensätze zum Datenfluss wie NetFlow und IPFIX, DNS-Abfragen sowie Attribute des TLS-Handshakes, die in der Regel als Metadaten und nicht als vollständige Pakete extrahiert werden. Da die Sensoren an Taps und Mirror-Ports statt auf Hosts angebracht sind, erkennt die Netzwerkverkehrsanalyse auch nicht verwaltete und vorübergehend vorhandene Geräte, die von agentenbasierten Tools nicht erfasst werden können.
• Cloud . Audit-Protokolle der Steuerungsebene, Flow-Protokolle und Workload-Signale aus Infrastruktur- und SaaS-Plattformen. Es handelt sich um das zentrale Erfassungssystem für cloud , wobei jedoch ein später noch zu erwähnender Vorbehalt besteht: Anbieter filtern oder stichprobenartig erfassen bestimmte Protokolltypen standardmäßig.
• Identitäts-Telemetrie. Anmelde- und Protokollaufzeichnungen aus Verzeichnissen, Identitätsanbietern, SaaS-Anwendungen, dem privilegierten Zugriffsmanagement und Verbunddiensten. Die Erfassung muss sich auch auf nicht-menschliche Identitäten erstrecken, darunter Dienstkonten, API-Schlüssel und KI-Agenten – dies bildet die Datengrundlage, auf der die Erkennung und Abwehr von Identitätsbedrohungen aufbaut.
• XDR- und MDR-Telemetrie. XDR-Plattformen korrelieren Telemetriedaten aus verschiedenen Domänen zu einheitlichen Erkennungsergebnissen, während MDR-Anbieter ihren Erkennungsdienst auf der Grundlage aller Telemetriedaten betreiben, die in der Kundenumgebung anfallen. Beide nutzen die oben genannten Domänen, anstatt eine neue hinzuzufügen.

Alarm- und Überprüfungsdaten runden das Bild ab. Firewalls sowie Systeme zur Erkennung und Abwehr von Eindringlingen liefern eigene Bewertungen und Erkennungsergebnisse und sind nach wie vor wichtige Quellen für die Netzwerksicherheit, auch wenn sie das Verhalten eher beobachten als rekonstruieren.

Ein Aspekt ist wirklich neu. Der DBIR 2026 ergab, dass 45 % der Mitarbeiter KI regelmäßig auf Unternehmensgeräten nutzen – ein Anstieg gegenüber 15 % im Vorjahr (Zusammenfassung des DBIR 2026). Die Telemetriedaten zur Nutzung von Browsern und KI-Tools werden daher zu einer erstklassigen Informationsquelle, da sich die nicht genehmigte Nutzung von KI genau dort konzentriert, wo herkömmliche Sicherheitsagenten am wenigsten hinschauen.

Fünf Telemetriebereiche, was jeder einzelne davon auf einzigartige Weise offenbart und welche Lücken bei der Erfassung entstehen, wenn sie einzeln genutzt werden.

So funktioniert Sicherheitstelemetrie

Rohsignale werden über eine Pipeline zu verwertbaren Telemetriedaten: Erfassen, Übertragen, Normalisieren, Weiterleiten, Speichern, Analysieren. Jede Stufe ist eine Designentscheidung, und mehrere Stufen stellen für sich genommen Angriffsflächen dar.

Die Datenerfassung erfolgt über Agenten auf Hosts, Sensoren an Netzwerk-Taps und Mirror-Ports, API-Abfragen bei cloud SaaS-Plattformen sowie in moderne Software integrierte Streaming-Exporter. Die Tap-basierte Erfassung zeichnet sich dadurch aus, dass sie passiv ist: Ein Sensor, der einen Mirror-Port überwacht, benötigt keine Installation auf dem endpoint, was den Verteidigern einen Kanal bietet, den Angreifer von einem kompromittierten Host aus nicht ohne Weiteres erreichen können. Die Übertragung leitet die Daten anschließend zur Analyse weiter, wobei Batching, Pufferung und Gegendruck zum Einsatz kommen, damit bei Datenbursts keine Ereignisse unbemerkt verloren gehen.

Insgesamt sieht der Ablauf wie folgt aus:

1. Instrument-Quellen mit Agenten, Sensoren, Exportern und API-Integrationen.
2. Erfassen Sie Ereignisse, Metriken, Protokolle und Traces kontinuierlich.
3. Übertragung mit Batch-Verarbeitung, Pufferung und Gegendrucksteuerung.
4. Normalisieren Sie alles in ein gemeinsames Schema.
5. Leiten Sie jeden Datenstrom an die Analyse, die Speicherung oder an beides weiter.
6. Nach Temperaturstufen lagern: heiß, warm und kalt.
7. Analyse im Hinblick auf Erkennung, Ermittlungen und Fahndungen.

‍

Durch die Normalisierung lassen sich Telemetriedaten verschiedener Anbieter miteinander verknüpfen. Das Open Cybersecurity Schema Framework (OCSF) verleiht Sicherheitsereignissen eine gemeinsame, herstellerneutrale Struktur. OpenTelemetry standardisiert die Instrumentierung von Software sowie den Export ihrer Metriken, Protokolle und Traces, und das Projekt stellt spezielle Sicherheitsrichtlinien zur Absicherung seiner Collector-Komponenten bereit. Elastic Common Schema (ECS) und das Common Information Model (CIM) verfolgen innerhalb ihrer jeweiligen Ökosysteme dasselbe Ziel. Bei allen vier handelt es sich um Eigenschaften, die beschreiben, wie die Daten nach der Normalisierung aussehen – nicht um Analysetools.

Von dort gelangen die Daten in eine Analyseebene. Ein SIEM-System gleicht normalisierte Telemetriedaten anhand von Regeln und Verhaltensmodellen ab, um Warnmeldungen zu generieren, und diese Seite endet an dessen „Haustür“. Die Praxis der offenen Abfragen und Untersuchungen, die auf derselben Datenebene stattfindet, gehört zum Bereich der Observability, der für diese Arbeit zuständig ist.

Die Messung der Telemetriedaten selbst sorgt für Transparenz in der Pipeline. Vier Kennzahlen spielen dabei eine entscheidende Rolle: die Abdeckung, d. h. welche Techniken des Erkennungs-Frameworks Ihre Quellen nachweisen können, das Erfassungsvolumen und die damit verbundenen Kosten, die Latenz von der Ereigniserzeugung bis zur Analyse sowie die Vollständigkeit, d. h. dass die Datenströme lückenlos und ohne stillschweigende Ausfälle ankommen. Schwache Werte bei einer der vier Kennzahlen zeigen sich später als blinde Flecken. Verfolgen Sie diese pro Quelle und nicht als einen globalen Durchschnittswert.

Sicherheitstelemetrie in der Praxis

Drei Fälle, die sich über einen Zeitraum von 13 Jahren erstrecken, verdeutlichen den Unterschied zwischen dem bloßen Vorhandensein von Telemetriedaten, der Vollständigkeit dieser Daten und der Umsetzung der daraus gewonnenen Erkenntnisse. Jeder dieser Fälle zeigt zudem, warum Analysten Telemetriedaten als Beweismittel betrachten: Sie müssen vorhanden sein, den richtigen Bereich abdecken und jemanden oder etwas erreichen, der bzw. das darauf reagiert.

• Hugging Face (2026): Telemetriedaten wurden ausgewertet. Das Unternehmen berichtete, dass seine „Pipeline zur Erkennung von Anomalien eine LLM-basierte Triage der Sicherheitstelemetriedaten nutzt, um echte Signale vom alltäglichen Rauschen zu trennen, und dass es die Korrelation dieser Signale war, die auf den Angriff hinwies“ (Offenlegung von Hugging Face). Der Vorfall wurde vom betroffenen Unternehmen selbst gemeldet, wobei kein zeitlicher Rahmen für den Angriff angegeben wurde. Er wurde am 16. Juli 2026 bekannt gegeben und fand am 20. Juli breitere, neutrale Berichterstattung (Help Net Security). Berichte bestätigten Auswirkungen auf interne Datensätze und Anmeldedaten (TechCrunch).
• SolarWinds SUNBURST (2020): Unvollständige Telemetrie. Das am 13. Dezember 2020 öffentlich bekannt gegebene Implantat in der Lieferkette tarnte seinen Command-and-Control-Datenverkehr als legitime Produkttelemetrie und umging so endpoint (Mandiant-Analyse zu SUNBURST). Eine Endpoint Telemetrie kann Aktivitäten, die über vertrauenswürdige Kanäle laufen, übersehen.
• Target (2013): Telemetriedaten wurden ignoriert. Einem Bericht der Mitarbeiter des Handelsausschusses des US-Senats vom 26. März 2014 zufolge hat Target offenbar nicht auf mehrere automatische Warnmeldungen der firmeneigenen Anti-Intrusion-Software reagiert, während Angreifer malware installierten, bevor die Daten das Netzwerk verließen (Senatsanalyse „Kill Chain“). Erkennungsfähigkeit ohne Triage ist keine Erkennung.

Die Verweildauer ist ein Maßstab für den Erfolg, und sie entwickelt sich in die falsche Richtung. M-Trends 2026, das das Kalenderjahr 2025 mit mehr als 500.000 Stunden für die Reaktion auf Vorfälle abdeckt, ergab, dass die globale Median-Verweildauer von 11 auf 14 Tage gestiegen ist, wobei Vorfälle im Zusammenhang mit Cyberspionage und nordkoreanischen IT-Fachkräften einen Median von 122 Tagen aufwiesen (M-Trends 2026). Die Vorgängerauflage, M-Trends 2025, die das Kalenderjahr 2024 abdeckt, liefert den Ausgangswert von 11 Tagen. Um diese Lücke zu schließen, kommt es weniger auf mehr Rohdaten an als vielmehr auf eine Erfassung, die threat hunting zwischen den Warnmeldungen und einer Triage-Disziplin, die Signale in eine Incident-Response-Maßnahme umwandelt, bevor sich die Verweildauer weiter verlängert.

Blinde Flecken in der Telemetrie und wie Angreifer diese ausnutzen

Was nie aufgezeichnet wurde, lässt sich nicht erkennen. Blinde Flecken lassen sich in zwei grundsätzlich unterschiedliche Fehlermodi einteilen: Erfassungslücken, bei denen das Ereignis gar nicht erst erfasst wird, und Manipulationen, bei denen es zwar erfasst, anschließend aber unterdrückt wird. Beides trägt zur Alarmflut bei: SOC-Teams müssen mehr Alarme bearbeiten, als sie einordnen können, und die Alarmmüdigkeit lässt die wenigen Signale von Angreifern unter der weitaus größeren Menge an Alarmen untergehen, die den normalen Betrieb beschreiben. Der DBIR 2026 verdeutlicht die Kosten einer langsamen Isolierung: Die mediane Zeit bis zur vollständigen Behebung betrug 43 Tage, und nur 26 % der kritischen Schwachstellen auf der CISA-Liste der „Known Exploited Vulnerabilities“ wurden vollständig behoben – ein Rückgang gegenüber 38 % (Zusammenfassung des DBIR 2026).

Erfassungslücken: Die Daten werden nie erhoben

Nicht verwaltete Geräte, Edge-Geräte, IoT-Geräte und Geräte der Betriebstechnik (OT) führen keine Agenten aus, sodass keine Host-Telemetriedaten von ihnen vorliegen. Der DBIR 2026, der Vorfälle bis einschließlich Oktober 2025 abdeckt, stellte fest, dass die Ausnutzung von Schwachstellen auf 31 % der Sicherheitsverletzungen angestiegen ist und damit den häufigsten Erstzugriffsvektor darstellt (Zusammenfassung des DBIR 2026). Bereits der DBIR 2025 hatte 22 % der Angriffe durch Ausnutzung von Sicherheitslücken auf Edge-Geräte und VPNs zurückgeführt (DBIR 2025). Filterung und Stichprobenahme auf Anbieterseite führen zu einer ähnlichen Lücke in cloud .

Auch die Identitäts-Telemetrie versagt unbemerkt. Eine im Juli 2026 veröffentlichte Bedrohungsanalyse eines Anbieters beschrieb das Spoofing von OAuth-Client-IDs in Entra-ID-Umgebungen: Bei einer gefälschten Client-ID bleibt das Feld für den Anwendungsnamen leer, sodass Erkennungsmechanismen, die auf eine namentlich genannte Anwendung ausgerichtet sind, diese Aktivität vollständig übersehen können (Help Net Security). Eine seit Dezember 2025 verfolgte Kampagne nutzte mehr als 3,7 Millionen gefälschte Anwendungs-IDs gegen mehr als zwei Millionen Benutzerkonten und prüfte die Gültigkeit der Anmeldedaten, „ohne ein erfolgreiches Anmeldeereignis zu erzeugen“ (The Hacker News). Keine ATT&CK-Technik-ID deckt dieses Verhalten ab: Es handelt sich um eine Lücke in der Abdeckung, nicht um Manipulation, da nie etwas darüber geschrieben wurde.

Manipulation: Die Daten werden erst erstellt und anschließend unterdrückt

Wo Telemetriedaten erzeugt werden, unterdrücken Angreifer diese. MITRE ATT&CK erfasst dies als T1685 Werkzeuge deaktivieren oder ändern im Rahmen der Taktik „Defense Impairment“ (TA0112): Gegner, die Verteidigungssoftware selbst außer Kraft setzen oder verändern, darunter EDR-Tools, IDS, Antivirenprogramme sowie Protokollierungsagenten und Sensoren; das Wettrüsten, das unter Umgehung der EDR. Alle sechs Teiltechniken zielen auf den Datensatz oder die Sichtweise des Analysten darauf ab: Deaktivieren oder Ändern des Windows-Ereignisprotokolls, cloud oder des Linux-Audit-Systemprotokolls, Ändern oder Fälschen der Benutzeroberfläche eines Tools sowie Löschen von Windows-Ereignisprotokollen oder Linux- und Mac-Systemprotokollen.

Der Druck ist groß. Ein Branchenbericht zu Sicherheitsbedrohungen für das Jahr 2025 ergab, dass rund 82 % der Erkennungen malware waren, wobei der schnellste gemessene Ausbruch etwa 27 Sekunden dauerte. Angreifer, die sich mit legitimen Anmeldedaten und Tools so schnell bewegen, haben jedes Interesse daran, die Host-Telemetrie auszuschalten.

Die Erfassungsschicht ist selbst Software

Auch die Erfassungsschicht ist Software. Zwei OpenTelemetry-Sicherheitslücken aus dem Jahr 2026, CVE-2026-40182, eine unbegrenzte Antwort, die in der .NET-Implementierung eingelesen wird und den Arbeitsspeicher erschöpfen kann (NIST CVSS 5.9), sowie CVE-2026-45287, ein Dateideskriptor-Leck in OpenTelemetry-Go, das zu einem Denial-of-Service führen kann, stellt sowohl ein Verfügbarkeits- als auch ein Ressourcenerschöpfungsproblem dar. Ein abgestürzter Collector blockiert den gesamten nachgelagerten Datenfluss. Die Bewertungen des zweiten Fehlers zeigen zudem, warum eine Triage anhand eines einzigen Wertes anfällig ist: Das NIST bewertete ihn nach CVSS 3.1 mit 5,5, während die CVE Numbering Authority ihn nach CVSS 4.0 mit 2,1 bewertete – derselbe Fehler wird also je nach Quelle sehr unterschiedlich eingestuft.

Alle in der nachstehenden Tabelle aufgeführten Ausgleichsquellen haben eine gemeinsame Eigenschaft: Sie sind unabhängig vom kompromittierten Host. Wenn Agenten fehlen, deaktiviert sind oder falsche Angaben machen, sind die Netzwerkdaten aus Taps und Mirrors die Aufzeichnungen, die Eindringlinge nicht unterdrücken können – das zentrale Argument für Netzwerktransparenz sowie Netzwerküberwachung und -reaktion.

Fünf häufige blinde Flecken in der Telemetrie, die jeweiligen Fehlerursachen und die Ausgleichsmaßnahmen, die die Sichtbarkeit wiederherstellen.

Die wirtschaftlichen Aspekte der Sicherheitstelemetrie

Das Wachstum der Telemetriedaten ist mittlerweile ein eigener Budgetposten mit Auswirkungen auf die Sicherheit. Der „Telemetry Trends“-Bericht von Cribl ergab, dass die wichtigsten Datenquellen (Syslog, TCP und TCP JSON) im Zeitraum von April 2024 bis April 2025 jeweils um mehr als 60 % gegenüber dem Vorjahr zugenommen haben (Cribl Telemetry Trends). Die Preisgestaltung auf Analytics-Ebene erfolgt in der Regel pro eingelesenem Gigabyte, sodass sich das Wachstum direkt auf das Betriebsbudget des SOC auswirkt. Der Kostendruck wird so zu einem versteckten Sicherheitsproblem: Teams, die Quellen pauschal streichen, um Geld zu sparen, schaffen sich damit eine Sicherheitslücke – und erzielen keine Einsparungen.

Eine Telemetrie-Pipeline-Schicht ist die sich abzeichnende Lösung. Gartners „Market Guide for Telemetry Pipelines“, der am 2. September 2025 veröffentlicht wurde, prognostiziert: „Bis 2027 werden 40 % aller Log-Telemetriedaten über ein Telemetrie-Pipeline-Produkt verarbeitet werden – gegenüber weniger als 20 % im Jahr 2024“ (Gartner Market Guide for Telemetry Pipelines). Eine Pipeline befindet sich zwischen den Produzenten und den Zielsystemen und dient der Erfassung, Verarbeitung und Weiterleitung: Sie filtert Störsignale heraus, reichert Datensätze an, passt Schemata an und ordnet jeden Datenstrom einer Ebene zu, bevor die Daten die Analyseebene erreichen.

Diese Analyseebene wird in der Regel durch ein SIEM abgedeckt, und die pro Gigabyte anfallenden SIEM-Erfassungsdaten sind der Posten, den die Pipelines schützen sollen. Als orientierender Marktkontext dient die SIEM-Marktanalyse des syndizierten Aggregators Mordor Intelligence, die den Markt für das Jahr 2026 auf 12,06 Milliarden US-Dollar schätzt, mit einem Anstieg auf 20,78 Milliarden US-Dollar bis 2031 – was einer durchschnittlichen jährlichen Wachstumsrate von 11,50 % entspricht. Dieselbe Analyse behauptet – auf eigene Grundlage und ohne unabhängige Primärdaten – dass Unternehmen mit mehr als 10.000 Mitarbeitern täglich über 10 Terabyte an Protokolldaten erfassen. Beide Angaben sollten eher als Richtwerte denn als präzise Messgrößen betrachtet werden.

Die Aufteilung der Aufbewahrungsstufen ist die andere Hälfte der Kostenkontrolle. Halten Sie Daten aus der Echtzeit-Erkennung im „Hot“-Status, Untersuchungsdaten im „Warm“-Status und Compliance-Daten im „Cold“-Status und entkoppeln Sie den Speicher von der Analyse-Engine, damit historische Daten weiterhin abfragbar bleiben, ohne dass die Preise der „Hot“-Stufe anfallen.

Durch die mehrstufige Aufbewahrung wird jede Telemetrie-Nutzung einer Speicherklasse zugeordnet, sodass die Abdeckung gewährleistet bleibt, ohne dass für alles die Preise der „Hot-Tier“-Klasse anfallen.

Die Strategie, die all dies miteinander verbindet, ist das zielgerichtete Logging: Zunächst werden Erkennungsziele definiert, diese werden dann den für die Erkennung erforderlichen Telemetriedaten zugeordnet, und alles andere wird prioritätsmäßig herabgestuft oder ganz weggelassen. Praktische Leitfäden wie der Leitfaden zur Telemetrie-Strategie von Security Blue Team verdeutlichen denselben Ansatz: Jede Entscheidung zur Datenerfassung sollte auf einen Erkennungs- oder Untersuchungszweck zurückzuführen sein, nicht auf Gewohnheit.

Sicherheitstelemetrie, Frameworks und Compliance

Die Anforderungen an die Telemetrie werden zunehmend von Rahmenwerken und Aufsichtsbehörden vorgegeben, und das Jahr 2026 markiert einen Neuanfang für zwei wichtige Bezugspunkte.

Zuordnung von Telemetriedaten zu MITRE ATT&CK

Telemetrie-Kartierung im Inneren MITRE ATT&CK innerhalb von sechs Monaten zweimal geändert. Mit Version 18, die am 28. Oktober 2025 veröffentlicht wurde, wurde die veraltete Komponente „Datenquellen“ zugunsten von Erkennungsstrategien (DET) und Analysen (AN) als veraltet markiert (MITRE ATT&CK – Versionshinweise zur Veröffentlichung MITRE ATT&CK 2025). In Version 19, die am 28. April 2026 veröffentlicht wurde, wurde „Verteidigungsausweichen“ dann in „Tarnung“ (TA0005) und „Verteidigungsbeeinträchtigung“ (TA0112) unterteilt (MITRE ATT&CK – Versionshinweise zur Veröffentlichung MITRE ATT&CK 2026). Ältere Datenquellen-IDs wie beispielsweise DS0029, DS0038und DS0002 Sie tauchen zwar nach wie vor in Fachpublikationen auf, sind jedoch historische Bezeichnungen aus einem veralteten Modell und stellen keine aktuellen Leitlinien dar. Für Detektionstechnik Teams: Die Abdeckungskartierung beginnt nun bei den Erkennungsstrategien und den darunter liegenden Analysen, wobei jeweils die benötigten Telemetriedaten angegeben werden.

OMB M-26-14 und die Neufestsetzung der Holzeinschlagquoten des Bundes für 2026

Im OMB-Memorandum M-26-14 vom 22. Mai 2026 heißt es: „Mit sofortiger Wirkung wird das OMB-Memorandum M-21-31 aufgehoben.“ Die risikobasierte Priorisierung ersetzt die Protokollierung, bei der alle Daten aufbewahrt werden, und orientiert sich an zwei Zielen: Continuous Event Monitoring (CEM) sowie Threat Hunting, Investigation, Response und Forensics (THIRF). Das Reifegradmodell umfasst fünf Stufen, von Stufe 0 „Ineffektiv“ bis Stufe 4 „Optimal“, wobei das Memorandum selbst die Bezeichnung für Stufe 1 uneinheitlich verwendet: „Basic“ in der Tabelle zu den Fristen für die Einhaltung der Vorschriften, „Initial“ in Anhang C. Der Geltungsbereich umfasst zivile Systeme der US-Bundesbehörden, wobei IoT und OT ausdrücklich eingeschlossen sind, während Systeme der nationalen Sicherheit, des Verteidigungsministeriums und der Nachrichtendienste ausgeschlossen sind.

In dem Memo wird die CISA mit der Erstellung einer Referenzarchitektur für die Protokollierung (Logging Reference Architecture, LRA) beauftragt, die zum Stand vom 20. Juli 2026 noch nicht veröffentlicht ist. Die CISA-Ressourcenseite ist ein Platzhalter vom 26. Mai 2026, auf dem angegeben ist, dass sie aktualisiert wird, sobald die LRA fertiggestellt ist und die 90-Tage-Frist um den 20. August 2026 herum abläuft.

‍

Standards und Faktoren für die Kundenbindung

NIST SP 800-92, der grundlegende Leitfaden zum Protokollmanagement, stammt aus dem September 2006, und die öffentliche Konsultation zum Entwurf der Revision 1 endete am 29. November 2023, ohne dass dieser endgültig verabschiedet wurde; daher bleibt die Originalfassung von 2006 weiterhin die maßgebliche Grundlage. NIST CSF 2.0 verankert die Telemetrie in seiner „Detect“-Funktion unter der Kategorie „DE.CM Continuous Monitoring“. OWASP hat A09:2021 „Security Logging and Monitoring Failures“ in A09:2025 „Security Logging and Alerting Failures“ umbenannt und dabei die Nummer 9 beibehalten. Das CISA Zero Trust Model nennt „Visibility and Analytics“ als eine seiner übergreifenden Fähigkeiten.

Die Aufbewahrungspflichten ergeben sich aus einem breiteren Rahmenwerk. PCI DSS, DSGVO, NIS2, HIPAA und SOC 2 legen alle fest, wie lange Telemetriedaten aufbewahrt werden müssen, und die Berichterstattung zur Einhaltung der Vorschriften beansprucht die archivierten Speicherebenen – eine nützliche Erinnerung daran, dass M-26-14 eine Richtlinie der US-Bundesregierung ist, während diese Faktoren weltweit gelten.

Wie wichtige Rahmenwerke und Vorschriften auf Sicherheitstelemetrie Bezug nehmen, mit Angabe der jeweiligen Version bzw. des jeweiligen Status Stand Juli 2026.

Moderne Ansätze zur Sicherheitstelemetrie

Die Entwicklung geht in Richtung weniger, aber besserer Signale bei einer breiteren Abdeckung. Vier Maßnahmen prägen den modernen Ansatz: „Pipeline-First“-Architekturen, die bereits vor der Analyseebene filtern und weiterleiten, offene Normalisierungsschemata, die Daten verknüpfbar und portabel halten, entkoppelte Speicherung, die die Aufbewahrung historischer Daten kostengünstig macht, sowie KI-gestützte Triage, die die Telemetriedaten selbst auswertet, anstatt einen weiteren Alarmstrom hinzuzufügen. Für SOC-Betriebsteams besteht der Test für jede dieser Maßnahmen darin, ob sich der Abstand zwischen dem Rohsignal und einer fundierten Entscheidung verringert.

Der neueste Bereich der Telemetrie ist die KI selbst. Der DBIR 2026 stufte die Nutzung von „Shadow-KI“ in seinem Datensatz zur Verhinderung von Datenverlusten als dritthäufigste nicht böswillige Insider-Handlung ein (DBIR 2026 – Zusammenfassung), und KI-Agenten sowie andere nicht-menschliche Identitäten entwickeln sich zunehmend zu vollwertigen Erzeugern und Nutzern von Telemetriedaten. Absicherungskonzepte, die sich auf menschliche Nutzer und verwaltete Hosts beschränken, hinken bereits hinterher.

Wie Vectra AI das Thema Sicherheitstelemetrie Vectra AI

Vectra AI von der Prämisse Vectra AI , dass ein Angriff bereits stattgefunden hat: Kompetente Angreifer werden sich Zugang verschaffen – daher lautet die entscheidende Frage, wie schnell sich ihr Verhalten in den Daten bemerkbar macht. Eine umfassende Telemetrie im modernen Netzwerk, die den Campus, das Rechenzentrum, cloud und die Identitätsverwaltung abdeckt, ist notwendig, aber nicht ausreichend. Die eigentliche Herausforderung besteht darin, diese Breite in eine kleine Anzahl hochpräziser Angriffssignale umzuwandeln, auf die ein Analyst mit Sicherheit reagieren kann.

‍