Wenn Sicherheits- und Traffic-Ereignisse nicht in einem Standardformat an ein SIEM fließen, sieht der SOC das vollständige Bild zu spät.
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.
Unser Ansatz
TR7 behandelt Log-Weiterleitung nicht als einen einzigen globalen Ausgang, sondern als ein Profilmodell, das pro Namespace, Format, Quelle und Ziel verwaltet wird.
Ein separater Transport-Prozess pro Namespace bietet Log-Isolierung
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.
Ein Format-Pool passt sich an verschiedene SIEM-Erwartungen an
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.
Filterung auf Profil-Ebene reduziert unnötiges Log-Rauschen
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.
DB-gesteuerter Sync wendet Profiländerungen ohne Neustart an
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.
Fähigkeiten
SIEM Log Streaming leitet TR7-Plattformereignisse über Standard-Syslog-Transporte und SIEM-freundliche Nachrichtenformate an externe Log-Infrastruktur weiter.
UDP-Transport bietet einen schnellen und einfachen Syslog-Stream
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 bietet einen verbundenen und kontrollierten Log-Stream
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-Unterstützung gewährleistet Kompatibilität mit Legacy-Syslog-Empfängern
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-Unterstützung arbeitet mit modernen Syslog-Architekturen
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.
JSON-Nachrichtenformat eignet sich gut für Such- und Indexierungs-Systeme
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-Format ermöglicht schnelle Integration mit fertigen SIEM-Parsern
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 wird in Umgebungen verwendet, die grundlegende Syslog-Kompatibilität erfordern
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.
Vier Haupt-Log-Quellen können pro Profil ausgewählt werden
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-Verbose-Kontrolle verwaltet das Log-Volumen
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.
Mehrere Profile können dasselbe Log in verschiedenen Formaten an verschiedene Ziele senden
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.
Operative Tiefe
SIEM Log Streaming wird zusammen mit Formatierung, Profil-Synchronisierung, Validierung, Fehler-Isolierung und Nachrichten-Bereinigungsverhalten betrieben.
CEF-Formatierungsmodell
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.
App-Name-Konfiguration
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-Synchronisierung
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.
Profil-Validierung
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.
Fehler-Isolierung
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.
HTML-Bereinigung
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.
Wann es verwendet wird
WAAP-Ereignisse im CEF-Format an das SOC-System weiterleiten
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.
Eine Such- und Analytics-Plattform mit einem JSON-Log-Stream speisen
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.
Namespace-Level-SIEM-Trennung in Multi-Tenant-Umgebungen
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.
Admin- und Systemereignisse für Compliance exportieren
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.
Häufig gestellte Fragen
Welche Log-Quellen können in ein Transport-Profil aufgenommen werden?
Was ist der Unterschied zwischen CEF- und JSON-Nachrichtenformaten?
Können mehrere Profile gleichzeitig im selben Namespace laufen?
Wie werden Health-Check-Log-Volumina unter Kontrolle gehalten?
Wann wird TCP-Transport gegenüber UDP bevorzugt?
Wie werden Profiländerungen ohne Ausfallzeit angewendet?
Ihr SIEM jedes Plattformereignis lesen lassen
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.