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:

• einheitliche Sprache zur Beschreibung des Ereignisses
• einheitlicher Mechanismus zur Protokollierung von Informationen
• einheitlicher Mechanismus zur Übertragung von Informationen

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.

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:

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 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 Security Frameworks, Routing, Firewalling und Log Management.

Links

• http://www.opengroup.org/
• http://www.openlogformat.org/
• https://attack.mitre.org/
• https://capec.mitre.org/
• https://car.mitre.org/
• https://cee.mitre.org/
• https://cve.mitre.org/
• https://cve.mitre.org/data/board/archives/2001-03/msg00013.html
• https://cwe.mitre.org/
• https://kc.mcafee.com/resources/sites/MCAFEE/content/live/CORP_KNOWLEDGEBASE/78000/KB78712/en_US/CEF_White_Paper_20100722.pdf
• https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf
• https://tools.ietf.org/html/draft-staniford-cidf-data-formats-00
• https://www.cisco.com/c/en/us/td/docs/security/ips/specs/CIDEE_Specification.html
• https://www.dmtf.org/standards/cadf
• https://www.dmtf.org/standards/cim
• https://www.ibm.com/developerworks/community/wikis/form/anonymous/api/wiki/9989d3d7-02c1-444e-92be-576b33d2f2be/page/3dc63f46-4a33-4e0b-98bf-4e55b74e556b/attachment/a19b9122-5940-4c89-ba3e-4b4fc25e2328/media/QRadar_LEEF_Format_Guide.pdf
• https://www.ibm.com/support/knowledgecenter/en/SSB23S_1.1.0.14/gtpb1/rcbefmt.html
• https://www.ietf.org/rfc/rfc4765.txt
• https://www.webtrends.com/