Sophos-XGS-Logs in Microsoft Sentinel: von Syslog zum verwertbaren Alarm

Sophos XGS und Microsoft Sentinel — die Kombination liegt für jede Microsoft-lastige Umgebung nahe, und die Kurzantwort vorab: Die Anbindung läuft über Syslog an einen Linux-Collector mit Azure Monitor Agent, der die Ereignisse in den Log-Analytics-Workspace hebt; die fertige Sophos-Lösung aus dem Content Hub bringt Parser und erste Inhalte mit, und ab dann sind Firewall-Ereignisse per KQL abfragbar wie jede andere Sentinel-Quelle. Aber — und das ist die Kernbotschaft dieses Artikels — Logs sammeln kann jeder. Der Wert entsteht erst durch zwei Dinge: durch Auswahl (wer ungefiltert alles sendet, bezahlt für Grundrauschen) und durch Korrelation — XGS-Ereignisse neben Entra-Anmeldungen und Defender-Alerts erzählen Geschichten, die keine Quelle allein erzählen kann. Dieser Artikel führt durch die komplette Strecke: Architektur, Collector-Einrichtung, die Log-Auswahl mit Kostenkontrolle, die ersten Analytics Rules mit Firewall-Bezug, die Korrelation mit den Microsoft-Signalen — und die Stellschrauben, mit denen die Rechnung planbar bleibt.

Architektur: der Log-Weg von der Sophos XGS nach Microsoft Sentinel

Die Pipeline hat vier Stationen, und jede hat eine klar umrissene Aufgabe. Station eins ist die XGS selbst: In den Protokolleinstellungen wird ein Syslog-Server hinterlegt — und, entscheidend, dort wird auch je Log-Typ ausgewählt, was überhaupt gesendet wird; dieser erste Filter ist der billigste der ganzen Kette, denn was die Firewall nie verschickt, kostet nie Geld. Station zwei ist der Log-Collector: eine schlanke Linux-VM (on-prem oder in Azure), auf der der Azure Monitor Agent läuft; eine Datensammlungsregel (DCR) bestimmt, welche Syslog-Facilities und Schweregrade er weiterreicht — der zweite Filter. Station drei ist der Log-Analytics-Workspace mit aktiviertem Sentinel: Hier landen die Rohereignisse in der Syslog-Tabelle, und hier tickt auch der Gebührenzähler — abgerechnet wird pro aufgenommenem Gigabyte. Station vier schließlich sind die Analytics Rules: zeitgesteuerte KQL-Abfragen, die aus Log-Zeilen Incidents machen.

Zwei Architektur-Anmerkungen gehören dazu. Erstens die Nachbarschaft: Der eigentliche Grund, XGS-Logs ausgerechnet nach Sentinel zu bringen, sind die anderen Mieter im selben Workspace — Entra-ID-Anmeldeprotokolle und Defender-Alerts fließen über native Connectors mit wenigen Klicks ein, und erst dieses Nebeneinander macht aus Firewall-Zeilen korrelierbare Signale (das eigene Kapitel dazu folgt). Zweitens die Rohdaten-Frage: Die XGS liefert ihr eigenes Syslog-Format, das im Workspace zunächst als generische Syslog-Zeile ankommt — lesbar macht es die Parser-Funktion der Sophos-Lösung, die aus dem Textwurm benannte Felder wie Benutzer, Quell-IP und Aktion extrahiert. Die Pipeline-Skizze zeigt den kompletten Weg samt der beiden Filter vor dem Gebührenzähler.

Skizze 1: Vier Stationen, zwei Filter vor dem Gebührenzähler — und die Workspace-Nachbarn Entra und Defender als eigentlicher Grund für die ganze Übung.

Syslog-Collector mit Azure Monitor Agent einrichten

Die Einrichtung des Collectors ist ein Nachmittagsprojekt, wenn die Reihenfolge stimmt. Schritt eins: eine Linux-VM bereitstellen — eine kleine Ubuntu- oder RHEL-Maschine mit zwei CPU-Kernen und vier Gigabyte RAM trägt den Mittelstand locker; sie kann on-prem stehen (kurzer Weg von der Firewall, Logs verlassen das Haus gebündelt über HTTPS) oder als Azure-VM (bei Azure-Arc-Anbindung der On-Prem-Variante nimmt sich das wenig). Schritt zwei: die Maschine mit dem Workspace verbinden — bei Azure-VMs direkt, on-prem über Azure Arc — und den Azure Monitor Agent per Portal ausrollen. Schritt drei: die Datensammlungsregel anlegen, die Syslog-Daten der relevanten Facilities einsammelt und in den Workspace schreibt. Schritt vier: aus dem Sentinel Content Hub die Sophos-Firewall-Lösung installieren — sie bringt den Daten-Connector samt Anleitung, die Parser-Funktion und erste Inhalte wie Workbook und Regel-Vorlagen mit.

Schritt fünf wechselt auf die XGS: Syslog-Server eintragen (die Collector-IP), als Transport TCP oder besser TLS statt des klassischen UDP — bei Sicherheitsereignissen ist »Paket weg, Pech gehabt« kein akzeptables Zustellmodell —, und dann die Log-Typen-Auswahl treffen, die das nächste Kapitel systematisch behandelt. Schritt sechs ist die Verifikation: In Sentinel eine Abfrage auf die Syslog-Tabelle absetzen, prüfen, dass Ereignisse ankommen, und die Parser-Funktion testweise über die Daten laufen lassen — erst wenn Benutzer, IPs und Aktionen als saubere Felder erscheinen, ist die Pipeline wirklich fertig. Ein Betriebshinweis zum Schluss: Der Collector ist ein Single Point of Logging — wer es ernst meint, stellt einen zweiten daneben und trägt beide auf der XGS ein.

Log-Auswahl: was senden, was weglassen — die Kostenkontrolle beginnt an der Quelle

Jetzt zur wichtigsten Einzelentscheidung des ganzen Projekts, und sie fällt nicht in Azure, sondern auf der Firewall: Welche Log-Typen werden überhaupt gesendet? Die Leitfrage für jede Kategorie lautet nicht »könnte das mal interessant sein?« (Antwort: immer ja, deshalb ist die Frage wertlos), sondern: »Gibt es eine Regelidee, die auf diesen Daten anspringen soll — oder einen Untersuchungsfall, der sie braucht?« Mit dieser Brille sortiert sich das XGS-Angebot erstaunlich klar in drei Klassen, die die Ampel-Skizze zusammenfasst: Immer senden, was hohen Sicherheitswert bei kleinem Volumen liefert — ATP- und IPS-Ereignisse, WAF-Blocks, sämtliche Authentifizierung (VPN und Portale, Erfolg wie Fehlschlag), Admin- und Konfigurationsereignisse, dazu die gezielten Verwerfen-Regeln mit Signalwert wie der Port-25-Wächter aus dem Mailfluss-Regelwerk. Selektiv senden, was Wert hat, aber wuchern kann — verweigerter Verkehr an der Außenkante nur gefiltert, Webfilter nur Blocks. Und draußen lassen, was Masse ohne Detektionswert ist: erlaubter Verkehr Zeile für Zeile, erlaubter Web-Traffic, DHCP, Wireless-Geplauder.

Skizze 2: Die Ampel sortiert das XGS-Log-Angebot — das Ergebnis ist ein kuratierter Strom von grob 10–20 % des Rohvolumens mit praktisch vollem Detektionswert.

Erste Analytics Rules mit Firewall-Bezug

Mit sauber geparsten Daten beginnt der eigentliche Spaß: Analytics Rules sind zeitgesteuerte KQL-Abfragen, die bei Treffern Incidents erzeugen — samt Entitäten wie Benutzer, IP und Host, die später die Korrelation tragen. Die Startdisziplin ist dieselbe wie bei der Log-Auswahl: lieber fünf Regeln, deren Alarme jemand ernst nimmt, als fünfzig, die nach zwei Wochen stummgeschaltet werden. Die dankbarsten Kandidaten für den Anfang stehen in der Tabelle — sie decken die Klassiker ab: Brute-Force am VPN (viele Fehlschläge, dann Erfolg — das Muster, nicht der Einzelfehler), jeden ATP-Treffer (die Kategorie ist selten genug, dass jeder Fund einen Incident wert ist), administrative Anmeldungen und Konfigurationsänderungen außerhalb der Wartungsfenster, und den Port-25-Frühwarner aus dem Mailfluss-Regelwerk. Für die IPS-Ereignisse gilt eine Besonderheit: Ihr Alarmwert steht und fällt mit dem Tuning der Profile — ein verrauschtes IPS produziert verrauschte Incidents; die Vorarbeit dazu leistet der IPS-Artikel [LINK: A4].

Korrelation mit Entra- und Defender-Signalen

Jetzt zum Kapitel, das den Sentinel-Aufwand rechtfertigt — denn alles bisher könnte ein beliebiger Syslog-Server auch. Korrelation heißt: Ereignisse verschiedener Quellen über gemeinsame Schlüssel verbinden, und davon gibt es drei: den Benutzernamen (mit einer Stolperfalle: Die XGS loggt oft die Kurzform, Entra den UPN — die Abfrage muss normalisieren, sonst findet der Join nie etwas), die IP-Adressen und das Zeitfenster. Das Lehrbuchbeispiel zeigt die Skizze: Eine VPN-Anmeldung an der XGS aus Deutschland und eine M365-Anmeldung desselben Benutzers aus einem anderen Land fünf Minuten später — jede Quelle für sich unauffällig, zusammen eine unmögliche Reise über Systemgrenzen hinweg, die keine der beiden Plattformen allein je gesehen hätte. Technisch ist das ein KQL-Join zwischen der geparsten Sophos-Tabelle und den SigninLogs im Zeitfenster; als Analytics Rule verpackt, wird daraus ein Incident mit hoher Priorität.

Die zweite Korrelationsrichtung läuft über den Endpoint: Meldet Defender einen Alarm auf einem Gerät und zeigt die XGS zeitgleich verdächtige Verbindungsmuster derselben internen IP — geblockte Ziele, ATP-Treffer, ungewöhnliche Ports —, dann verwandelt die Verknüpfung zwei mittlere Einzelmeldungen in ein klares Bild: Der Host ist kompromittiert und versucht nach draußen zu telefonieren. Praktisch beginnt man hier nicht mit eigenen Regeln, sondern mit Anreicherung: Bei jedem Defender-Incident die Firewall-Sicht der betroffenen IP im fraglichen Zeitraum abfragen — eine gespeicherte Hunting-Query genügt für den Start. Wie aus solchen Verknüpfungen belastbare, revisionsfeste Nachweisketten für Prüfer werden, vertieft der Audit-Korrelations-Artikel [LINK: C4]; und was im Ernstfall aus einem korrelierten Incident folgt — Eindämmung, Forensik, Kommunikation —, behandelt der Incident-Response-Artikel [LINK: C9].

Skizze 3: Zwei für sich unauffällige Ereignisse, drei Join-Schlüssel, ein Befund — die unmögliche Reise über Systemgrenzen ist der Klassiker der Firewall-Identitäts-Korrelation.

Kosten im Griff behalten

Zum Schluss das Thema, an dem SIEM-Projekte intern gewinnen oder verlieren: die Rechnung. Die Kostenlogik steht im Faktenkasten in zwei Sätzen; daraus folgen vier Stellschrauben in absteigender Wirkung. Stellschraube eins ist die Quelle — die Ampel entscheidet über den Löwenanteil, denn nicht gesendete Gigabytes sind die einzigen, die garantiert nichts kosten. Stellschraube zwei ist die Überwachung: Das Verbrauchsblatt des Workspace zeigt das Volumen je Tabelle und Tag — ein wöchentlicher Blick plus eine Warnung bei ungewöhnlichem Anstieg fängt den schleichenden Zuwachs, bevor er zur Quartalsüberraschung wird; typischer Auslöser ist eine gut gemeinte neue Firewall-Regel mit Logging auf erlaubtem Verkehr. Stellschraube drei ist die Aufbewahrung: Die inkludierten Tage decken die operative Arbeit; wer für Compliance länger vorhalten muss, nutzt die günstigen Langzeit-Speicherklassen statt der teuren Analytics-Vorhaltung. Und Stellschraube vier sind die Abnahmerabatte ab konstant höherem Tagesvolumen — für die XGS-Anbindung allein selten relevant, im Verbund mit den Microsoft-Quellen durchaus.

FAQ — häufige Fragen zu Sophos-XGS-Logs in Microsoft Sentinel

Wie sende ich Sophos-Logs an Microsoft Sentinel?

Der Standardweg in fünf Schritten: Erstens eine kleine Linux-VM als Log-Collector bereitstellen (on-prem oder in Azure), zweitens sie per Azure Arc beziehungsweise direkt mit dem Log-Analytics-Workspace verbinden und den Azure Monitor Agent installieren, drittens eine Datensammlungsregel anlegen, die die relevanten Syslog-Facilities in den Workspace schreibt, viertens aus dem Sentinel Content Hub die Sophos-Firewall-Lösung installieren — sie liefert Connector-Anleitung, Parser-Funktion und erste Inhalte —, und fünftens auf der XGS den Syslog-Server eintragen (Collector-IP, TCP oder TLS statt UDP) samt bewusster Auswahl der Log-Typen. Danach beweist eine Abfrage auf die Syslog-Tabelle die Ankunft, und die Parser-Funktion macht aus den Rohzeilen benannte Felder. Zwei Randnotizen: Der alte Log-Analytics-Agent (MMA) ist abgekündigt — Anleitungen auf seiner Basis sind Geschichte. Und ein zweiter Collector kostet wenig, macht die Pipeline aber ausfallsicher.

Was kostet die Log-Aufnahme ungefähr?

Die Rechnung hat zwei Faktoren: das tägliche Volumen und den Gigabyte-Preis der Analytics-Klasse (zum Redaktionsstand kombiniert grob vier bis fünf Euro je Gigabyte — regions- und modellabhängig, verbindlich ist der Azure-Preisrechner). Das Volumen wiederum hängt fast vollständig an der Auswahl: Mit dem kuratierten Ampelmodell dieses Artikels liegt eine typische Mittelstandsumgebung bei 0,2 bis 0,5 Gigabyte pro 100 Benutzer und Tag — für 200 Benutzer also grob bei 60 bis 150 Euro im Monat für die Firewall-Quelle. Der Alles-Sender zahlt für dieselbe Erkenntnis das Fünf- bis Zehnfache. Der seriöse Weg zur eigenen Zahl: Auswahl festlegen, zwei Wochen senden, im Verbrauchsblatt das Tabellenvolumen ablesen, hochrechnen — und eine Volumen-Warnung einrichten. Aufbewahrung jenseits der inkludierten Tage und die übrigen Quellen kommen gegebenenfalls obendrauf — etliche Microsoft-Alertquellen fließen kostenfrei ein.

Welche XGS-Logs lohnen sich im SIEM?

Die mit einer Regelidee dahinter — das ist der ganze Trick. Konkret, absteigend nach Wert-pro-Gigabyte: ATP-Ereignisse (winzig im Volumen, jeder Treffer untersuchungswürdig), die komplette Authentifizierung an VPN und Portalen inklusive Fehlschlägen (Fundament für Brute-Force- und Korrelationsregeln), Admin- und Konfigurationsereignisse (wer hat wann was geändert — Audit-Gold), IPS-Treffer (nach dem Profil-Tuning), WAF-Blocks der veröffentlichten Dienste und die gezielten Verwerfen-Regeln mit Signalwert — allen voran der ausgehende Port-25-Wächter als Botnet-Frühwarnung. Selektiv dazu: verweigerter WAN-Verkehr in gefilterter Form und Webfilter-Blocks. Nicht ins SIEM gehören die Massenkategorien ohne Detektionswert: erlaubter Verkehr Zeile für Zeile, erlaubtes Surfen, DHCP, Wireless-Geplauder. Die Gegenprobe: Wenn du keine Regel benennen kannst, die darauf anspringen soll, ist »könnte man mal brauchen« nur die teure Umschreibung für »weiß nicht«.

Gibt es fertige Sentinel-Inhalte für Sophos?

Ja — der Startpunkt ist die Sophos-Firewall-Lösung im Sentinel Content Hub: Sie bündelt den Daten-Connector samt Einrichtungsanleitung, die Parser-Funktion, die aus den Syslog-Rohzeilen abfragbare Felder macht, ein Workbook für die Visualisierung und Vorlagen für Analytics Rules. Die ehrliche Einordnung dazu: Die Vorlagen sind ein Fundament, kein Fertighaus — sie kennen weder deine Management-Netze noch deine Wartungsfenster, deine Regel-IDs oder deinen speziellen Port-25-Wächter, und ungetunte Vorlagen produzieren entweder Stille oder Rauschen. Der bewährte Weg: Lösung installieren, Parser verifizieren, dann die eigenen fünf Startregeln aus der Detektions-Tabelle bauen und die Vorlagen als Steinbruch für KQL-Muster nutzen. Ein zweiter Blick lohnt auf die herstellerneutralen Content-Hub-Inhalte — generische Detektionen wie unmögliche Reise oder Brute-Force-Muster funktionieren mit den geparsten Sophos-Feldern oft auf Anhieb.

Wie korreliere ich Firewall- und Anmelde-Ereignisse?

Über drei gemeinsame Schlüssel: Benutzername, IP-Adresse und Zeitfenster — technisch als KQL-Join zwischen der geparsten Sophos-Tabelle und den Entra-SigninLogs. Die eine Stolperfalle, die fast jeden ersten Versuch scheitern lässt: die Namensnormalisierung. Die XGS protokolliert Benutzer gern in Kurzform (m.schulz), Entra als UPN (m.schulz@firma.de) — ohne Angleichung in der Abfrage findet der Join schlicht nichts, und der Fehler ist tückisch, weil er keine Fehlermeldung produziert, sondern nur leere Ergebnisse. Das Einstiegsrezept: erst als Hunting-Query bauen und auf Plausibilität prüfen, dann als Analytics Rule mit Schwellwerten scharf schalten. Der Klassiker als erste Regel: unmögliche Reise über Systemgrenzen — VPN-Login aus Land A, M365-Login desselben Benutzers aus Land B binnen Minuten. Danach die Endpoint-Richtung: Defender-Incidents automatisch um die Firewall-Sicht der betroffenen IP anreichern — oft der schnellste Erkenntnisgewinn der ganzen Anbindung.

Reicht Sophos Central nicht aus?

Für die Sophos-Welt: oft ja. Central bündelt Firewall-Berichte, Alarme und mit XDR auch übergreifende Erkennung innerhalb des Sophos-Ökosystems — wer ausschließlich wissen will, was seine Firewall und seine Sophos-Endpoints treiben, ist dort gut und ohne Zusatzkosten für Log-Aufnahme bedient. Die Grenze verläuft exakt an der Herstellergrenze: Central sieht keine Entra-Anmeldungen, keine Defender-Alerts, keine M365-Ereignisse — und damit keine der Korrelationen, die dieser Artikel beschreibt; die unmögliche Reise zwischen VPN und Cloud-Anmeldung bleibt dort schlicht unsichtbar. Die Entscheidungsformel: Sophos-only-Sicht plus überschaubare Compliance-Anforderungen → Central genügt. Microsoft-lastige Umgebung mit zusammenfließenden Identitäts-, Endpoint- und Firewall-Signalen, zentrale SOC-Sicht oder lange revisionssichere Aufbewahrung → Sentinel. Und es ist kein Entweder-oder: Der Alltag vieler Umgebungen ist Central für den Sophos-Betrieb und Sentinel als Korrelationsebene darüber — die XGS beliefert beide parallel.

Fazit: Auswahl vor Anbindung, Korrelation vor Sammelwut

Die technische Anbindung der XGS an Sentinel ist ein Nachmittag: Collector, Agent, Datensammlungsregel, Content-Hub-Lösung, Syslog-Ziel — fertig ist die Pipeline. Über Wert oder Frust des Projekts entscheiden die beiden Disziplinen drumherum: die Auswahl an der Quelle (die Ampel schlägt jeden Tarif-Trick, weil nicht gesendete Gigabytes die einzigen kostenlosen sind) und die Korrelation als eigentlicher Daseinszweck — Firewall-Ereignisse neben Entra-Anmeldungen und Defender-Alerts erzählen Geschichten, die keine Quelle allein kennt, von der unmöglichen Reise bis zum halb bereinigten Notebook. Wer mit fünf ernst genommenen Regeln startet, das Volumen wöchentlich im Blick behält und jeden Defender-Incident automatisch um die Firewall-Sicht anreichert, hat nach einem Monat ein SIEM, das Fragen beantwortet statt Speicher zu füllen — und eine Rechnung, die niemand erklären muss.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen zeichnet der Pillar-Artikel [LINK: Pillar]. Wie aus korrelierten Ereignissen revisionsfeste Nachweisketten für Prüfungen werden, vertieft der Audit-Korrelations-Artikel [LINK: C4]. Was im Ernstfall aus einem Incident folgt — Eindämmung, Forensik, Wiederanlauf —, behandelt der Incident-Response-Artikel [LINK: C9]. Und damit die IPS-Ereignisse Signalwert statt Rauschen liefern, gehört vorab das Profil-Tuning aus [LINK: A4] erledigt.