MDR- und XDR-Integrationen in Sophos Fusion einrichten

Mit Integrationen führt Sophos Fusion (ehemals Sophos Central) Telemetrie aus Sophos- und Drittprodukten im Sophos Data Lake zusammen oder stellt gezielte Response Actions bereit. Entscheidend ist die Wahl des richtigen Integrationstyps: Data Ingest liefert Daten für Abfragen, Detections und Untersuchungen; Response Action führt eine Aktion im angebundenen Produkt aus. Nicht jedes Produkt unterstützt beide Richtungen.

Der Einstieg hängt vom Produktstand des Tenants ab. Für die erweiterte XDR-/MDR-Lösung gilt Security Operations > Integrations > Marketplace; bestehende Classic-Konfigurationen liegen im Threat Analysis Center > Integrations. Die folgenden TAC-Anleitungen beschreiben diesen Classic-Pfad und sind keine identische Klickfolge für die neue Oberfläche. Die tenantbezogene Upgrade-Prüfung hilft bei der Zuordnung. Sichtbare Fusion-Namen allein beweisen kein abgeschlossenes Produktupgrade.

Im Endpoint-Onboarding-Pfad schliesst dieser Artikel die produktübergreifende Integrationsphase zwischen Schutzkonfiguration und Betriebsabnahme.

Der praxistaugliche Ablauf lautet: Lizenz und Quellsystem prüfen, im Marketplace die passende Produktkachel und Konfiguration wählen, die Verbindung mit möglichst kleinen Berechtigungen aufbauen, unter Configured kontrollieren und mit einem erwarteten Testereignis verifizieren. Erst danach sollte die Integration als produktiv gelten.

Verbindung und tatsächlichen Datenfluss getrennt kontrollieren

In der aktuellen Oberfläche öffnet man Security Operations > Integrations > Configured Integrations. Unter Data Ingest zeigt der Status die Konfiguration und Verbindung der API-, Syslog- oder Sophos-Integration. Ein grüner Status bestätigt Kommunikation, nicht bereits korrekt normalisierte Ereignisse. Nach 20 Minuten ohne Kommunikation beziehungsweise bei nicht meldenden Teilressourcen kann eine Warnung erscheinen; nach 60 Minuten oder fehlgeschlagener Authentifizierung ein Fehler. Der Hover-Text liefert den konkreten Grund.

Bei einer API-Integration öffnet man den Namen und API Query Logs. Standard ist der letzte Tag, auswählbar sind bis zu sieben Tage. Unter Details werden die Parameter mit dem richtigen Quell-Tenant verglichen. Hierarchische Integrationen können einen Parent mit mehreren Child-Endpunkten enthalten; ein gesunder Teilpfad beweist nicht die Funktion aller Kinder.

Danach prüft man Security Operations > Integrations > Configured Data Sources. Diese eigene Ansicht beantwortet, ob Logs tatsächlich eingehen und welchen Schemas sie zugeordnet werden. Healthy bedeutet Aktivität innerhalb einer Stunde, Warning zwischen einer und 24 Stunden und Unhealthy länger als 24 Stunden ohne Aktivität. Das sind andere Kriterien als die Verbindungsgrenzen oben. Eine selten sendende Quelle wird gegen ihre erwartete Aktivität beurteilt, nicht durch ein erfundenes Testereignis als gesund erklärt.

Ein Klick auf die Quelle zeigt den Nachrichtenverlauf je Schema der letzten 24 Stunden. Für die Abnahme erzeugt man ein genehmigtes Ereignis im Quellsystem und vergleicht Zeitpunkt, Quelle, Pflichtfelder und normalisiertes Schema. Advanced Search in den Quelldetails öffnet eine vorbereitete Suche für die Sensor-ID der letzten 24 Stunden. Die Suchanleitung erklärt die weitere Eingrenzung. Fehlen Daten, wird zunächst der Weg Quelle → Integration/Collector → Schema geprüft; eine Detection ist für ein gewöhnliches Auditereignis nicht zu erwarten.

Export All as CSV beziehungsweise Export Selected as CSV sichert das Quelleninventar über Data Exports. Das Papierkorb-Symbol entfernt dagegen nur den Data-Source-Datensatz, nicht die bereits empfangene Telemetrie. Die Löschung ist nicht rückgängig zu machen; eine weiter sendende Quelle erscheint wieder, die Entfernung kann bis zu fünf Minuten dauern. Löschen ist deshalb weder eine Datenlöschbestätigung noch ein Reparaturtest.

Sichtbarkeit, Berechtigung und aktuelle API-Allowlist

Der Marketplace zeigt je nach Produkt getrennte Ingest- und Actions-Kacheln. EDR ohne XDR zeigt keine Nicht-Endpoint-Ingest-Kacheln; Response-Actions können weiterhin sichtbar sein. Admin und Super Admin können Integrationen verwalten. Help Desk und Read-only sehen nur Konfiguration und Status. Bei Custom Roles werden Integration: read sowie nur die benötigten Rechte create, update, delete und download vergeben. Eine nicht sichtbare Funktion wird gegen Lizenz und Rolle geprüft, bevor Rechte erweitert werden.

Die aktuelle XDR-Allowlist ist vom folgenden Classic-IP-Snapshot und vom Collector-Uplink zu trennen. Unter Profile icon > Support settings wird die tatsächliche geografische XDR-Region ermittelt; nicht aus einem Produktnamen raten. Die Herstellerliste vom 25. September 2026 nennt für administrative/API-Aufrufe beim Drittanbieter:

Nur den zur tatsächlichen Integration gehörenden Bereich nach Change-Freigabe zulassen. Die Liste beweist keine Verfügbarkeit jedes Produkts in allen Regionen und ersetzt nicht die Prüfung der aktuell benötigten API-Ziele. Der ausgehende mTLS-Pfad des Collectors verwendet andere Ziele.

Health-Benachrichtigungen gezielt adressieren

Die weiter unten erklärten Regeln für 24 Stunden kontinuierlichen Fehler, Countdown-Reset und 30-tägige Wiederholung gelten auch für die aktuelle Fusion-Hilfe vom 20. Oktober 2026. Die E-Mail ist kein Sofortalarm nach den oben genannten 20 oder 60 Minuten.

Eine eigene Empfängerregel öffnet man unter General Settings > Platform > Notification Settings > Configure email alerts > Custom rules > + Create new rule. Nach Rolle, Administratoren/Verteilerlisten und Geräteumfang werden unter Alert Types die Filter Medium alert, Produkt Sophos Central und Kategorie Central Integrations Alert gewählt. Anschliessend Namen/Beschreibung setzen und speichern. Vor dem Speichern muss die weitere Verteilung anderer Alerts geplant sein: Die erste eigene Regel schaltet den Standardversand aller E-Mail-Alerts an alle Administratoren ab. Notwendige übrige Empfänger werden deshalb durch weitere passende Regeln erhalten; keine Test-Störung am Produktivconnector erzeugen, nur um eine Mail zu erzwingen.

Quellenbezogene nächste Schritte

Für eigene Quellen führen HTTP Ingest, S3 und Azure durch die getrennten Transportwege. Der Collector-Betrieb und die Cloud-Bereitstellung ergänzen das vorhandene Migrationsrunbook. Cloud Flow Logs, Netzwerktelemetrie und Windows Event Logs behandeln die benötigten Quellformate und Schema-Lizenzgrenzen. Nicht jede Telemetrie eines Herstellers wird pauschal zur SIEM-pflichtigen Quelle.

Nach dem Upgrade: Response Actions wieder betriebsbereit machen

Prüfstand 11. Oktober 2026: Die erweiterte Lösung verwendet für Actions ein anderes Ausführungs- und Berechtigungsmodell. Bestehende TAC-Verbindungen und deren Credentials werden dafür nicht einfach übernommen. Vor einer Änderung dokumentiert man die betroffenen Microsoft-Tenants, Verbindungen, aktivierten Aktionen und Verantwortlichen. Die erfolgreiche Datenaufnahme eines separaten Audit- oder Graph-Connectors ist kein Response-Test.

Microsoft 365 neu verbinden oder Credentials erneut autorisieren

Für diese Schritte benötigt man in Sophos Fusion Admin oder Super Admin und auf Microsoft-Seite einen Microsoft 365 administrator. Man prüft in jedem Consent-Dialog die tatsächlich angeforderten Rechte und den richtigen Microsoft-Tenant und übernimmt nicht ungeprüft den Berechtigungssatz einer alten TAC-App.

Ist die frühere TAC-Verbindung in der neuen Oberfläche noch nicht eingerichtet, erstellt man sie so:

1. Man öffnet Security Operations > Integrations > Marketplace und die Actions-Kachel Microsoft Graph API.
2. Man wählt Add new connection. Im Bereich Add a Connection erneut Add new connection wählen, Name und bei Bedarf Description sowie Tags erfassen und mit Done fortfahren.
3. Mit Proceed die geführte Microsoft-Autorisierung starten. Ein Name wie M365-Response-Produktiv ist nur eine frei wählbare Kennzeichnung; entscheidend sind der richtige Quell-Tenant und die genehmigten Rechte.
4. In Pick an account das vorgesehene Administratorkonto wählen. Die erste Permissions requested-Abfrage autorisiert die Sophos-Master-Anwendung. Nach der Rückkehr zu Sophos folgt ein zweiter Microsoft-Schritt für die eigentliche Response-Verbindung. Beide Dialoge nach Rechteprüfung mit Accept abschliessen. Wird einer abgebrochen, wird keine Verbindung erstellt.
5. Nach Rückkehr die angebotenen Aktionen prüfen und nur den freigegebenen Umfang mit Save speichern. Die neue Verbindung muss in Configured Integrations erscheinen.
6. In Microsoft Entra unter Manage > All applications mit Refresh kontrollieren, dass die neu erstellte Response-Anwendung aktiviert erscheint.

Ist bereits eine Verbindung unter Microsoft Graph API > Configured Integrations vorhanden, öffnet man am Verbindungsnamen das Drei-Punkte-Menü und Edit Connection. Man wählt Re-Authorize Credentials und durchläuft die Microsoft-Autorisierung. Der Button erscheint nur bei nötiger Neuautorisierung und verschwindet nach Abschluss. Man wiederholt dies für jede betroffene Verbindung; die Reparatur einer einzelnen Verbindung genügt nicht für alle Tenants oder Konfigurationen.

Die aktualisierte Anleitung vom 7. Oktober 2026 unterscheidet ausdrücklich zwischen weiterlaufendem Schutz und möglicherweise fehlschlagenden Microsoft-Response-Aktionen bis zur Neuautorisierung. Sie nennt 1. Oktober 2027 als Ablaufgrenze der bisherigen Credentials. Man wartet bei benötigten Actions nicht bis zu dieser Grenze: Der erforderliche Funktionsnachweis ist jetzt zu erbringen.

Zur Abnahme gehören die richtige Entra-Anwendung, die erwarteten Verbindungen und aktivierten Aktionen sowie ein genehmigter Test mit einem dedizierten Konto. Man verwendet nur eine für die aktuelle Aktion dokumentierte reversible Änderung. Die unten beschriebene Classic-Paarung Block user sign-in / Allow user sign-in ist kein Beleg, dass jede neue Action gleich heisst oder denselben Rückweg hat. Sessions lassen sich nach einem Widerruf nicht wiederherstellen. In den Action-Details liefert View Executions > History den Verlauf; zusätzlich prüft man den tatsächlichen Zustand in Microsoft. Ein Consent oder ein erfolgreicher Ausführungseintrag allein ersetzt diese Gegenprüfung nicht.

Sophos Firewall (Actions) nur bei fehlender Verbindung ergänzen

Nach dem Produktupgrade zunächst einen Case öffnen und prüfen, ob Sophos-Firewall-Aktionen verfügbar sind. Wenn ja, ist keine neue Verbindung erforderlich. Wenn sie fehlen:

1. Security Operations > Integrations > Marketplace öffnen.
2. Sophos Firewall (Actions) suchen und öffnen.
3. Add new connection wählen und mit Save speichern.

Für diese Verbindung werden keine Credentials verlangt. Danach stehen Firewall-Response-Aktionen aus Cases zur Verfügung: etwa das Blockieren schädlicher IP-Adressen, Domains oder URLs. MDR-Analysten können solche Aktionen im Rahmen der freigegebenen Response-Einstellung ausführen; XDR-Anwender können sie selbst aus dem Case starten. Die Verfügbarkeit prüft man ohne produktive Ziele zu blockieren. Ein Wirkungstest ist ein separater, genehmigter Change mit einem vorher geklärten produktspezifischen Rückweg.

Neue Actions gezielt deaktivieren statt Verbindungen blind löschen

Für Actions in der erweiterten Lösung gibt es einen dokumentierten Schalter: Unter Security Operations > Integrations > Marketplace, Configured > Actions, die betreffende Action öffnen und im Bereich Enable/disable integration deaktivieren. Das ist kein universeller Schalter für alle Data-Ingest-Connectoren. Eine Deaktivierung stellt bereits ausgeführte Änderungen im Quellsystem nicht zurück.

Delete Integration entfernt die zugehörigen Verbindungen und Bedingungen und setzt die Action-Konfiguration auf den Ausgangszustand zurück. Das Entfernen der einzigen Verbindung löscht ebenfalls deren zugehörige Bedingungen. Vorher deshalb Verbindungen und Bedingungen sichern beziehungsweise dokumentieren. Für Rücknahme von Testaktionen gilt weiterhin der konkrete Microsoft- oder Firewall-Rückweg, nicht das Löschen des Connectors.

XDR-Automationen: Classic REST und GraphQL auseinanderhalten

Der API-Stand ist ein Nachtrag vom 9. Oktober 2026, nicht eine rückwirkende Zusage zum September-Launch. Neue XDR-Integrationen und schreibende XDR-Workflows auf Fusion sollen die neuen GraphQL APIs nutzen. Das ist von einer Marketplace-API-Verbindung zu unterscheiden: Deren REST-Aufrufe können weiterhin zum Drittanbieter gehen.

Die bisherigen Cases REST API und Detections REST API heissen nun Classic XDR APIs und sind abgekündigt. Die Detections REST API ist bereits read-only. Die Cases REST API bleibt für bestehende Integrationen verfügbar; auch sie soll später read-only werden. Anschliessend sollen beide APIs historische Daten bis zu ihrer Entfernung bereitstellen. Ein konkretes Abschaltdatum nennt dieser Stand nicht. Bestehende Integrationen deshalb nicht pauschal löschen oder ihre Hosts wegen des Namens Fusion umschreiben.

Für jede Automation notiert man API, lesende und schreibende Operationen, Datenzeitraum, Tenant, Rechte und Fehlerbehandlung. Man prüft bei bestehenden Clients getrennt, ob aktuelle oder historische Daten erwartet werden und ob ein Schreibworkflow noch auf Classic Detections zugreifen will. Für den GraphQL-Wechsel müssen Feldzuordnung, Pagination, Authentifizierung, Berechtigungen und Fehlerbehandlung anhand des konkreten neuen Schemas umgesetzt und in einem isolierten Test verglichen werden. Dieser Artikel gibt bewusst keine erfundenen Endpoints, Mutationsnamen oder Payloads vor. Die Bestandsaufnahme ist abgeschlossen, wenn jeder Client einen Owner und einen nachvollziehbaren Weiterbetriebs- oder Migrationsentscheid hat; sie ist noch kein erfolgreicher API-Migrationstest.

Welche GraphQL API gehört zum Client?

Die Veröffentlichung vom 18. September 2026 umfasste fünf GraphQL APIs mit unterschiedlichen Aufgaben:

• Detections v2: Detections aus Endpoints, Netzwerksensoren und weiteren Quellen suchen und bearbeiten.
• Cases v2: Cases sowie Evidence, Kommentare, Dateien und Links verwalten.
• Threat Timeline v2: Prozesszusammenhänge für bis zu 100 Prozesse in einem Aufruf suchen.
• Events v1: Ereignisdetails anhand bekannter Event-IDs abrufen.
• Live Endpoint Search v1 (LES): osquery-artige Abfragen auf verbundenen Endpoints ausführen und Ergebnisse sowie Telemetry abrufen.

Live Discover REST gehört nicht zur Abkündigung der Classic Cases/Detections APIs. Bestehende Live-Discover-REST-Integrationen können weiterarbeiten; ihr Wechsel auf LES ist optional. Der Live-Pfad und die historische XDR Query API sind verschiedene Aufgaben. Die Live-Discover-API-Abgrenzung erklärt auch die sessionbasierte LES-Zielauswahl. Ebenso werden die Endpoint API unter /endpoint/v1 und deren Device Migration nicht wegen dieser XDR-Abkündigung auf GraphQL umgestellt.

Seit 12. Oktober 2026 ist zusätzlich die Search GraphQL API v1 für historische QL-Suchen veröffentlicht. Sie bietet createSearch, getOrCreateSearch, search und searchResults; Request-Vertrag, Ausführungsstatus, Ergebnis-Seiten und SQL-Migrationsprüfung beschreibt Sophos Fusion Data Lake per Search GraphQL API abfragen. Data Lake Search bleibt der interaktive Suchweg; die XDR Query API bleibt verfügbar. Die neue API erzwingt keinen sofortigen Wechsel und ist kein LES-Live-Endpoint-Workflow. Für Assets und Entity Graph bleibt die separate Referenz- und Tenant-Prüfung offen: Ihre Erwähnung im Cases-Leitfaden ist keine vollständige Implementierungsfreigabe.

Den konkreten Migrationsvertrag prüfen

Der Wechsel ist kein Austausch der URL bei unverändertem Client. Für Cases, Detections und optional LES wird jeweils der eigene Workflow verglichen, nicht ein gemeinsames REST-zu-GraphQL-Rezept:

• GraphQL liefert nur ausgewählte Felder. Der Client prüft sowohl HTTP-Status als auch das errors-Array und operationsspezifische Statusfelder; HTTP 200 kann einen Query-Fehler enthalten. Benötigte verschachtelte Felder und Zeitangaben mit seconds/nanos werden bewusst ausgewählt und verarbeitet.
• Bei Detections ersetzt detectionSearch den REST-Ablauf aus Query-Start, Statusabfrage und Ergebnisabruf. Kleine Suchmengen verwenden offset/limit, grosse Suchmengen den zurückgegebenen search_id mit detectionPoll. Alle Teile und die Gesamtzahl abgleichen. Filter werden einzeln als QL-Prädikate geprüft; ein Host-Lookup erwartet eine ID, nicht einfach den Gerätenamen. Ein REST-type oder eine Intelix-Reputation hat keinen zugesicherten identischen Ersatz.
• Die Detection-Severity von REST und GraphQL bewertet getrennte Datensätze nach getrennten Modellen. REST verwendet eine Ganzzahlskala bis 10, GraphQL metadata.severity eine Skala von 0 bis 1. Nicht durch Division umrechnen. Schwellen anhand der jeweiligen Daten fachlich neu prüfen. Case.severity mit 2/4/6/8/10 ist nochmals eine andere Skala.
• Bei Cases verwendet der API-Client die UUID id, nicht die lesbare shortId im Format CSE#####. Alte REST-Case-IDs werden nicht übersetzt und alte Cases nicht über die neue API verfügbar. Benötigte Altfall-Nachweise werden vor dem Cutover mit dem bestätigten bisherigen Abrufweg gesichert; daraus folgt weder ein universeller Exportbutton noch eine Übernahme der Historie.
• Case-Typen, Status und Verdicts werden als dynamische, lizenzabhängige Tenant-Referenzdaten aufgelöst und regelmässig aktualisiert. assigneeId erwartet eine Subject ID oder eine unterstützte @mention, keine E-Mail-Adresse. Ein nicht auflösbares assigneeSubject kann null sein; dafür braucht die Anzeige einen bewussten Ersatz.
• caseEvidence liefert Verknüpfungs-IDs, nicht fertige Evidence-Payloads. Detections werden über detectionRetrieveById mit dem exakt geschriebenen Argument iDs nachgeladen, Events über ihre unveränderten Resource Names. Asset- und Entity-Graph-Abhängigkeiten bleiben bis zur passenden Referenz- und Tenant-Prüfung offen. Detection-, Event-, Asset- und Entity-Graph-IDs sind nicht austauschbar; ein Entity-Graph-Einstieg für einen Case verwendet dessen UUID als INVESTIGATION, nicht die shortId.
• Case-Pagination verwendet Offset oder Cursor, nicht beides in einem Request. Für eine sich verändernde Liste Cursor bevorzugen und unverändert zurückgeben. keyFindings ist ein typisiertes Dokument und wird im Einzelabruf, nicht in der Case-Liste geliefert. Die bisherigen Filter overviewContains und escalated haben keinen direkten Ersatz; benötigte Funktionen vor dem Cutover ausdrücklich entscheiden.
• Es gibt kein deleteCase als Ersatz für REST-DELETE. Schliessen, gegebenenfalls mit dem vom Case-Typ verlangten Verdict, und anschliessendes optionales Archivieren sind separate Schritte. Bei providerverwalteten MDR-Cases sind die tatsächlich erlaubten Schreibfelder enger und vorab zu prüfen.

Ein Pilot muss dieselbe fachliche Frage im richtigen Tenant mit nachvollziehbaren IDs, vollständiger Pagination und ausgewerteten Fehlern beantworten. Zusätzliche GraphQL-Funktionen wie Kommentare, Dateien, Links, Regeln, Templates sowie Split/Merge sind eigene Erweiterungen, keine Voraussetzung für jeden Cutover. Fehlende Feldentsprechungen oder ungeklärte Historie bleiben ein offener Client-Entscheid; sie werden nicht mit einer angenommenen Gleichwertigkeit übergangen.

Geltungsbereich: XDR, MDR und Lizenzen

Eine Integration ersetzt weder eine XDR- noch eine MDR-Lizenz. XDR stellt Analysefunktionen bereit, mit denen ein eigenes Security-Team Daten im Threat Analysis Center und im Data Lake untersucht. MDR ergänzt dies um den verwalteten Sophos-Service. Welche Integrationen im Tenant auswählbar sind, hängt vom Sophos-Vertrag, vom Produkt, vom Integrationstyp und gegebenenfalls von der Lizenz des Drittprodukts ab.

Für längere Aufbewahrung oder eigene Datenquellen erklärt Sophos Next-Gen SIEM die Prüfung des optionalen Add-ons und das Retention-Inventar je Quelle.

Die oft zitierte Aussage, bestimmte Integrationen seien kostenlos, bedeutet nicht, dass der gesamte Marketplace kostenlos ist. Für MSP Flex gibt es separate Integration License Packs nach Kategorien wie Endpoint, Network, Email oder Firewall. Die bisherige MSP-Flex-Regel nannte mit einer XDR-Lizenz Sophos NDR, Sophos Cloud Optix, Microsoft Graph Security und die Microsoft 365 audit appliance ohne zusätzliches Integration License Pack. Diese Regel gilt ausdrücklich nur für MSP-Flex-Kunden. Cloud Optix ist darin heute nur noch ein historischer Eintrag: Sein End of Life am 30. September 2026 erlaubt keine neue produktive Planung mit diesem Dienst. Man prüft deshalb im eigenen Tenant und im Vertrag, was freigeschaltet ist, statt von einem pauschalen Gratisumfang auszugehen.

Auch die Gegenseite kann Lizenzen verlangen. Bei Microsoft 365 widersprechen sich die Sophos-Seiten: Die Übersichtsseite bezeichnet Management-Activity-Auditlogs als für alle Microsoft-365-Kunden verfügbar; die konkrete Einrichtungsseite verlangt jedoch Purview Audit (Standard oder Premium), eine dort aufgeführte Benutzerlizenz und aktiviertes Auditing. Für die Einrichtung gelten diese konkreten Voraussetzungen. Die von Graph Security V2 gelieferten Detections hängen zusätzlich vom Microsoft-Lizenzumfang und den verfügbaren Defender-XDR-Funktionen ab. Für Microsoft 365 Response Actions im Classic/TAC-Pfad nennt Sophos keine Microsoft-Lizenzanforderung; erforderlich sind jedoch ein Microsoft-365-Administrator und die weiter unten ausdrücklich als Classic aufgeführten Graph-Berechtigungen. Für Actions in der erweiterten Lösung gelten stattdessen die oben beschriebenen Voraussetzungen und die tatsächlich angeforderten Rechte der zweistufigen Autorisierung; die Classic-Liste definiert nicht den neuen Consent.

Cloud Optix nach dem End of Life: Telemetrie und CSPM getrennt behandeln

Sophos Cloud Optix erreichte am 30. September 2026 sein End of Life. Danach sammelt der Dienst keine neuen Daten, erzeugt keine Findings und leitet keine Telemetrie mehr an MDR oder XDR weiter. Am Prüfstand 11. Oktober 2026 ist die frühere Empfehlung, noch vor dem EOL zu exportieren und parallel umzuschalten, kein ausführbarer Zukunftsschritt mehr.

Man prüft jetzt, welche AWS-, Azure-, GCP- oder OCI-Umgebungen zuvor ausschliesslich über Cloud Optix angebunden waren und welche davon bereits eine direkte Verbindung zur erweiterten XDR-/MDR-Lösung besitzen. Diese direkten Cloud-Integrationen müssen je Plattform eingerichtet werden; das Produktupgrade erledigt dies nicht automatisch. Ohne geprüfte neue Verbindung darf für den Zeitraum nach dem 30. September keine lückenlose Telemetrieabdeckung behauptet werden. Für einen noch nicht umgestellten Tenant oder eine fehlende Produktkachel den Zustand mit dem Sophos-Konto- beziehungsweise Partnerteam klären.

Eine direkte Cloud-API-Integration ist nicht dasselbe wie ein in AWS, Azure oder GCP laufender Syslog Data Collector. Man wählt im Marketplace die Integration zum benötigten Cloud-Datenstrom, prüft die konkreten Quellberechtigungen und weist anschliessend Daten sowie die erwarteten Detections nach. Der Nachweis muss Cloud-Konto, Datenquelle und Zeitfenster erkennen lassen; eine grüne Verbindung allein reicht nicht.

Cloud Security Posture Management (CSPM) wird nicht übernommen: Zustandsbewertung von Cloud-Konfigurationen, Compliance-Benchmark-Berichte und Configuration-Drift-Findings sind kein Leistungsversprechen der neuen Telemetrie-Integrationen. Man dokumentiert diesen Bedarf getrennt und klärt Ersatz und verbliebene Vertragsansprüche mit dem Accountteam. Auch Cloud-Optix-Berichte, Findings-Historie, Compliance-Nachweise und Inventardaten werden nicht in das neue System migriert. Bereits vorhandene Exporte sichern und auf Vollständigkeit prüfen; eine nachträgliche Exportmöglichkeit oder Wiederherstellung ist hier nicht bestätigt.

Integrationstypen und benötigte Zugangsdaten

REST API

Eine API-Integration ruft Daten aus dem Cloud-Dienst des Herstellers ab oder sendet dort eine Response-Aktion. Der Einrichtungsassistent fragt je nach Produkt etwa Tenant- oder Organisations-ID, API-URL, Client-ID, Client Secret, Token oder Zertifikat ab. API-Integrationen benötigen keine Sophos-Appliance.

Einige Integrationen nehmen die Daten direkt im Assistenten entgegen. Andere fordern eine wiederverwendbare Integration Credential an. Ob ein Connector dies unterstützt, zeigt der Einrichtungsassistent durch die Auswahl einer vorhandenen oder die Anlage einer neuen Credential. Der Integration Credential Manager steht nur für einen begrenzten Teil der API-Integrationen zur Verfügung; seine Existenz bedeutet daher nicht, dass sich jedes Secret zentral wiederverwenden lässt.

Log collector

Die folgende Appliance-Beschreibung gilt für den Classic-SVA-Pfad. In der erweiterten XDR-Lösung sammeln XDR Data Collectors Syslog-Daten; sie haben eigene Ressourcen- und Netzwerkvorgaben. Die alten SVA-Mindestwerte dürfen nicht auf die neue VM übertragen werden. Die Migration provisioniert Konfigurationen, startet aber keinen einsatzbereiten Ersatz. SVA-Syslog-Cutover und XDR Data Collector Betrieb erklärt die Adressvarianten, ausgeschlossene Einstellungen und sichere Umschaltung. NDR wird dabei nicht automatisch mitmigriert.

Bei einer Log-Collector-Integration exportiert das Quellsystem Ereignisse per Syslog an eine Sophos appliance. Deren Log Collector verarbeitet die Daten und lädt sie in den Sophos Data Lake. Die Appliance läuft auf ESXi, Hyper-V, AWS oder Nutanix beziehungsweise auf geeigneter Dell-, NUC- oder OnLogic-Hardware. Für ESXi oder Hyper-V sind mindestens 4 CPUs, 16 GB RAM und 160 GB Speicher einzuplanen; unterstützt werden ESXi 6.7 Update 3 mit VM-Hardwareversion 11 oder neuer sowie Hyper-V unter Windows Server 2016 oder neuer. Sophos verwaltet die Betriebssystem- und Sicherheitsupdates der Appliance; darauf wird kein zusätzlicher Sophos- oder Antimalware-Agent installiert. Man dimensioniert bei hohem Datenvolumen oder mehreren Integrationen grösser und prüft vor der Freigabe DNS, Proxy sowie die benötigten Port- und Domainausnahmen. Anschliessend wird im Drittprodukt nicht ein beliebiger Syslog-Server, sondern die Verbindung zur Appliance eingetragen.

Mehrere Integrationen können dieselbe Appliance verwenden. Trotzdem müssen Protokoll, Port, Format und Quelle für jedes Produkt gemäss dessen Integrationsanleitung konfiguriert werden. Eine grüne Appliance allein beweist noch nicht, dass der richtige Ereignistyp ankommt.

Sophos-Produkte

Produkte wie Sophos Firewall oder Sophos NDR besitzen produktspezifische Einrichtungswege. Sophos NDR und Log-Collector-Integrationen benötigen eine Integrations-Appliance, aber nicht zwingend eine klassische VM. Eine reine REST-API-Integration benötigt keine Appliance. Man verwendet den Marketplace des betroffenen Tenants als Verfügbarkeitsprüfung: Die Produktkachel zeigt die dort angebotenen Methoden und öffnet den passenden Einrichtungsassistenten.

NDR-Arbeitslast und gemeinsame Appliance sicher abgrenzen

Die folgende gemeinsame Appliance-Topologie gilt für Classic SVA/TAC, nicht für den neuen XDR Data Collector. Dieser ersetzt den Syslog-Anteil; NDR bleibt eine separat betriebene Appliance-Arbeitslast und wird nicht auf den neuen Collector übertragen.

Pro Appliance ist nur eine Sophos-NDR-Integration zulässig. Dieselbe Appliance kann daneben mehrere appliance-basierte Drittanbieter-Integrationen als Log Collectors hosten. Man klappt deshalb unter Configured > Integration Appliances vor jeder Änderung den Appliance-Eintrag auf und prüft alle zugeordneten Integrationen. Weder der Wert Integrations noch ein grüner Appliance-Status ersetzt diese Prüfung.

Ein gezielter NDR-Neustart unterbricht den NDR-Sensor, während die Log Collectors weiterlaufen. Restart oder Shutdown der gesamten VM unterbricht dagegen NDR und alle Log Collectors auf dieser Appliance. Man plant solche Aktionen in einem Wartungsfenster, dokumentiert vorher den Zustand aller Arbeitslasten und prüft sie danach einzeln. Den Ablauf beschreibt Sophos NDR Appliance und Sensor sicher betreiben.

Delete im Appliance-Menü entfernt nicht lediglich eine einzelne Integration. Man löscht die Appliance nicht, solange ihr NDR oder ein Log Collector zugeordnet ist. Der Menüeintrag sagt zudem weder aus, dass die bereitgestellte VM entfernt wird, noch dass bereits aufgenommene Data-Lake-Daten gelöscht werden. Man klärt vor der Ausserbetriebnahme die Zuordnungen, die Datenaufbewahrung, den Abbau der Plattformressourcen, den Wiederherstellungsweg und die abschliessende Kontrolle. Bis dahin bleibt die Appliance bestehen.

Vor der Einrichtung

1. Man meldet sich als Admin oder Super Admin in Sophos Fusion an. Für die allgemeine Einrichtung nennt Sophos diese Rollen als Voraussetzung.
2. Man prüft im Drittprodukt, welche Lizenz, Administratorrolle, API-Funktion oder Syslog-Ausgabe erforderlich ist.
3. Man entscheidet, ob Data Ingest, Response Action oder beides benötigt wird. Eine Response-Integration liefert nicht automatisch die Telemetrie, auf der eine Untersuchung basiert.
4. Man legt für API-Zugriffe nach Möglichkeit eine dedizierte App beziehungsweise ein dediziertes Service-Konto an. Man vergibt nur die in der Produktanleitung verlangten Rechte und dokumentiert Besitzer, Ablaufdatum und Rotationsweg des Secrets.
5. Verlangt das Drittprodukt eine Quell-IP-Allowlist für administrative API-Aufrufe, ermittelt man zuerst die Central-Region unter My Environment > Installers: Man bewegt den Mauszeiger über einen Downloadlink unter Endpoint Protection oder Server Protection und liest die Region aus der angezeigten URL, zum Beispiel eu-central-1. Man erlaubt anschliessend nur die Adressen dieser Region aus der Tabelle unten. Diese Adressen sind die Quellen der Sophos-API-Aufrufe und keine ausgehenden Ziele der Integrations-Appliance.
6. Man prüft für eine Integrations-Appliance deren eigenen ausgehenden Netzwerkweg, DNS und gegebenenfalls Proxy gemäss den Appliance-Anforderungen.
7. Man plant ein reproduzierbares, ungefährliches Testereignis. Ein Login- oder Auditereignis eignet sich besser als ein echter Malwareversuch.

Quell-IP-Adressen für API-Allowlisting

Diese Tabelle zeigt den Classic-IP-Satz mit Prüfstand 14. September 2026. Sie ist von der aktuellen XDR-Allowlist weiter oben zu unterscheiden und kein alleiniger Nachweis für eine produktive Allowlist-Änderung.

Vor einem Change die Integrationsgeneration, Tenant-Region und den vollständigen benötigten IP-Satz gegen den aktuellen Sophos-Stand prüfen. Bei Abweichungen keine alten Werte übernehmen und keine Regionen kombinieren. Die Regionszuordnung und Änderung nach dem eigenen Freigabeprozess kontrollieren lassen, nur den benötigten Bereich zulassen und danach die betroffene Integration mit einer ungefährlichen API-Synchronisation oder einem Testereignis validieren. Ausgangszustand, Freigabe, Ergebnisse und Rückweg im Change dokumentieren.

Sophos bezeichnet derzeit sowohl die Zeile für São Paulo als auch die Zeile für Dubai mit sa-east-1. Man unterscheidet sie anhand des Tenant-Standorts und des IP-Satzes; Regionen werden niemals kombiniert. Man dokumentiert die freigegebene Liste im Change.

Integration im Marketplace hinzufügen

1. Man öffnet Threat Analysis Center > Integrations > Marketplace.
2. Man sucht nach Hersteller oder Produkt. Man verwendet bei ähnlichen Einträgen die Produktseite und prüft Kategorie, Produktname, Integrationstyp und Zweck. Cisco Meraki und Fortinet FortiAnalyzer werden beispielsweise sowohl als API- als auch als Log-Collector-Variante angeboten.
3. Man öffnet die gewünschte Integration.
4. Man wählt den benötigten Typ, zum Beispiel Data Ingest, und klickt Add Configuration.
5. Man folgt den Integration setup-Schritten. Bei API-Integrationen werden die Daten aus dem Quellsystem eingetragen oder ein OAuth-Consent erteilt. Bei Log-Collector-Integrationen wird eine Appliance erstellt oder ausgewählt und danach der Syslog-Export des Quellsystems auf diese Appliance gerichtet.
6. Falls Sophos bei der ersten Integration nach internen Domains und IP-Bereichen fragt, erfasst man nur die eigenen internen Bereiche. Diese Angaben kennzeichnen eigene Adressen, gruppieren zusammengehörige Alerts und vermeiden Drittanbieter-Lookups; sie sind nicht mit der Allowlist der Sophos-Quelladressen zu verwechseln.
7. Man speichert die Konfiguration und schliesst einen externen Consent-Dialog vollständig ab. Man notiert Integrationsname, Quell-Tenant, verantwortliche Person und Datum der nächsten Credential-Rotation.
8. Man öffnet Threat Analysis Center > Integrations > Configured. Die neue Konfiguration muss dort erscheinen. Hier lässt sie sich später überwachen oder bearbeiten; unter Connection Method ist auch erkennbar, ob für die Fehlersuche der API- oder Log-Collector-Pfad gilt.

FortiAnalyzer: API-Alerts sind nicht alle empfangenen Syslog-Ereignisse

Bei Fortinet FortiAnalyzer unterstützt der API-Connector Appliance und VM Subscription, nicht FortiAnalyzer Cloud. Er liest ausschliesslich von FortiAnalyzer erzeugte Alerts aus /eventmgmt/adom/<ADOM>/alerts; <ADOM> bezeichnet die passende administrative Domäne des Quellsystems. Ein von FortiAnalyzer lediglich empfangenes Syslog-Ereignis wird nicht automatisch zu einem solchen Alert. Sollen Syslog-Ereignisse aufgenommen werden, wird stattdessen die FortiAnalyzer-Log-Collector-Integration oder die Fortinet-Fortigate-Integration für die konkrete Quelle geprüft. Die Entscheidung fällt vor der Connector-Einrichtung, nicht erst bei einer vermeintlichen Datenlücke.

Der API-Connector entfernt nicht formatkonforme Daten und verwirft anschliessend bestimmte Alert-Typen: VPN-Tunnel-Meldungen (vpntunnel), blockierte Webanfragen an nicht bewertete Ziele, IP-/Port-Scanning-Meldungen, von SSL-Prüfung ausgenommene Verbindungen aufgrund Allowlist oder Adresse, Link-Monitor-Meldungen über herunter- oder hochgefahrene Interfaces, Warnungen zu vollem Memory Log sowie Disk-Quota-Alert/-Warning und blockierte unsichere SSL-Verbindungen. Ein fehlender solcher Alert ist daher nicht automatisch ein Authentisierungs- oder Transportfehler. Die Typzuordnung verwendet bei vorhandenem message einen Musterabgleich, andernfalls die Felder FTNTFGTattack, ad.subtype und cat; ohne Treffer wird das message-Feld bereinigt. Ein empfangener Alert-Titel ist nicht automatisch eine vollständige MITRE-Zuordnung.

Für die Abnahme ein harmloses, genehmigtes Ereignis wählen, das nachweislich einen FortiAnalyzer-Alert erzeugt, zum Beispiel eine im eigenen Event-Handler dafür vorgesehene Konfigurationsänderung. Zuerst Alert, ADOM und Zeitpunkt im FortiAnalyzer belegen und sicherstellen, dass Format und Alert-Typ nicht verworfen werden. Danach denselben Alert über den für diesen Connector bestätigten Sophos-Suchweg im richtigen Tenant nachweisen. Ein beliebiger Test-Login oder eine gesendete Syslog-Zeile ohne FortiAnalyzer-Alert ist kein gültiger API-Aufnahmetest. Fehlt der erwartete Alert, zuerst Alert-Erzeugung, ADOM, Format und Typfilter prüfen, danach Credentials und Verbindung; eine Sophos-Detection oder ein Case ist auch bei erfolgreicher Aufnahme nicht garantiert.

Funktion kontrollieren und testen

Eine gespeicherte Konfiguration ist noch kein Funktionsnachweis. Man prüft nacheinander Verbindung, Datenfluss und fachlichen Inhalt:

1. Verbindungsstatus: Man öffnet den Eintrag unter Configured beziehungsweise bei einer Appliance deren Status. Bei Log Collectors bedeutet Rot, dass die Integration nicht arbeitet, Gelb, dass sie mit Fehlern arbeitet, und Grün, dass Ereignisse ohne sichtbare Probleme empfangen und verarbeitet werden.
2. Definiertes Testereignis: Man erzeugt im Quellsystem ein harmloses Ereignis, das die jeweilige API oder Syslog-Kategorie sicher erfasst, etwa eine administrative Änderung oder einen Test-Login. Man hält Uhrzeit, Benutzer und Quelle fest.
3. Data-Lake-Nachweis: Man sucht nach Ablauf der produktspezifischen Verzögerung in Threat Analysis Center > Live Discover. Man verwendet die in der produktspezifischen Anleitung dokumentierte Live-Discover-Kategorie oder Abfrage; wenn Sophos für den Connector keine solche Abfrage dokumentiert, darf dieser allgemeine Ablauf keinen universellen Query-Nachweis versprechen. Das Live-Discover-Runbook erklärt Abfrage, Data-Lake-Grenzen und Ergebnisprüfung. Man prüft Zeitstempel, Tenant, Benutzer und Ereignistyp. Ein einzelner Datensatz beweist die Verbindung; mehrere aktuelle Datensätze über einen angemessenen Zeitraum belegen den laufenden Datenfluss.
4. Detection-Grenze: Nicht jedes eingelesene Ereignis erzeugt eine Detection oder einen Case. Data Ingest macht Daten analysierbar; Detections entstehen nur, wenn eine passende Erkennungslogik greift. Man testet deshalb die Aufnahme zuerst im Data Lake und erwartet nicht zwangsläufig einen Alert.
5. Response Action: Man verwendet ein genehmigtes Testkonto und dokumentiert den Ausgangszustand. Für Microsoft 365 eignet sich Block user sign-in mit anschliessendem Allow user sign-in als reversibler Test; Revoke all current sessions ist nicht reversibel. Man beachtet zudem, dass Entra Connect Sync ein gesperrtes Hybridkonto später wieder aktivieren kann, die MDR-Response-Einstellung Aktionen der Sophos-Analysten begrenzt und Namen einzelner Inbox Rules bei Response Actions gross-/kleinschreibungssensitiv sind.

Die Health Alerts sind kein Soforttest. Der 24-Stunden-Zeitraum beginnt mit der ersten Fehlermeldung und führt nur dann zu einem Alert mittlerer Severity, wenn der Fehler ununterbrochen anhält. Ein grüner Status oder das Bestätigen des Alerts setzt den Countdown zurück. Bleibt das Problem bestehen, erscheint der Alert anschliessend einmal alle 30 Tage erneut.

Microsoft 365: drei getrennte Integrationen

„Microsoft 365 anbinden“ ist kein einzelner Schalter. Die folgende Tabelle beschreibt die getrennten Aufgaben im Classic/TAC-Marketplace, einschliesslich der dortigen Response-Actions-Grenze. Für die erweiterte Lösung gilt der oben beschriebene Microsoft-Graph-API-Actions-Ablauf mit eigenen Verbindungen und neuem Consent; die Classic-Beschränkung auf eine Umgebung ist keine Grenze dieses neuen Ablaufs.

Für Response Actions im Classic/TAC-Pfad nennt Sophos die Microsoft-Graph-Berechtigungen User.ManageIdentities.All, User.EnableDisableAccount.All, User.RevokeSessions.All, MailboxSettings.Readwrite und User.Read. Bei MDR begrenzt die gewählte MDR-Antwortoption weiterhin, ob Analysten ohne Freigabe handeln dürfen. In einer hybriden Entra-ID-Umgebung kann Microsoft Entra Connect Sync eine in Central blockierte Anmeldung später wieder aktivieren.

Beispiel: Management Activity sicher anbinden

1. Man stellt in Microsoft 365 sicher, dass Auditing aktiv ist. Ein Microsoft-365-Administrator muss die Verbindung autorisieren.
2. Man öffnet Threat Analysis Center > Integrations > Marketplace und wählt Microsoft - Office 365 Management Activity API.
3. Man klickt unter Data Ingest (Security Alerts) auf Add Configuration.
4. Man prüft den Auditing-Hinweis, klickt Save and continue und danach in Connect to Microsoft 365 auf Proceed.
5. Man meldet sich mit dem vorgesehenen Microsoft-Administratorkonto an, prüft die verlangten Berechtigungen und bestätigt mit Accept. Man schliesst die Bestätigung mit Close.
6. Man kontrolliert den Eintrag in Sophos Fusion. Unter Live Discover > Query muss die Kategorie Microsoft 365 audit data erscheinen. Man erzeugt danach ein nachvollziehbares Auditereignis und sucht es mit einer bereitgestellten Abfrage.

Microsoft garantiert keine feste Zeit, in der einzelne Ereignisse im Auditlog erscheinen. Eine verzögerte Zeile ist deshalb nicht automatisch ein Integrationsfehler. Nach dem erstmaligen Einschalten des Auditings können bis zu 12 Stunden vergehen, bevor Daten sichtbar werden.

Für Graph Security V2 erfolgt die erste Synchronisation ungefähr fünf Minuten, nachdem die Daten im Microsoft Defender Security Center verfügbar sind. Muss der Alerts-and-Incidents-Dienst zuerst provisioniert werden, kann allein dieser Microsoft-Schritt etwa eine Stunde beanspruchen.

Integration deaktivieren oder zurückbauen

Es gibt keinen einheitlichen Disable-Schalter für alle Integrationsarten. Die verfügbaren Aktionen unterscheiden sich nach Produkt und Connection Method. Eine universelle Schaltfläche darf deshalb nicht vorausgesetzt werden:

1. Man öffnet Threat Analysis Center > Integrations > Configured, wählt die Konfiguration und dokumentiert Status, Namen, Quell-Tenant, Appliance und Credential.
2. Man stoppt bei einer API-Integration zuerst kontrolliert die Datenaufnahme beziehungsweise nutzt eine angebotene Disable- oder Delete-Aktion, falls die konkrete Produktseite sie bereitstellt. Man widerruft danach im Quellsystem das OAuth-Consent oder deaktiviert die dedizierte App beziehungsweise das Token. Bei Response Actions verhindert dieser Schritt weitere Aktionen aus Central.
3. Man entfernt bei einer Log-Collector-Integration die Syslog-Zielkonfiguration im Quellsystem. Man löscht eine gemeinsam genutzte Sophos-Appliance nicht, solange andere Integrationen sie verwenden.
4. Man entfernt die Konfiguration in Central nur, wenn Aufbewahrungs-, Audit- und Change-Vorgaben erfüllt sind. Das Entfernen einer Konfiguration garantiert nicht, dass bereits aufgenommene Data-Lake-Daten gelöscht werden; deshalb klärt man Aufbewahrung und Löschung vorab anhand der für den Tenant geltenden Data-Lake- und Compliance-Vorgaben.
5. Man prüft, dass keine neuen Ereignisse mehr eintreffen und keine unerwarteten Response-Aktionen möglich sind. Man entfernt anschliessend nicht mehr benötigte Secrets, Zertifikate, Service-Konten und Allowlist-Einträge.

Für einen kurzen Wartungsunterbruch stoppt man bei einer Log-Collector-Integration den Syslog-Export, ohne eine gemeinsam genutzte Appliance zu löschen. Bei API- und Response-Integrationen darf ein Credential nur dann als Wartungspause gesperrt werden, wenn die Reaktivierung derselben Konfiguration zuvor nachweislich getestet wurde; andernfalls ist ausschliesslich der für den Connector angebotene Disable-, Delete- oder Reconnect-Weg zu verwenden. Ein gesperrtes oder abgelaufenes Credential ist kein universeller Rollback und erzeugt Synchronisationsfehler.

Typische Fehler systematisch eingrenzen

API-Integration synchronisiert nicht

Man öffnet Configured, prüft Connection Method und liest die konkrete Fehlermeldung. Invalid credentials, insufficient permission und expired credentials werden zuerst im Drittprodukt behoben: ID, Secret, Tokenlaufzeit, Zertifikat und API-Rechte prüfen. Network not reachable und invalid domain verlangen zusätzlich DNS-, Proxy-, Firewall- und Dienststatuskontrollen. Bei request throttling hat der Anbieter die API begrenzt; wiederholtes sofortiges Speichern verschärft den Fehler möglicherweise. Bei Microsoft steht HTTP 401 für ungültige Authentisierung; 429 und 509 weisen auf Drosselung hin.

Log Collector bleibt rot oder gelb

Rot bedeutet ausgefallen, Gelb laufend mit Fehlern. Man prüft VM-Ressourcen, Netzwerk und DNS, ausgehende Erreichbarkeit sowie den Syslog-Pfad vom Quellsystem zur Appliance. Die Meldung no events received since last container restart weist auf fehlende Syslog-Ereignisse seit dem Containerstart hin; no received events in last 10 mins kann einen unterbrochenen Export oder schlicht eine selten sendende Quelle bedeuten. Bei Uploadfehlern puffert die Appliance Daten auf Disk. Bleibt der Upload blockiert und wird der Speicher voll, können ältere Daten verworfen werden.

Microsoft 365 liefert keine Daten

Für Management Activity müssen Microsoft-365-Auditing und bei Office 365 Management APIs die Eigenschaft Enabled for users to sign-in? = Yes aktiv sein. Man berücksichtigt die Anlaufzeit von bis zu 12 Stunden nach dem Einschalten des Auditings. Bei Graph Security V2 prüft man Defender-XDR-Zugriff, Consent, Provisionierung des Alerts-Dienstes und den verfügbaren Microsoft-Lizenzumfang. Die alte Graph Security API ist keine Rückfalloption mehr.

Kein Health Alert trotz Ausfall

Man kontrolliert zuerst, ob es sich um eine Data Ingest-Integration handelt und ob der Fehler seit der ersten Fehlermeldung bereits 24 Stunden ununterbrochen besteht. Ein zwischenzeitlich grüner Status oder das Bestätigen des Alerts setzt den Countdown zurück. Standardmässig erhalten alle Central-Administratoren die E-Mail; eigene Notification Rules können diese Verteilung verändern.

Sicherheits- und Betriebsregeln

• Man verwendet dedizierte Apps und Secrets statt persönlicher Administratorzugänge.
• Man erteilt nur die von der konkreten Integration geforderten API-Rechte. Response-Integrationen benötigen naturgemäss schreibende Rechte und verdienen eine strengere Freigabe als reine Datenaufnahme.
• Man speichert Secrets nicht in Tickets, Screenshots oder KB-Artikeln. Man hält Besitzer und Ablaufdatum im Passwort- oder Secret-Management fest.
• Man plant Credential-Rotation vor dem Ablauf. Sophos meldet abgelaufene Credentials als Synchronisationsfehler.
• Man erlaubt Sophos-IP-Adressen nur, wenn der Anbieter eine Quell-Allowlist verlangt, und verwendet die Liste der tatsächlichen Central-Region.
• Man aktiviert Health-Benachrichtigungen für ein verantwortliches Team. Man beachtet beim Erstellen einer Custom Notification Rule, dass dadurch der Standardversand aller E-Mail-Alerts an alle Administratoren abgeschaltet wird und notwendige Regeln separat nachgebildet werden müssen.
• Man dokumentiert für jede Integration Datenquelle, Zweck, Datenklassifikation, Aufbewahrung, Rechte, Test, Owner und Rückbauweg.

Abnahmekriterien

Die Integration ist erst abgeschlossen, wenn sie unter Configured mit der erwarteten Methode erscheint, ein definiertes Testereignis im vorgesehenen Ziel nachweisbar ist, Zeitstempel und Quell-Tenant stimmen und ein Owner die Credential-Rotation sowie Health Alerts übernimmt. Für Response Actions gehört zusätzlich ein genehmigter, dokumentierter Test zur Abnahme; nur reversible Aktionen werden dabei zum Ausgangszustand zurückgeführt, irreversible Aktionen wie der Session-Widerruf dürfen nicht als Rollback-Test verwendet werden. Man hält unvermeidbare Verzögerungen, etwa beim Microsoft-365-Auditing, im Betriebsprotokoll fest.

Häufige Fragen

Landen mit jeder Integration Daten im Sophos Data Lake?

Nein. Data Ingest sendet Daten in den Data Lake. Response Action ermöglicht eine Aktion im Drittprodukt. Manche Produkte bieten nur einen Typ, andere getrennte Konfigurationen für beide Richtungen.

Sind Drittanbieter-Integrationen mit XDR kostenlos?

Nicht pauschal. Sophos nennt für MSP Flex bestimmte Integrationen der Kategorie Sophos XDR, die mit XDR ohne zusätzliches Integration License Pack nutzbar sind. Andere Kategorien benötigen bei Flex passende Packs. Zusätzlich können Lizenzen des Drittanbieters erforderlich sein.

Warum sehe ich Daten, aber keine Detection?

Aufnahme und Erkennung sind verschiedene Stufen. Ein Data-Ingest-Connector kann Ereignisse korrekt in den Data Lake schreiben, ohne dass jedes Ereignis eine Sophos-Detection oder einen Case auslöst. Man prüft den Rohdatenfluss zuerst mit der vorgesehenen Live-Discover-Abfrage.

Kann ich dieselbe Appliance für mehrere Syslog-Integrationen nutzen?

Ja, im Classic-SVA-Pfad erlaubt Sophos mehrere Drittintegrationen sowie eine Sophos-NDR-Integration auf derselben Appliance. Jede Quelle muss trotzdem mit den korrekten Verbindungs- und Formatangaben eingerichtet werden. Der neue XDR Data Collector ist dagegen der Syslog-Ersatz und übernimmt oder hostet diese NDR-Arbeitslast nicht. Für den Wechsel gilt der oben verlinkte Collector-Migrationsablauf; NDR wird separat nach dem NDR-Betriebsrunbook betrieben.

Warum ist die Microsoft-365-Response-Integration nicht genug?

Sie stellt Aktionen bereit, nimmt aber nicht automatisch Audit- oder Defender-Alerts auf. Man ergänzt deshalb Microsoft 365 Management Activity und Microsoft Graph Security API V2, damit Detections und Untersuchungskontext vorhanden sind.

Löscht das Entfernen einer Integration historische Data-Lake-Daten?

Das Entfernen garantiert keine sofortige Löschung bereits aufgenommener Daten. Man behandelt das Entfernen daher als Stopp des künftigen Datenflusses und klärt Aufbewahrung oder Löschpflichten separat, bevor ein verbindlicher Löschzeitpunkt zugesagt wird.