Security Log Standard - Noch immer eine ungeklärte Frage

Security Log Standard

Noch immer eine ungeklärte Frage

Rocco Gagliardi
von Rocco Gagliardi
am 15. März 2018
Lesezeit: 11 Minuten

Keypoints

  • Ein Standard für Logs lässt noch immer auf sich warten
  • IoT verlangt den Austausch eines einheitlichen Formats für Security-Events
  • Logging wird sich voraussichtlich mehr Richtung strukturierter und schwierig lesbarer Maschinenformate entwickeln

Selbst beim Schreiben eines simplen Skripts muss man sich mit der Frage auseinandersetzen: “Was und wie soll protokolliert werden, was geschieht?” Das Problem der Darstellung, Übertragung und Interpretation ist auf die Schwierigkeit zurückzuführen, notwendige Daten zu identifizieren und übermitteln, so dass das Gegenüber sowohl Kontext als auch Inhalt verstehen kann. Im spezifischen Beispiel einer Security Information ist es wichtig zu wissen, ob ein Ereignis durch verschiedene Sensoren wie Netzwerk, Host oder andere vermeldet werden kann. Diese Schwierigkeit ist eminent, betrachtet man die hohe Anzahl und Unterschiedlichkeiten der verschiedenen Komponenten, die untereinander Daten austauschen können.

Eine kurze Geschichte der Log Formate

Falls mehrere verschiedene Systeme das gleiche Ereignis beobachten, ist davon auszugehen, dass sie dieses in gleicher Weise beschreiben. Wenn dann die relevanten Details des Events zusammengeführt werden (Datum, Quelle, Ziel), dann sollte ein Computer unkompliziert in der Lage sein, den Zusammenhang zwischen zwei Logs, Daten-Logs, Audit-Logs, Alerts, Alarmierungen und Audit Trails zu erkennen.

Damit dieses Ziel erreicht werden kann, wird folgendes vorausgesetzt:

In NIST 800-92, Guide to Computer Security Log Management wird festgehalten:

[T]here is no consensus in the security community as to the standard terms to be used to describe the composition of log entries and files.

Es wurden viele Versuche unternehmen, dieses Problem durch eine Standardisierung anzugehen. Die folgende Liste ist nicht vollständig. Es wurden sämtliche Formate, die ich in meiner Laufbahn benutzt habe, aufgelistet. Es gibt aber über 1’000 weitere Syslog-Nachrichtenformate.

Format Typ Vorgeschlagen durch Jahr Status Kommentar Genutzt durch
XDAS Offen OpenGroup 1997 Beendet XDAS bietet viele nützliche Möglichkeiten, wie ein einheitliches Audit Record Format und die Standardisierung einer Audit Event Taxonomy, mit der Audit Records klassifiziert werden können. Unbekannt
CIDF Offen DARPA 1999 Beendet Das Common Intrusion Detection Framework definierte die Common Intrusion Specification Language (CISL), welche für die Logs der US Navy herangezogen wurden. Es wurde mit IDMEF zusammengeführt. US Navy
IDMEF Offen IETF 2002 Beendet Intrusion Detection Message Exchange Format (RFC4765) wurde durch das IETF als Nachfolger von CIDF vorangetrieben. IDMEF wurde entwickelt, um die Einbruchsereignisse von IDS-Geräten austauschen zu können. Snort
CIEL Offen MITRE 2002 Beendet Das “CVE für Intrusion Detection” hatte zum Ziel, ein einheitliches Schema für alle netzwerk- und hostbasierten Events bereitzustellen. Keine
SDEE/CIDEE Proprietär ICSA Labs 2003 Beendet Security Device Event Exchange nutzt einen XML-Syntax und SOAP-Transport. Es wird lediglich von Cisco unterstützt. Cisco
CBE Proprietär IBM, Cisco 2003 Beendet Das Common Base Event Model ist aus der IBM-Initiative “Autonomic Computing” hervorgegangen. CVE beschreibt eine “einheitliche Sprache zur Erkennung, Protokollierung und Lösung von Systemproblemen”. Tivoli
CIM Offen DMTF 2005 Aktiv Das DMTF Common Information Model (CIM) gewährt eine einheitliche Definition von Management Systemen für Systeme, Netzwerke, Applikationen und Dienste. Hersteller können ihre eigenen Erweiterungen einbringen. Microsoft WMI
CEF Proprietär ArcSight 2006 Aktiv Eine CEF-Nachricht wird durch getrennten Klartext und optionalen Key-Value-Paaren gebaut. Es ist relativ simpel eine solche zu erstellen und parsen. Zudem erfolgt der Transport komplett unabhängig. Viele
CEE Offen MITRE 2007 Beendet Adressiert verschiedene Bereiche des Log Managements: Syntax (CLS), Transport (CLT), Vokabular (CEET) und Empfehlungen (CELR). Keine
OLF Proprietär eIQNetworks 2007 Beendet OLF wurde für das Protokollieren von Netzwerk-Events, die durch Firewalls generiert werden, entwickelt. Es kann aber gleichermassen für Events ausserhalb des Netzwerks zur Anwendung kommen. Unbekannt
WELF Proprietär WebTrends 2008 Aktiv Ein WELF Log besteht aus mehreren Einträgen, in chronologischer Reihenfolge der 4 erforderlichen und 20 optionalen Felder, für Firewall- und Netzwerksysteme. Viele
LEEF Proprietär Q1 Labs 2013 Aktiv Das Log Event Extended Format (LEEF) wurde spezifisch für IBM Security QRadar ausgearbeitet. Wie CEF kann es sehr simpel lesen und parsen. Qradar
CADF Offen DMTF 2015 Aktiv Die Cloud Auditing Data Federation (CADF) standardisiert ein vollumfängliches Event-Model, das nach Belieben genutzt werden kann, um Zertifizierungen, Self-Management und Self-Auditing Application Security in Cloud-Lösungen zu etablieren. OPENShift

Versprechungen von MITRE und andere Niederlagen

MITRA hat in den frühen 2000 eine Reihe von Projekten ins Leben gerufen, mit denen die Probleme des Informationsaustauschs bekämpft werden sollten. Dabei haben sie sich ebenfalls mit verschiedenen Bereichen des Log Managements auseinandergesetzt. CIEL (Common Intrusion Event List) ist mittlerweile inaktiv und stattdessen wird auf das CEE Framework (Common Event Expression) gesetzt. Es deckt die Bereiche Transport (Common Log Transport), Syntax (Common Log Syntax), Taxonomy (Common Event Expression Taxonomy) und eine Reihe von Empfehlungen (Common Event Log Recommendations) ab. Es soll als Teil des nationalen Cyber Information Sharing Ökosystem mit CVE, CWE, CAPEC, ATT&CK und CAR zusammenspielen. In 2014 wurde jedoch entschieden, dass CEE keine Priorität mehr geniessen sollte.

Das Erzeugnis daraus ist ein Dictionary, das die Worte definiert, mit denen das Cybersecurity Puzzle zusammengesetzt werden kann. Doch es fehlt die Haftbarkeit der einzelnen Teile: Wir benutzen noch immer Syslog, um die Daten zwecks Analyse an unsere Cybersecurity-Systeme – wie zum Beispiel IDS, IPS und EPS – zu übermitteln. Dabei muss nach wie vor ad hoc auf grok gesetzt werden, um das Nachrichtenfeld verstehen zu können.

Wieso ist es also so schwer ein einheitliches Log-Format zu definieren? Wieso haben so viele Initiativen versagt?

Es ist nicht schwierig einen Standard zu definieren! Klar, einige Vorschläge haben über das Ziel hinausgeschossen (IDMF), andere sind zu komplex zu implementieren. Doch schlussendlich adressieren alle ein Problem, das von Entwicklern nicht wahrgenommen wird. Erinnern wir uns an "xennet: skb rides the rocket: 19 slots" message flooding /var/log/syslog for “some reason”! Die Standardisierung von Nachrichten ist für Entwickler, die solche Mitteilungen schreiben wollen, schlichtweg nicht gangbar.

Die Zukunft

Und dennoch: Selbst im Jahr 2018 gibt es noch immer kein standardisiertes Format für Security Log Messages! Wir haben zwar Syslog als “universalen Transportmechanismus” akzeptiert. Mehr aber nicht.

Das Message-Feld gilt es zu erobern!

CEF, LEEF und CIM/CADF sind die meistverbreiteten und -unterstützten Formate:

Format Transport Encoding Struktur Anzahl Felder Erweiterbarkeit Bemerkungen
CEF syslog k→v Lose, kein Dictionary 91 Einige zusätzliche Felder Einfach zu lesen und parsen, viele Informationen
LEEF syslog k→v Lose, kein Dictionary 51 Nicht spezifiziert Einfach zu lesen und parsen, Fokus auf Netzwerk
CIM Agnostisch Agnostisch XML-Schema 59 Neue Instanzen Einfach zu parsen. Strukturen zur Beschreibung von Security Events müssen erweitert werden.

Gegenwärtig gewinnen lose Format, die über Syslog verteilt werden, menschenlesbar sind und sich programmtechnisch einfach parsen lassen. Doch IoT wird ein Mehr an Events generieren, die jedoch nicht für Menschen gedacht sind! So werden wir mehr strukturierte, kryptische, komprimierte und nicht menschenlesbare Formate sehen, die mehr aus IDs und weniger aus Worten bestehen.

Meine Angst ist, dass ohne eine einheitliche Steuerung dieser Entwicklung eine Vielzahl an Git-wanna-be-Master-Clones gegeben sein und zum Wildwuchs beitragen wird.

Fazit

Gerade mit der anstehenden Revolution durch IoT wird es unabdingbar, dass man sich auf einen Standard im Bereich Logging einigen kann, so dass unkompliziert und effizient die Korrelation und Identifikation von verdächtigen Aktivitäten erkannt werden kann.

Viele Organisationen sind bisher ohne Erfolg darum bemüht, hierzu eine Definition zu etablieren. In den letzten Jahren wurde CEE und LEEF mit Syslog zu einem De-Facto Standard. Doch sie wirken noch immer archaisch, gross, schwerfällig, benutzerorientiert – Das ist konträr zu dem, was die heutige Zeit mit Kompaktheit, Agilität, und maschinenlesbaren Formaten verlangt.

Über den Autor

Rocco Gagliardi

Rocco Gagliardi ist seit den 1980er Jahren im Bereich der Informationstechnologie tätig. In den 1990er Jahren hat er sich ganz der Informationssicherheit verschrieben. Die Schwerpunkte seiner Arbeit liegen im Bereich Routing, Firewalling und Log Management.

Links

Sie wollen die Sicherheit Ihrer Firewall prüfen?

Unsere Spezialisten kontaktieren Sie gern!

×
Schutz vor Phishing

Schutz vor Phishing

Rocco Gagliardi

Logging

Logging

Rocco Gagliardi

IT Security Policies

IT Security Policies

Rocco Gagliardi

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv