SIEM vs. Observability: Wie sich Security Monitoring und Observability unterscheiden, wo sie sich überschneiden und wie Sie beides verbinden

Die Frage „SIEM vs. Observability“ taucht meist dann auf, wenn zwei Teams feststellen, dass sie dieselben Logs doppelt sammeln, doppelt bezahlen und im Ernstfall trotzdem keine schnelle Antwort auf eine einfache Frage haben: Ist dieser Ausfall ein Angriff, ein fehlerhaftes Deployment oder beides? Security-Teams betreiben ein SIEM, um Bedrohungen zu erkennen und Compliance nachzuweisen. SRE- und Plattform-Teams betreiben eine Observability-Plattform, um Services zuverlässig und performant zu halten. Beide schauen auf Telemetrie aus denselben Systemen, teilen aber selten Daten, Kontext oder Prozesse.

Dieser Beitrag vergleicht beide Disziplinen herstellerneutral: welche Daten sie nutzen, worauf sie optimiert sind, wie sich Aufbewahrung und Kostenmodelle unterscheiden, wie Erkennung funktioniert und wer mit welchem Werkzeug arbeitet. Anschließend zeigen wir, was „Security Observability“ in der Praxis bedeutet, mit einer Vergleichstabelle und einer Architektur-Checkliste, die Sie direkt in Ihre eigene Planung übernehmen können.

SIEM und Observability in jeweils einem Absatz

SIEM (Security Information and Event Management) bezeichnet eine Werkzeugkategorie, die sicherheitsrelevante Ereignisse aus der gesamten Organisation sammelt, normalisiert, mit Erkennungsregeln und Threat Intelligence korreliert und so lange vorhält, wie Untersuchungen und Audits es erfordern. Typische Quellen sind Anmeldeprotokolle, Firewall- und Proxy-Logs, Ereignisse aus Endpoint-Detection-Lösungen, Cloud-Audit-Trails und Ereignisse des Identity Providers. Typische Ergebnisse sind Security-Alerts für das Security Operations Center (SOC), Ermittlungszeitleisten und Compliance-Berichte.

Observability ist die Fähigkeit, den inneren Zustand eines Systems aus der Telemetrie zu verstehen, die es aussendet. Eine Observability-Plattform sammelt Metriken, Logs, Traces, Profile und Events aus Anwendungen und Infrastruktur, verknüpft sie über gemeinsamen Kontext wie Trace-IDs und Servicenamen und hilft Engineers, Störungen zu erkennen, zu analysieren und zu verhindern. Typische Ergebnisse sind SLO-Berichte, Alerts auf Symptome wie Latenz oder Fehlerrate und Root-Cause-Analysen. Gute Observability beginnt mit strukturiertem Logging und konsistenten Metadaten, und genau das hilft, wie Sie gleich sehen, auch der Security.

Die wichtigsten Unterschiede: Daten, Ziele, Aufbewahrung und Kosten

Datenquellen

Ein SIEM konzentriert sich auf Sicherheitsereignisse: Wer hat sich von wo angemeldet, welche Berechtigungen wurden geändert, welcher Prozess wurde auf welchem Endgerät gestartet, welche Netzwerkverbindung wurde blockiert? Viele dieser Quellen, etwa Identity Provider, Endpoint-Agenten oder Netzwerkgeräte, sind selten Teil eines Observability-Setups. Eine Observability-Plattform konzentriert sich auf das Verhalten von Services: Anfrageraten, Latenzen, Fehlercodes, Ressourcenverbrauch, verteilte Traces und Anwendungslogs. Die Schnittmenge ist real, aber begrenzt. Anwendungslogs, Kubernetes-Audit-Logs, Cloud-Audit-Trails, Load-Balancer-Logs und Webserver-Access-Logs sind für beide Seiten wertvoll.

Ziele

Das SIEM beantwortet die Frage: „Tut jemand etwas, das er nicht tun sollte, und können wir belegen, was passiert ist?“ Die Observability-Plattform beantwortet: „Erhalten unsere Nutzer eine schnelle und korrekte Erfahrung, und wenn nicht, warum?“ Beide Fragen stellen sich oft im selben Incident. Ein Anstieg von 5xx-Fehlern kann ein misslungenes Release sein oder ein Credential-Stuffing-Angriff, der den Login-Service überlastet.

Aufbewahrung und Kostenmodelle

Security- und Compliance-Anforderungen verlangen für auditrelevante Ereignisse häufig lange Aufbewahrungsfristen, je nach Regulierung und interner Richtlinie oft ein Jahr oder länger. Observability-Daten sind meist in den ersten Tagen und Wochen am wertvollsten. Hochaufgelöste Daten werden daher kurz gehalten, ältere Daten verdichtet oder archiviert. Viele SIEMs werden nach Datenvolumen oder Ereignissen pro Sekunde abgerechnet, sodass das ungefilterte Weiterleiten aller Logs teuer wird. Observability-Plattformen nutzen eine Mischung aus Preisen pro Host, pro GB und pro Signal. In beiden Welten ist der wirksamste Kostenhebel, schon vor der Speicherung zu entscheiden, welche Daten wohin gehen und wie lange sie bleiben. Unser Lexikoneintrag zur Datenaufbewahrung erklärt die Abwägungen.

Erkennungslogik

Die Erkennung im SIEM basiert auf Korrelationsregeln (zum Beispiel viele fehlgeschlagene Anmeldungen, gefolgt von einer erfolgreichen aus einem neuen Land), auf dem Abgleich mit Signaturen und Indikatoren aus Threat Intelligence, auf Zuordnungen zu Frameworks wie MITRE ATT&CK und in vielen Produkten auf User and Entity Behavior Analytics (UEBA), die das normale Verhalten je Nutzer oder Host als Baseline lernt. Die Erkennung in der Observability basiert auf Service Level Objectives mit Burn-Rate-Alerts, Schwellwerten auf den Golden Signals, Anomalieerkennung auf Metriken und topologiebasierter Korrelation, die Symptome nach ihrer wahrscheinlichen Ursache gruppiert. Beide arbeiten mit Baselines und Anomalien, aber sie beobachten Unterschiedliches: Identitäten auf der einen, Services auf der anderen Seite.

Wer damit arbeitet: SOC versus SRE- und Plattform-Teams

Das SIEM ist das zentrale Werkzeug des SOC: Security-Analysten bewerten Alerts, Threat Hunter suchen nach verdächtigen Mustern und Incident Responder rekonstruieren den Ablauf von Angriffen. Compliance- und Audit-Teams nutzen die Berichte. Die Observability-Plattform ist das zentrale Werkzeug von SRE-, Plattform- und Entwicklungsteams: Engineers in Rufbereitschaft reagieren auf Alerts, Entwickler analysieren Performance-Probleme und Plattform-Teams planen Kapazitäten.

Reibung entsteht an der Grenze. Eine SOC-Analystin sieht eine verdächtige ausgehende Verbindung von einer IP-Adresse, weiß aber nicht, welcher Service dort läuft, wem er gehört oder ob er gerade neu ausgerollt wurde. Ein SRE sieht eine Latenzspitze an der Login-API, weiß aber nicht, dass das SOC bereits eine Brute-Force-Kampagne gegen genau diese API verfolgt. Jedes Team hat die halbe Wahrheit, und die Übergabe läuft über Chatnachrichten und Screenshots.

Vergleichstabelle: SIEM, Observability-Plattform und kombinierter Ansatz

Die Tabelle fasst die Dimensionen zusammen und zeigt, wie ein kombinierter Security-Observability-Ansatz jeweils aussieht.

Dimension	SIEM	Observability-Plattform	Kombinierter Ansatz
Hauptziel	Bedrohungserkennung, Ermittlung, Compliance-Nachweise	Zuverlässigkeit, Performance, schnelle Ursachenanalyse	Gemeinsames Lagebild: Angriff, Änderung oder beides?
Wichtigste Datenquellen	Identitäts-, Endpoint-, Netzwerk-, Cloud-Audit- und Security-Tool-Ereignisse	Metriken, Logs, Traces, Profile, Deployment- und Change-Events	Eine Pipeline sammelt einmal und verteilt je Anwendungsfall
Datenmodell	Normalisierte Sicherheitsereignisse, oft in Hersteller- oder Standardschema	OpenTelemetry-Signale mit Ressourcenattributen und Trace-Kontext	Einheitliche Attribute für Service, Umgebung und Verantwortliche an jedem Ereignis
Erkennungslogik	Korrelationsregeln, Threat Intelligence, UEBA	SLOs und Burn Rates, Anomalieerkennung, Topologiekorrelation	Security-Alerts mit Laufzeitkontext; Zuverlässigkeits-Alerts markieren sicherheitsrelevante Muster
Aufbewahrung	Lang, getrieben durch Audit und Regulierung	Kurz für hochaufgelöste Daten, länger für Aggregate	Fristen je Datenklasse statt je Werkzeug
Kostentreiber	Datenvolumen oder Ereignisse pro Sekunde	Hosts, GB, Signale oder eine Mischung	Filtern, Sampling und Routing vor der Speicherung
Hauptnutzer	SOC-Analysten, Threat Hunter, Compliance	SRE-, Plattform- und Entwicklungsteams	Gemeinsame Incident-Rollen mit klaren Übergaben
Typisches Ergebnis	Security-Alerts, Fälle, Audit-Berichte	Incidents, SLO-Berichte, Belege zur Ursache	Eine Incident-Zeitleiste mit Security- und Zuverlässigkeitsbelegen

Wo sich SIEM und Observability überschneiden

Die Schnittmenge ist größer, als viele Organisationen annehmen, und sie wächst, je mehr Infrastruktur softwaredefiniert ist:

• Gemeinsame Quellen: Anwendungs- und API-Logs, Kubernetes-Audit-Logs, Audit-Trails der Cloud-Anbieter, Ingress- und Load-Balancer-Logs, DNS-Logs und Ereignisse der Web Application Firewall.
• Gemeinsame Erfassung: Agenten und Collectors laufen für die Observability ohnehin auf jedem Knoten. Ein zweiter Satz Agenten für das SIEM verdoppelt Overhead und Konfigurationsaufwand.
• Gemeinsame Fragen: Was hat sich wann, durch wen und mit welcher Wirkung geändert? Change- und Deployment-Events sind für die Ursachenanalyse ebenso zentral wie für forensische Zeitleisten.
• Gemeinsame Regulierung: Regelwerke wie NIS2 erwarten sowohl Security Monitoring als auch die Fähigkeit, Störungen der Verfügbarkeit zu erkennen und zu bewältigen. Unser Beitrag zu den NIS2-Monitoring-Anforderungen geht darauf im Detail ein.

Was Security Observability in der Praxis bedeutet

Security Observability heißt, Prinzipien der Observability wie reichhaltigen Kontext, Korrelation über Signale hinweg und schnelle Exploration auf Sicherheitsfragen anzuwenden und Security-Workflows mit derselben gut strukturierten Telemetrie zu versorgen, die auch die Zuverlässigkeitsteams nutzen. In der Praxis stützt sich das auf vier Bausteine.

1. Eine gemeinsame Telemetrie-Pipeline

Statt getrennter Agenten und Forwarder je Werkzeug erfasst eine Telemetrie-Pipeline Logs, Metriken, Traces und Events einmal, normalisiert sie, maskiert personenbezogene Daten und leitet sie an die Ziele weiter, die sie benötigen. OpenTelemetry Collectors oder eine verwaltete Pipeline-Schicht können diese zentrale Stelle bilden. Das Ergebnis sind überall einheitliche Attribute und ein zentraler Ort für Kostenkontrolle und Datenschutz, statt mehrerer Wege der Log-Aggregation, die mit der Zeit auseinanderlaufen.

2. Relevante Ereignisse ans SIEM leiten, nicht alles

Jedes Debug-Log ans SIEM zu schicken, ist teuer und erzeugt Rauschen in den Erkennungsregeln. Besser ist es, Daten in der Pipeline zu klassifizieren: Authentifizierung, Autorisierung, Rechteänderungen, Audit-Trails, Befunde von Security-Werkzeugen und auffällige Anwendungsereignisse gehen mit langer Aufbewahrung ans SIEM. Operative Logs mit hohem Volumen bleiben mit kürzerer Frist im Observability-Speicher. Eine vollständige Kopie ausgewählter Quellen kann zusätzlich in einen günstigen Archivspeicher für spätere Ermittlungen fließen. Die Routing-Regeln sollten versioniert und von beiden Teams geprüft werden.

3. Laufzeitkontext für Security-Alerts

Ein SIEM-Alert mit dem Inhalt „verdächtiges Anfragemuster von 203.0.113.7 an 10.2.4.18“ zwingt die Analystin, erst einmal nachzuschlagen, was hinter der internen Adresse steckt. Derselbe Alert mit Laufzeitkontext lautet: Service checkout-api, Namespace payments, verantwortlich ist das Payments-Team, vor 14 Minuten in Version 2.31.0 ausgerollt, über Ingress aus dem Internet erreichbar, derzeit mit erhöhter Fehlerrate. Dieser Kontext stammt aus der Observability: Ressourcenattribute, Topologie, Deployment-Events und Service-Verantwortung. Damit kann das SOC Exposition und Auswirkung in Sekunden einschätzen und weiß, wen es anrufen muss.

4. Gemeinsame Incident Response

Betrifft ein Incident sowohl Security als auch Zuverlässigkeit, sollten beide Teams mit derselben Zeitleiste arbeiten. Dazu gehören gemeinsame Definitionen für den Incident-Schweregrad, eine klare Regel, wann aus einem Ausfall ein Sicherheitsvorfall wird (und umgekehrt), definierte Rollen wie Incident Commander und Security Lead sowie eine Beweiskette, die SIEM-Fälle mit Observability-Incidents verknüpft. Sicherheitskritische Details können dabei eingeschränkt sichtbar bleiben, während die operative Zeitleiste allen Beteiligten offensteht.

Architektur-Checkliste: SIEM + Observability

Übernehmen Sie diese Checkliste in Ihr Design-Dokument oder Ticketsystem und markieren Sie jeden Punkt als erledigt, geplant oder nicht relevant. Sie funktioniert unabhängig davon, welches SIEM und welche Observability-Plattform Sie einsetzen.

ARCHITEKTUR-CHECKLISTE: SIEM + OBSERVABILITY

Erfassung
[ ] Eine Collector-/Agenten-Schicht pro Knoten oder Cluster (keine doppelten Agenten)
[ ] OpenTelemetry für Anwendungs- und Infrastrukturtelemetrie
[ ] Quelleninventar: Verantwortliche, Volumen pro Tag, Sicherheitsrelevanz

Datenmodell
[ ] Pflichtattribute an jedem Ereignis: service.name, deployment.environment,
    Team/Verantwortliche, Cloud-Region, K8s-Namespace, Version
[ ] Strukturierte Logs (JSON oder OTLP), keine reinen Freitext-Sicherheitsereignisse
[ ] Mapping auf das SIEM-Schema dokumentiert und getestet

Routing und Kosten
[ ] Datenklassen definiert: sicherheitsrelevant / operativ / Archiv
[ ] Routing-Regeln in Git versioniert, von SOC und SRE geprüft
[ ] Debug- und Massenlogs vor dem SIEM gefiltert oder gesampelt
[ ] Volumen und Kosten je Ziel überwacht und mit Alerts versehen

Datenschutz
[ ] Maskierung oder Hashing personenbezogener Daten in der Pipeline
[ ] Zugriffsrechte je Datenklasse (Security-Daten eingeschränkt)
[ ] Datenstandort für jedes Ziel dokumentiert

Aufbewahrung
[ ] Fristen je Datenklasse an rechtliche und Audit-Vorgaben angepasst
[ ] Archivstufe für vollständige Daten mit getesteter Wiederherstellung

Erkennung und Kontext
[ ] SIEM-Alerts angereichert mit Service, Verantwortlichen, Deployment, Exposition
[ ] Deployment- und Change-Events an SIEM und Observability
[ ] Zuverlässigkeits-Anomalien mit Sicherheitsmustern ans SOC weitergeleitet

Incident Response
[ ] Gemeinsame Schweregrad-Skala und Eskalationsregeln
[ ] Definierte Übergabe: Ausfall -> Sicherheitsvorfall und zurück
[ ] Querverweise zwischen SIEM-Fällen und Observability-Incidents
[ ] Gemeinsames Post-Incident-Review bei gemischten Vorfällen

Pragmatische Einführung in vier Schritten

1. Überschneidungen erfassen. Listen Sie jede Quelle auf, die heute beide Teams sammeln, mit Volumen und Ziel. Doppelte und verwaiste Quellen sind Ihre schnellen Erfolge.
2. Attribute vereinbaren. Legen Sie verpflichtende Ressourcenattribute und Verantwortlichkeiten fest. Das ist eine kleine Änderung, die jeden weiteren Schritt erleichtert.
3. Routing in die Pipeline verlagern. Beginnen Sie mit einer Quelle mit hohem Volumen, etwa Ingress-Logs: Sicherheitsrelevante Felder und Ereignisse gehen ans SIEM, der Rest bleibt im Observability-Speicher. Vergleichen Sie Kosten und Erkennungsqualität vorher und nachher.
4. Einen gemeinsamen Incident üben. Spielen Sie in einer Tabletop-Übung durch, wie ein Sicherheitsereignis einen Service beeinträchtigt. Notieren Sie, wo Kontext fehlte und welche Übergabe unklar war, und schließen Sie diese Lücken.

Vermeiden Sie die zwei typischen Fehler: alles „für alle Fälle“ ans SIEM zu schicken, was Kosten und Alert-Rauschen in die Höhe treibt, und einen separaten Security Data Lake aufzubauen, der die Observability-Pipeline ohne gemeinsamen Kontext dupliziert.

Wie Obseria unterstützt

Obseria ist eine OpenTelemetry-native Observability-Plattform, kein SIEM, und darauf ausgelegt, mit Ihren bestehenden Security-Werkzeugen zusammenzuarbeiten. Die Obseria Pipeline filtert, maskiert personenbezogene Daten, sampelt und routet Telemetrie vor der Speicherung. So senden Sie sicherheitsrelevante Ereignisse an Ihr SIEM und behalten operative Daten in Obseria Lake mit Datenhaltung in der EU. Obseria TopoGraph liefert den Kontext zu Services, Verantwortlichen und Deployments, der Security-Alerts handlungsfähig macht, und die Funktionen für Application Security verknüpfen Laufzeitbefunde mit den betroffenen Services.

• Eine Erfassungsschicht und Routing-Regeln für Observability- und SIEM-Ziele
• Topologie- und Change-Kontext für schnellere Triage zwischen SOC und SRE
• Gemeinsames Incident-Management mit Zeitleisten für Sicherheit und Zuverlässigkeit
• Optional Managed Observability und Security mit unserem Implementierungspartner

Wie eine gemeinsame Pipeline mit Ihrer eigenen Telemetrie funktioniert, sehen Sie am schnellsten im kostenlosen Test.