Im Enterprise-Sicherheitsbetrieb sollten WAAP-, ADC-, AAM-, Health-Check-, Admin-Aktions- und GTM-Ereignisse nicht in einer Produktkonsole gesperrt bleiben. SOC-Teams möchten diese Ereignisse in ihrem eigenen SIEM, ihren Log-Analytics- und Compliance-Systemen sehen. Wenn ein Anbieter Logs in proprietären oder schwer konvertierbaren Formaten aufbewahrt, wird die Incident-Untersuchung fragmentiert.
Verschiedene SIEM-Plattformen kommen mit verschiedenen Format-Erwartungen. Einige Teams wollen JSON für Suche und Indexierung, andere verlassen sich auf CEF für fertige Parser, und wieder andere bevorzugen einen einfachen plainText-Syslog-Stream. Produkte, die ein einziges Format aufzwingen, verlängern Integrations-Zeitpläne und verlagern die Log-Normalisierung auf die Organisation.
In Multi-Tenant- oder Namespace-getrennten Umgebungen wird Log-Streaming noch sensibler. Die Logs jedes Tenants müssen ihr eigenes SIEM erreichen, und Ereignisse aus verschiedenen Namespaces dürfen sich nicht vermischen. Ein einzelner globaler Syslog-Ausgang reicht für solche Architekturen weder für Isolierung noch für Auditierbarkeit aus.
Log-Volumen ist eine weitere Herausforderung. In hochfrequentierten Health-Check- oder Sicherheitsereignisszenarien kann das Senden jedes kleineren Ereignisses an das SIEM Kosten und Rauschen erzeugen. Filterung auf Quell-Ebene, Health-Check-Verbose-Kontrolle, mehrere Profile und Sampling wo angemessen müssen alle Teil des Log-Betriebsmodells sein.
TR7 SIEM Log Streaming adressiert all dies mit Namespace-bezogenen Transport-Profilen, UDP/TCP Syslog, RFC3164/RFC5424-Unterstützung, JSON/CEF/plainText-Nachrichtenformaten und Filterung auf Quell-Ebene — Plattformereignisse in die eigene SIEM-Pipeline der Organisation leitend.
TR7 behandelt Log-Weiterleitung nicht als einen einzigen globalen Ausgang, sondern als ein Profilmodell, das pro Namespace, Format, Quelle und Ziel verwaltet wird.
Für jeden Netzwerk-Namespace kann ein dedizierter Log-Transport-Prozess laufen. Dieses Modell verhindert das Vermischen von Log-Streams verschiedener Tenants in Multi-Tenant-Umgebungen und stellt sicher, dass die Logs jedes Tenants sein eigenes SIEM-Ziel erreichen.
Log-Nachrichten können als JSON, CEF oder plainText produziert werden. JSON bedient Such- und Indexierungs-Workflows, CEF ermöglicht fertige SIEM-Parser, und plainText deckt die allgemeine Syslog-Kompatibilität ab.
Jedes Transport-Profil wählt aus, welche Log-Quellen weitergeleitet werden. Admin-Aktionen, Health-Check-Ereignisse, Benachrichtigungen, GTM-Ereignisse und Sicherheitsereignisse können jeweils bei Bedarf über separate Profile verwaltet werden.
Log-Transport-Profile werden aus den Management-Daten synchronisiert. Wenn ein Profil hinzugefügt, geändert oder entfernt wird, wird der relevante Namespace-Prozess ohne Neustart des gesamten Systems aktualisiert.
SIEM Log Streaming leitet TR7-Plattformereignisse über Standard-Syslog-Transporte und SIEM-freundliche Nachrichtenformate an externe Log-Infrastruktur weiter.
UDP-Transport ist ein unkompliziertes Ausgangsmodell, das mit traditionellen Syslog-Topologien kompatibel ist. Der Standard-Syslog-Port 514 kann verwendet werden, oder auf Profil-Ebene kann ein anderer Port ausgewählt werden. Es liefert Log-Weiterleitung mit geringem Overhead für zuverlässige LAN-Umgebungen. Da UDP von Natur aus keine Zustellgarantie bietet, ist TCP für kritische Umgebungen vorzuziehen.
TCP-Transport wird von Teams verwendet, die einen verbindungsorientierten Log-Stream zum SIEM-Ziel wollen. Der Ziel-Host, Port und Timeout können im Profil definiert werden; ein typischer TCP-Timeout beträgt 10.000 ms. TCP bietet kontrolliertere Zustellung als UDP, aber das Verbindungsverhalten sollte überwacht werden, wenn das Zielsystem langsam ist.
RFC3164 wird für die Integration mit Systemen unterstützt, die das traditionelle BSD-Syslog-Format verwenden. Das Profilfeld syslogAppName kann als Nachrichtenpräfix verwendet werden; der Standardwert kann TR7_syslog_client sein. Es bietet breite Kompatibilität für ältere SIEM- oder Syslog-Empfänger. Dieses Format ist eine praktische Wahl in Umgebungen, die keine modernen strukturierten Daten erfordern.
RFC5424 ist der modernere Syslog-Standard und unterstützt strukturierte Datenfelder. Ein TR7-Log-Profil kann diesen Standard auswählen, um geordnetere und maschinenverarbeitbare Syslog-Nachrichten zu produzieren. Feld-Parsing und Ereignisklassifizierung werden auf der SIEM-Seite konsistenter. In Kombination mit JSON- oder CEF-Payload bildet es ein starkes Integrationsmodell.
Im JSON-Format sind Felder wie Zeitstempel, Quelle, Schweregrad, Nachricht und Meta leicht maschinenverarbeitbar. Feldbasierte Suche wird für Log-Analytics-, Indexierungs- und Abfrage-Systeme vereinfacht. SOC-Teams können Ereignisse als geparste Felder statt als rohe Textzeilen untersuchen. Dieses Format wird bei Integrationen mit modernen Log-Plattformen bevorzugt.
CEF-Nachrichten werden mit der Struktur CEF:0|TR7|LogTransport|1.0|...|. produziert. Schweregradwerte werden auf einer 0-10-Skala abgebildet; Stufen wie info 3, warning 5, error 7 und critical 10 werden verwendet. Key-Value-Felder können von fertigen Parsern auf der SIEM-Seite verarbeitet werden. Dieses Format eignet sich für SOC-Teams, die einen standardisierten CEF-Stream für Ereignisklassifizierung und -korrelation wollen.
PlainText-Format produziert ISO-Zeitstempel, Schweregrad, Quelle und Nachrichtenfelder als menschenlesbaren Text. Es kann schnell in Umgebungen ohne komplexe Parser oder für temporäre Integrationen eingesetzt werden. Es bietet hohe menschliche Lesbarkeit und ist für einfache Log-Ziele geeignet, bei denen JSON oder CEF unnötig wären.
userLogs deckt Admin-Aktionen ab, hcLogs deckt Health-Check-Ereignisse ab, notificationLogs deckt Systembenachrichtigungen ab, und gtmLogs deckt GTM-Ereignisse ab. Jedes Profil kann so definiert werden, dass es nur die benötigten Quellen sendet, sodass nur relevante Log-Klassen das SIEM erreichen. WAAP-Sicherheitsereignisse können ebenfalls über dieselbe Transport-Pipeline an die Log-Infrastruktur der Organisation weitergeleitet werden.
Health-Check-Logs können auf stark ausgelasteten Systemen ein hohes Volumen erzeugen. Wenn hcLogsVerbose auf false gesetzt ist, werden nur Health-Check-Ereignisse mit einer stateChange-Bedingung gesendet. Dieser Ansatz reduziert SIEM-Rauschen und zeigt nur bedeutungsvolle Service-Zustandsübergänge auf. Verbose-Verhalten kann während der Fehlerbehebung vorübergehend aktiviert werden.
Innerhalb desselben Namespace können mehr als ein Transport-Profil aktiv sein. Ein Profil kann im CEF-Format an das SOC-SIEM senden, während ein anderes im JSON-Format an ein Log-Analytics-System weiterleitet. Diese Struktur verteilt denselben Log-Stream an die Bedürfnisse verschiedener Teams. Das Multi-Ziel-Szenario reduziert die Notwendigkeit, einen separaten externen Log-Router einzusetzen.
SIEM Log Streaming wird zusammen mit Formatierung, Profil-Synchronisierung, Validierung, Fehler-Isolierung und Nachrichten-Bereinigungsverhalten betrieben.
CEF-Anbieter- und Produktfelder werden als TR7 / LogTransport / 1.0 produziert. Schweregrad wird auf einer 0-10-Skala abgebildet. Nachrichtenfelder sind als Key-Value-Paare strukturiert, die von SIEM-Parsern gelesen werden können.
Das Profilfeld syslogAppName wird als Anwendungsname in Syslog-Nachrichten verwendet. Der Standardwert kann TR7_syslog_client sein. Dieses Feld ist wichtig für Quellenidentifizierung und -filterung auf der SIEM-Seite.
Profiländerungen werden pro Namespace gruppiert und auf die relevanten Transport-Prozesse angewendet. Wenn ein altes Profil entfernt wird, wird sein zugehöriger Prozess beendet. Neue oder geänderte Profile können ohne Neustart in den aktiven Log-Stream gebracht werden.
Wenn der transportType-Wert nicht syslog ist, wird das Profil nicht in der aktuellen Syslog-Transport-Pipeline zugelassen. Diese Struktur lässt Raum für die zukünftige Erweiterung auf verschiedene Transport-Typen. Aktuelle Unterstützung umfasst UDP und TCP Syslog.
Syslog-Client-Verbindungs- und Fehlerereignisse werden über den internen Logger aufgezeichnet. Ziel-SIEM-Verbindungsfehler bringen den Haupt-Management-Prozess nicht zum Absturz. Operatoren können Verbindungsprobleme über Logs und Profilstatus überwachen.
Wenn UI-generierte Nachrichten HTML-Inhalt enthalten, wird der Textinhalt extrahiert, bevor er an Syslog gesendet wird. Dies ist besonders wichtig für Feldsicherheit und Parser-Konsistenz im CEF-Format. Log-Nachrichten werden in einer saubereren und sichereren Form an das SIEM geliefert.
Sicherheitsteams können WAAP-Ereignisse im CEF-Format an das SIEM senden. Regel-, Schweregrad-, Quell- und Meta-Felder werden von SIEM-Parsern verarbeitet. Das SOC-Team sieht Ereignisse auf seinem eigenen Korrelationsbildschirm, ohne die TR7-Oberfläche aufzurufen.
Operations-Teams können das JSON-Format auswählen, um Logs in feldindexierter Form an eine externe Log-Plattform weiterzuleiten. Zeitstempel-, Quell-, Schweregrad- und Meta-Felder werden abfragbar. Fehleranalyse und Trend-Extraktion werden vereinfacht.
Ein Managed-Service-Provider kann für jeden Tenant einen separaten Namespace und ein separates Log-Transport-Profil definieren. Die Logs jedes Tenants gehen an sein eigenes SIEM-Ziel. Tenant-Daten werden daran gehindert, sich im selben Log-Stream zu vermischen.
Compliance-Teams können userLogs, notificationLogs und Health-Check-State-Change-Ereignisse in ein zentrales SIEM spiegeln. Selbst wenn lokale Logs gelöscht oder rotiert werden, bleiben kritische Ereignisse im externen System. Admin-Aktionen und Systemereignisse können während Audits retrospektiv überprüft werden.
Namespace-bezogene Profile, JSON/CEF/plainText-Formate und Filterung auf Quell-Ebene — lassen Sie uns durch ein Live-Setup in Ihrer eigenen Umgebung führen.