Windows Event Logs an Sophos XDR und SIEM senden

Microsoft Windows Event Log lässt sich über einen unterstützten Forwarder im Format Snare-over-syslog an einen Sophos XDR Data Collector senden. Das ist ein eigener Datenweg neben dem Sophos-Endpoint-Agenten: Weder eine Windows-Event-ID im lokalen Protokoll noch ein grüner Endpoint-Status beweist, dass dieses Ereignis über die Event-Log-Integration aufgenommen wurde.

Der Ablauf lautet: Collector bereitstellen, gewünschte Windows-Ereignisse und Auditvorgaben festlegen, Forwarder mit dem richtigen Format auf UDP/514 richten und ein definiertes Testereignis in Sophos nachweisen.

Umfang und Lizenz vor dem Deployment klären

Je nach tatsächlich weitergeleiteten Ereignissen kann die Integration Authentisierung, Konto-/Gruppenänderungen, Prozesse, Defender-Malwarebefunde, administrative Änderungen, Directory-Audits und weitere Sicherheitsereignisse aufnehmen. Dokumentierte Schemas sind auth, process, antivirus, managementevent, cloudaudit, thirdpartyalert, encrypt und netflow.

Die SIEM-Lizenzgrenze betrifft netflow-Telemetrie, beispielsweise Windows-Filtering-Platform-Verbindungsereignisse wie Event 5156. Daraus folgt keine pauschale Next-Gen-SIEM-Pflicht für alle anderen genannten Windows-Ereignisse. Trotzdem müssen die für den eigenen XDR-/MDR-Tenant benötigten Integrations- und Quellentitlements vorliegen. Die SIEM-Einordnung und die Integrationsgrundlagen erklären diese Prüfung.

Collector, Forwarder und Datenschutz vorbereiten

Benötigt werden ein betriebsbereiter XDR Data Collector, ein genehmigter Netzwerkweg von den Windows-Quellen und eine Forwarding-Lösung, die Snare-over-syslog ausgeben kann. Sophos nennt beispielsweise Snare Enterprise, NXLog Enterprise, TIBCO Universal Collector, Syslog-ng Agent for Windows sowie NXLog Community Edition. Das ist keine Aussage, dass alle Produkte dieselben Felder, Lizenzen oder Konfigurationsdateien verwenden.

Das Collector-Runbook behandelt Ressourcen, DNS, Zeitversorgung und Uplink. Eingehend wird hier UDP/514 ausschliesslich aus den vorgesehenen Windows-Quellnetzen freigegeben. UDP liefert keine Zustellbestätigung pro Meldung; ein erfolgreicher Netzwerk- oder Porttest ersetzt daher nicht den Ereignisnachweis.

Vor der Konfiguration erfasst man Quellcomputer beziehungsweise Domain Controller, gewünschte Event-IDs, bestehende Auditvorgaben, verantwortliches Team und bisherigen Logpfad. Ereignisse können Benutzernamen, Ressourcenpfade oder Prozessargumente enthalten. Deshalb nur den genehmigten Umfang erfassen und Rohlogs oder Zugangsdaten nicht in frei zugängliche Tickets kopieren.

Windows-Forwarding konfigurieren

1. Im richtigen Sophos-Tenant unter Security Operations > Integrations > Data Collectors den bereitgestellten Collector identifizieren. Seine für die Windows-Quellen erreichbare IP verwenden, nicht eine regionale Sophos-Upload-Adresse oder eine fremde Appliance-IP.
2. Auf einem freigegebenen Pilotcomputer den vorgesehenen Forwarder nach dessen Produktanleitung bereitstellen. Vorhandene Forwarder-Konfiguration sichern und deren andere Ausgaben erfassen, bevor eine gemeinsame Datei geändert wird.
3. Den Forwarder ausdrücklich auf Snare-over-syslog einstellen. Sophos verlangt dieses Format; beliebiges JSON, CEF oder Windows-Event-XML ist für diesen Einrichtungsweg kein bestätigter Ersatz.
4. Als Empfänger die tatsächliche Collector-IP mit UDP-Port 514 konfigurieren. Die gewählten Event-Kanäle beziehungsweise Filter müssen die benötigten Ereignisse tatsächlich einschliessen.
5. Quellzeitstempel in UTC ausgeben lassen und die Windows-Zeitversorgung prüfen. Die lokale Anzeige im Event Viewer allein belegt nicht, welche Zeitzone der Forwarder im gesendeten Datensatz verwendet.
6. Die Konfiguration aktivieren und den Forwarder auf lokale Fehler prüfen. Danach die Datenaufnahme mit dem unten beschriebenen Ereignisvergleich abnehmen, bevor weitere Computer aufgenommen werden.

Für NXLog CE die von Sophos bereitgestellte Konfigurationsvorlage nxlog_wel.txt herunterladen. Diese Vorlage dient als Ausgangspunkt für das dokumentierte Snare-Format, nicht als ungeprüfter Ersatz jeder bestehenden NXLog-Konfiguration. Collector-Ziel, gewählte Ereignisse und vorhandene Ausgaben müssen zur eigenen Umgebung passen.

Die aktuell verlinkte Vorlage setzt define PORT 601 und im Block MSWINEVENTLOGOUT Module om_tcp; sie ist deshalb nicht unverändert für den hier beschriebenen UDP/514-Pfad geeignet. Für diesen Pfad:

1. In define XDR A.B.C.D nur den Platzhalter A.B.C.D durch die tatsächliche Collector-IP ersetzen; define XDR bleibt erhalten.
2. Die Portzeile auf define PORT 514 setzen.
3. Im Ausgabeblock MSWINEVENTLOGOUT die Zeile Module om_tcp auskommentieren und die vorhandene Zeile Module om_udp aktivieren. In diesem Block nur ein Ausgabemodul aktiv lassen; andere bestehende Ausgaben separat erhalten.

Danach Syntax und Ereigniszustellung am Pilot prüfen. Sophos nennt dafür Best-Effort-Unterstützung; weitergehende Forwarder-Probleme gehören zum jeweiligen Hersteller.

Prozess-Command-Line für Event 4688

Einige Erkennungen benötigen Felder, die Windows nicht standardmässig protokolliert. Soll Event 4688 neben dem Prozessstart auch die Befehlszeile liefern, nennt Sophos die Windows-Policy:

Administrative Templates > System > Audit Process Creation > Include command line in process creation events

Diese Einstellung wird nur für den freigegebenen Scope und nach Prüfung des Inhalts aktiviert. Befehlszeilen können sensible Werte enthalten. Die Einstellung ersetzt weder die erforderliche Erzeugung von Prozess-Auditereignissen noch den Forwarder-Filter für Event 4688.

Zur Kontrolle startet man einen genehmigten, harmlosen Prozess ohne Geheimnisse in den Argumenten. Zuerst muss im Windows-Quellereignis 4688 die erwartete Befehlszeile vorhanden sein; anschliessend wird das zugehörige normalisierte process-Ereignis in Sophos verglichen. Fehlt die Befehlszeile bereits am Ursprung, kann der Collector sie nicht aus dem fehlenden Feld rekonstruieren.

Aufnahme mit einem Quellereignis nachweisen

Für einen ersten Test eignet sich eine freigegebene Anmeldung an einem dedizierten Testkonto. Windows-Event 4624 beziehungsweise 4625 kann erfolgreiche beziehungsweise fehlgeschlagene Anmeldung belegen; ein absichtlich erzeugter Fehler darf keine Kontosperre provozieren. Es wird nur ein Ereignis verwendet, das im gewählten Audit- und Forwarding-Umfang tatsächlich anfällt.

1. Im Windows-Quelllog Event-ID, Computer, Benutzer, Ergebnis und Uhrzeit festhalten. Nur bereinigte Werte in das Prüfprotokoll übernehmen.
2. Prüfen, dass der Forwarder genau diese Kategorie ausgibt und keine lokalen Format-, Berechtigungs- oder Verbindungsfehler meldet.
3. Im richtigen Sophos-Tenant den Datenfluss der Quelle und danach den Datensatz im erwarteten Schema prüfen. Quellcomputer, Zeitstempel, Benutzer und Ergebnis gegen den Windows-Nachweis vergleichen. Für einen Login wird auth, für Event 4688 process erwartet.
4. Den Test mit weiteren benötigten Ereigniskategorien wiederholen. Ein vorhandener Login beweist keine Aufnahme von Defender-Befunden, Directory-Audits oder netflow.
5. Über einen angemessenen Beobachtungszeitraum frische Datensätze vergleichen und die Abnahme mit Scope, Owner und nächstem Review festhalten.

Das Ereignis muss keine Detection und keinen MDR-Case auslösen. Ebenso beweist eine erfolgreiche Aufnahme heute keine historische Vollständigkeit oder zugesicherte Retention für sämtliche Daten. Für diese Fragen gelten die getrennten Lizenz- und Aufbewahrungsprüfungen.

Fehlende Felder und Datenlücken eingrenzen

Kein Ereignis in Windows: Zuerst Auditvorgabe, ausgewählten Kanal und tatsächliche Quellaktivität prüfen. Ohne Quellereignis gibt es nichts weiterzuleiten.

Quellereignis vorhanden, in Sophos nichts gefunden: Event-Filter des Forwarders, Snare-over-syslog-Format, UTC-Zeitstempel, Collector-IP und UDP/514-Pfad vergleichen. Danach Collector-Zustand und zeitlich passenden Datenfluss prüfen. Nicht vorsorglich einen zweiten Forwarder auf denselben Datenstrom setzen.

Ereignis vorhanden, Pflichtfeld fehlt: Das Feld zuerst im Windows-Original, danach in Forwarder-Ausgabe und normalisiertem Datensatz vergleichen. Für Prozessargumente Event 4688 und die freigegebene Command-Line-Policy prüfen. Ein Feld darf nicht durch einen erfundenen Standardwert ersetzt werden.

Nur netflow fehlt: Windows-Filtering-Platform-Ereignisse, Forwarder-Auswahl und SIEM-Entitlement gesondert prüfen. Der funktionierende Login-Datenweg bestätigt diesen zusätzlichen Scope nicht.

Pilot zurücknehmen oder Betrieb übergeben

Für einen Rückweg nur die neu eingerichtete Ausgabe beziehungsweise den Pilotfilter stoppen und die zuvor gesicherte Forwarder-Konfiguration kontrolliert wiederherstellen. Andere Ausgaben und gemeinsam genutzte Collector bleiben bestehen. Eine Audit-Policy wird nur nach Abgleich mit ihrem dokumentierten Ausgangszustand und nach Freigabe zurückgenommen; sie könnte auch für andere Sicherheits- oder Nachweisaufgaben benötigt werden.

Danach nachweisen, dass der bisherige benötigte Logpfad weiterarbeitet und keine unbeabsichtigte Doppelaufnahme besteht. Das Stoppen des Forwarders stellt verlorene UDP-Ereignisse nicht wieder her und löscht bereits übertragene Telemetrie nicht nachweislich. Für den Regelbetrieb bleiben Quellumfang, Zeitversorgung, Datenfluss, Vorlagenänderungen und Forwarder-Updates in der Verantwortung des benannten Teams.