„A data source is a system or service that generates telemetry.“ Mit diesem Satz beginnt der Autor, und er verschiebt den Blick weg von den Werkzeugen hin zu den Spuren. Bevor eine Regel greifen kann, muss eine Umgebung erst erzählen, was in ihr passiert. Wer im Detection Engineering arbeitet, kennt diese Abhängigkeit aus der unangenehmen Richtung: Eine Detection ohne Telemetrie ist kein Detektor, sondern eine leere Hülle. Der Text zeichnet nach, wie aus einer rohen Beobachtung eine auswertbare Regel wird – und wo das regelmäßig schiefgeht.
Telemetrie, Events und Logs: die Ladenglocke als roter Faden
Zum Einstieg greift der Autor ein Bild aus dem Alltag auf: Wer einen Laden betritt, löst eine Glocke aus, und der Ladenbesitzer weiß, dass ein Kunde hereingekommen ist. Die Glocke urteilt nicht darüber, ob der Besucher kaufen oder stehlen will – sie erzeugt eine Beobachtung. So funktioniert Telemetrie: Ein System oder Dienst beschreibt, was mit ihm passiert, ohne zu bewerten, ob das gut oder schlecht ist. Diese Beobachtungen werden meist als Events festgehalten, als strukturierte Nachrichten über ein Ereignis.
In der Sicherheitswelt reichen diese Ereignisse von der Anmeldung an Microsoft 365 über das Herunterladen und Ausführen einer Datei bis zum Zugriff auf eine interne Firmenwebseite. Sobald ein Event einen Zeitstempel bekommt und gespeichert wird, spricht man von einem Log. Dieselben Datensätze erfüllen ganz unterschiedliche Aufgaben: Entwicklungs- und Betriebsteams nutzen sie zum Debuggen, für Audits und zur Überwachung der Systemgesundheit, Sicherheitsteams dieselben Aufzeichnungen als Beweismittel, um Angriffe zu finden und aufzuklären. Ein Log ist damit zunächst nichts Sicherheitsspezifisches – es wird erst durch die Fragestellung dazu.
Nicht jedes Log ist nützlich. Der Autor weist darauf hin, dass Ereignisse, von denen man sich viel verspricht, oft gar nicht protokolliert werden. Ein großer Teil der Arbeit im Detection Engineering besteht deshalb darin, Herkunft, Form und Bedeutung einer Quelle so weit zu verstehen, dass sich beurteilen lässt, ob sie eine Jagd, eine Untersuchung oder eine Regel tragen kann. Ohne Telemetrie gibt es keine Regel, sagt er – dieser Satz steht im Zentrum seiner Argumentation.
Der Aufbau eines Sicherheitslogs: fünf Bestandteile, die fast immer vorkommen
Das Beispiel des Autors ist ein Anmeldeereignis: eine Aktion (SignIn), ein Akteur (alex@example.com), Kontext (Anwendung, Quell-IP), ein Zeitstempel (time) und ein Ergebnis (result=Success). Daraus lässt sich rekonstruieren, dass sich ein Nutzer namens Alex am 1. Januar erfolgreich an Microsoft 365 angemeldet hat, von der IP-Adresse 203.0.113.10. Entscheidend ist weniger der Inhalt als die Struktur: Ohne Aktionsname, Akteur, Kontext, Zeit und Ergebnis bleibt ein Vorfall eine Behauptung ohne Beleg.
Regelsprachen arbeiten fast immer gleich. Sie wählen Schlüssel im Log aus – etwa user oder action – und vergleichen deren Werte mit einem Muster, das auf schädliches Verhalten hindeuten könnte. Daraus folgt eine harte Anforderung: Jedes Log sollte den Zeitpunkt des Ereignisses enthalten, denn die meisten SIEM-Systeme verweigern ohne Zeitstempel die Verarbeitung. Ein Log ohne Zeit ist für die Korrelation zweier Vorfälle wertlos.
Der Zeitstempel ist mehr als eine Spalte. Wenn zwei Quellen dieselbe Minute unterschiedlich darstellen – die eine in UTC, die andere in Ortszeit, die eine mit Millisekunden, die andere ohne –, entsteht beim Zusammenführen ein Versatz, und Ereignisse erscheinen in der falschen Reihenfolge. Solche Details entscheiden darüber, ob sich eine Identitätsanmeldung sauber mit einer Endpunktaktivität verknüpfen lässt. Der Zeitstempel ist keine Formalie, sondern das, was die Ereignisse zusammenhält.
Fünf Logformate und woran man sie erkennt
Anbieter geben ihren Logs eine Form, das Logformat. Der Autor beschreibt die wichtigsten Vertreter, und die Unterschiede sind handfester, als sie wirken. CSV trennt Felder durch Kommas, die erste Zeile enthält die Feldnamen, jede weitere ein Ereignis. Das ist kompakt und vertraut, besonders für alle, die viel mit Tabellen arbeiten. Weil die Spalten rein positionell sind, werden Felder mit Kommas oder verschachtelten Daten aber schnell lästig.
Syslog ist Protokoll und Nachrichtenformat zugleich. Modernes Syslog kann strukturierte Daten in einem eigenen Logformat transportieren, doch in der Praxis dominieren freiformulierte Meldungen, aus denen die relevanten Werte erst mühsam herausgezogen werden müssen. Das Windows Event Log fällt aus dem Rahmen, weil Windows Ereignisse binär im .evtx-Format speichert. Werkzeuge rendern diese Dateien als XML: Der Ereigniskopf trägt allgemeine Metadaten wie Provider, Event ID, Channel, Computer und Zeit, die ereignisspezifischen Details erscheinen separat.
JSON ist ein strukturiertes, textbasiertes Format aus Name-Wert-Paaren und der Regelfall in Cloud-, SaaS-, API- und modernen Anwendungslogs – im SIEM das häufigste Format überhaupt. Der Autor nennt es das flexibelste, weil sich JSON-Objekte ineinander verschachteln lassen, was Extraktion und freie Felder erleichtert. Daneben gibt es CEF, ein kompaktes Schlüssel-Wert-Format, das vor allem Netzwerk- und Sicherheitsappliances liefern. Wer diese Formate auseinanderhalten kann, weiß, welche Arbeit beim Einlesen auf ihn zukommt.
Warum dasselbe Feld in jeder Quelle anders heißt
Der Schmerz beginnt beim Feldnamen. Will man in den genannten Formaten den Benutzeraccount extrahieren, bekommt man vier verschiedene Antworten. In CSV heißt das Feld user und steht in der zweiten Spalte. In Syslog heißt es ebenfalls user, aber es braucht eine eigene Extraktionsmethode, um die E-Mail-Adresse korrekt aus dem Feld [event] zu lösen. Im Windows Event Log verbirgt sich die Information unter TargetUserName, innerhalb von EventData, innerhalb von Event. In JSON lautet der Pfad user.email.
Ein Konzept, vier Adressen – und das ist kein Ausnahmefall, sondern der Normalfall. Der Autor nennt das ein klassisches Datenproblem, gelöst über ETL-Pipelines: Extrahieren, Transformieren, Laden. Ereignisse werden aus einer Quelle geholt, in eine Form gebracht, die die Sicherheitsplattform konsistent parsen und durchsuchen kann, und als normalisierte Events ins SIEM geladen. In der Praxis heißt das: eine rohe Syslog-Nachricht zerlegen, das Benutzerfeld auf ein Standardfeld abbilden, Zeitstempel in eine gemeinsame Zeitzone überführen oder auch nur userName in username umbenennen.
Was banal klingt, entscheidet darüber, ob eine Detection funktioniert. Wer diese Arbeit überspringt, muss jedes Mal nachbessern, wenn eine neue Quelle dazukommt. Der Autor verweist auf den bekannten Comic über Standards, von denen es immer einen zu viele gibt – so verhält es sich auch mit den Formatstandards der Hersteller.
Was fehlende Normalisierung im SIEM anrichtet
Ohne diese Vorarbeit entstehen drei Probleme, und alle drei treffen den Alltag eines Security Operations Centers direkt. Erstens droht Regel-Wildwuchs: Weil jede Quelle Benutzer, IP-Adressen und Zeitstempel anders darstellt, muss dieselbe Detection mehrfach geschrieben werden. Das kostet Wartung und Tuning und bindet Kapazität, die anderswo fehlt.
Zweitens werden zusammengesetzte Detections schwierig. Wer eine Identitätsanmeldung mit einer Endpunktaktivität verknüpfen will, braucht identische Zeitstempel, Feldnamen und Metadaten – sonst entstehen Integrationsprobleme mitten in der Regel, die sich nur mit zusätzlichen Parsern reparieren lassen. Drittens entstehen Wissenslücken: Analysten müssen die Eigenheiten unzähliger Formate im Kopf behalten, obwohl ihre Zeit besser in Alarmierung und Eindämmung investiert wäre. Wer im SIEM ständig zwischen Formaten umdenken muss, übersieht eher etwas.
Daraus formuliert der Autor eine Haltung, die über das Werkzeug hinausgeht: Sicherheitsingenieure sollten sich dafür interessieren, wie nachgelagerte Menschen und Dienste die Daten interpretieren, die sie erzeugen und weiterreichen. Das ist unbequem, weil es Verantwortung über die eigene Systemgrenze hinaus bedeutet. Aber nur so lassen sich blinde Flecken und doppelte Arbeit strukturell verhindern, statt sie immer wieder einzeln zu flicken.
Was das konkret bedeutet
Parsing und Normalisierung sind ein Problem, das so alt ist wie das Internet, und der Autor rechnet nicht damit, dass es verschwindet – auch nicht im Zeitalter agentischer Sicherheitssysteme. Wer Sicherheitslogs verstehen will, muss bei den Grundlagen ansetzen: Welche Quelle erzeugt welche Telemetrie, in welchem Format, mit welchen Feldnamen – und was davon landet tatsächlich im SIEM. Diese Fragen klingen unspektakulär, entscheiden aber darüber, ob eine Regel greift oder ins Leere läuft.
In der Praxis heißt das: Behandle Logformate nicht als lästiges Detail, sondern als Teil der Detection-Logik. Prüfe bei jeder neuen Quelle zuerst, ob der Zeitstempel brauchbar ist und ob der Akteur eindeutig identifizierbar bleibt. Investiere früh in eine saubere Transformationsschicht, statt später mehrere Versionen derselben Regel zu pflegen. Und akzeptiere, dass ein Teil der Arbeit unsichtbar bleibt – die Glocke über der Tür klingelt nur dann verlässlich, wenn jemand vorher die Verkabelung geprüft hat.
Der Text ist der erste Teil einer Reihe zu Logs und Logformaten. Der zweite Teil widmet sich der Transform-Schicht und den typischen Fallstricken der Normalisierung samt der Kompromisse, die damit einhergehen. Wer bis dahin die Formate und ihre Herkunft verstanden hat, begegnet diesen Kompromissen gelassener.
Quelle: detectionengineering.net
