Sophos Fusion Endpoint strukturiert in Betrieb nehmen

Sophos Fusion Endpoint wird nicht allein mit einem Installer eingeführt. Zu einer belastbaren Einführung gehören Administratorzugriff, Geräte- und Benutzeridentitäten, ein passender Softwareumfang, Policies, Netzwerkzugriff, ein repräsentativer Pilot sowie klar geregeltes Monitoring und Response.

Dieser Artikel ist die Orientierung für das Gesamtprojekt. Die konkreten Installations-, Policy- und Troubleshooting-Schritte stehen in den jeweils verlinkten Runbooks.

Der Ablauf auf einen Blick

1. Scope, Verantwortliche und Erfolgskriterien festlegen.
2. Central-Zugang und Administratorrollen absichern.
3. Lizenz, Agent Mode und unterstützte Plattformen prüfen.
4. Identitäten, Gruppen und Policy-Modell entwerfen.
5. Netzwerkpfad und Updateversorgung vorbereiten.
6. Windows und macOS auf repräsentativen Geräten sowie Linux im getrennten Server-Protection-Track pilotieren.
7. Schutz, Kommunikation, Events und Rückbau technisch abnehmen.
8. Erst danach in kontrollierten Wellen erweitern und den Regelbetrieb übernehmen.

Ein Wechsel in die nächste Phase erfolgt nur, wenn die vorherige Phase ein dokumentiertes Ergebnis besitzt. «Der Installer lief durch» ist noch keine Betriebsabnahme.

Direkte Wege durch die Inbetriebnahme

Wer zunächst nur installieren will, kann direkt zum passenden Plattformpfad springen. Für eine vollständige Einführung beginnt der Weg bei den Systemanforderungen und Lifecycle-Grenzen sowie den Netzwerk- und Proxy-Anforderungen. Gehört macOS zum Scope, kommen die macOS-Berechtigungen hinzu. Für Benutzer und Gruppen kann Microsoft Entra ID als Quelle dienen; Active Directory kann zusätzlich Geräte und Gerätegruppen liefern.

Administratorzugang vor dem Rollout absichern

Der Administratorzugang beginnt bei MFA, Passkeys und föderierter Anmeldung. Die konkrete Föderation wird je nach Identity Provider mit Microsoft Entra ID, OpenID Connect oder Okta beziehungsweise AD FS umgesetzt. Für RBAC werden zuerst die tenantweiten Administrationsrollen und danach die Endpoint-spezifischen Rollen und Berechtigungen passend zur Aufgabe begrenzt.

Installation nach Plattform und Verteilweg

Für einen kleinen Pilot oder einzelne Geräte führen die manuellen Anleitungen durch die Installation unter Windows und macOS. Ein automatisierter Windows-Rollout wird im Deployment-Runbook für Kommandozeile und Softwareverteilung vorbereitet; vorgefertigte virtuelle Maschinen benötigen zusätzlich das Verfahren für VDI-Gold-Images. Für Macs beschreibt der Jamf-Pro- und MDM-Pfad die zentrale Verteilung einschliesslich der benötigten Profile.

Linux ist dabei keine weitere Variante des Windows-/macOS-Endpoint-Installers. Sophos Fusion (ehemals Sophos Central) behandelt Installation, Skriptverteilung und Gold Images als Sophos Protection for Linux beziehungsweise Server Protection; der eigenständige Ablauf steht unter Sophos Protection for Linux installieren und verteilen.

Schutzfunktionen gezielt konfigurieren

Die Baseline wird nicht durch wahlloses Aktivieren aller Schalter verbessert. Die Threat-Protection-Einstellungen ordnen unter anderem HTTPS-Entschlüsselung, deren Datenschutzfolgen und die zugehörigen Ausnahmen ein. Produkt- oder anwendungsspezifische Scan-Ausnahmen werden so eng und nachvollziehbar wie möglich gesetzt. Ob zusätzliche zeitgesteuerte Prüfungen nötig sind und wie sie geplant werden, erklärt das Runbook zu Scheduled Scans.

Für die Benutzer- und Gerätekontrollen gibt es getrennte Entscheidungs- und Konfigurationspfade: Web Control für Websites und Kategorien, Application Control für Anwendungen, Peripheral Control für angeschlossene Windows- und macOS-Geräte sowie Data Loss Prevention für Datenkontrollregeln. Wartungsfenster, Softwarestände und Infrastruktur für die Verteilung werden separat unter Updates, Update Cache und Message Relay festgelegt.

XDR- und MDR-Integrationen optional erweitern

Bei passender XDR- oder MDR-Lizenz kann der Tenant Daten aus weiteren Sophos- und Drittprodukten zusammenführen. Das Central-weite Runbook XDR-Integrationen einrichten und prüfen führt durch Auswahl, Lizenzgrenzen, Anbindung und Funktionskontrolle; es ist keine Endpoint-Schutzrichtlinie.

Offene MDR-Fragen vor der Bereitstellung klären

Die MDR-Sensor-Berechtigung und der Windows-Installer-Produktwert mdr sind nicht abschliessend geklärt. Die offizielle MDR-Installationshilfe nennt für XDR Sensor noch MDR Essentials, die Service-Übersicht dagegen MDR und MDR Plus. Daraus lässt sich keine Berechtigung jeder aktuellen Stufe ableiten. Zudem verwendet die MDR-Windows-Anleitung mdr, während die Windows-CLI-Produktliste diesen Wert nicht aufführt. Das beweist weder dessen Ungültigkeit noch die Gleichwertigkeit von xdr oder xdrsensor; der Wert wird nicht eigenmächtig ersetzt.

Vor einer MDR-Sensor-Bereitstellung werden Vertragsstufe/SKU, aktive Lizenz im richtigen Tenant, Plattform und vorgesehener Installationsweg mit Sophos oder dem zuständigen Partner bestätigt. Bei Unklarheit bleibt dieser Bereitstellungsschritt gestoppt; für den Windows-Produktwert wird eine schriftliche Bestätigung zur eingesetzten Installer-Version und zum resultierenden Softwareumfang eingeholt. Ein sichtbarer Schalter ist kein Berechtigungsnachweis. Bereits verwaltete Geräte werden nach Agent Mode und Software prüfen kontrolliert; Endpoint-Installation und grüner Health State allein bestätigen keinen betriebsbereiten MDR-Service.

Zustand und Berichte

Nach dem Rollout zeigt die Protection Overview mit Events und Reports, ob Schutzstatus und Ereignisfluss plausibel sind. Der Account Health Check ergänzt diese Sicht um Abweichungen von Sophos-Empfehlungen, ersetzt aber weder Pilotabnahme noch fachliche Tests. Wiederkehrende Empfänger, Zeitpläne und fehlgeschlagene Zustellungen werden über geplante Reports eingerichtet und überwacht.

Wenn Installation oder Betrieb scheitern, liefert Endpoint Self Help und SDU die lokale Diagnose und die erforderlichen Protokolle. Anschliessend kann ein Sophos Supportticket mit verwertbaren Angaben eröffnet werden. Ein Partnerzugriff wird nicht improvisiert, sondern über Partner Assistance und zeitlich kontrollierte Remote Assistance freigegeben und wieder entzogen.

1. Auftrag und Zuständigkeiten klären

Vor der ersten Installation wird festgehalten, welche Geräte und Betriebssysteme zum Projekt gehören, welche Systeme ausdrücklich nicht dazugehören und wer Änderungen freigibt. Mindestens folgende Rollen müssen organisatorisch besetzt sein:

• Tenant- und Rollenverantwortung,
• Endpoint- und Policy-Verantwortung,
• Netzwerk- und Proxy-Verantwortung,
• Verantwortliche für Alerts und Sicherheitsvorfälle,
• Anwendungsverantwortliche für Pilot und Abnahme,
• Stellvertretung für kritische Zugänge und Entscheidungen.

Dazu kommen messbare Erfolgskriterien: Das Gerät erscheint im richtigen Tenant und in der richtigen Gruppe, erhält den vorgesehenen Agent Mode und die erwarteten Policies, meldet einen gesunden Zustand und liefert die geplanten Testereignisse. Für einen Fehlschlag sind Rollback, Supportweg und Entscheidungsbefugnis vorab benannt.

2. Tenant und Administratorzugriff absichern

MFA wird für alle Administratoren eingerichtet. Weitreichende Rechte werden nicht für die Tagesarbeit verwendet; Rollen werden nach Aufgabe vergeben und regelmässig überprüft. Wiederherstellung und Stellvertretung werden getestet, statt erst bei einem verlorenen Anmeldegerät improvisiert zu werden.

Die Detailentscheidungen stehen in Sophos Fusion Anmeldung mit MFA und IdP absichern und Sophos Fusion Endpoint Rollen und Berechtigungen planen.

3. Produktumfang und Plattformgrenzen bestimmen

Vor dem Rollout werden Lizenz, Gerätetyp, Betriebssystem und gewünschter Agent Mode gemeinsam geprüft. Welche Modi und Zusatzprodukte im eigenen Tenant sichtbar sind, hängt vom tatsächlichen Vertrag und von der Plattform ab; aus einem Screenshot oder einer allgemeinen Produktseite wird deshalb keine Verfügbarkeit abgeleitet.

Der Modus Endpoint steht für Sophos Endpoint-Schutz, XDR ergänzt die vorgesehenen Detection-and-Response-Funktionen und XDR Sensor ist kein eigenständiger Malware-Schutz. Ein Sensor-Konzept benötigt weiterhin ein separat betriebenes Schutzprodukt. Auswahl, Wechsel und Kontrolle erklärt Sophos Endpoint Agent Mode und Software verwalten; die kaufmännischen und technischen Grenzen stehen unter Sophos Fusion Endpoint-Lizenzen verstehen.

Windows und macOS erhalten eigene Pilotpfade. Vor jedem Plattformentscheid werden die aktuellen Systemanforderungen und Retirement-Hinweise geprüft. Das zugehörige Verfahren beschreibt Sophos Endpoint Systemanforderungen und Lifecycle planen.

Linux Runtime Detection Profiles gehören fachlich zum Schutz von Linux-Workloads und Cloud-Native-Umgebungen. Ihre Policy-Auswahl und Sensorbereitstellung werden nicht beiläufig in einen Windows-/macOS-Endpoint-Rollout aufgenommen, sondern als eigener Workload-Track mit den aktuellen Sophos-Voraussetzungen geplant.

Der Profil-Lifecycle beginnt unter My Products > Global Settings > Protection and Remediation > Linux Profiles. Create Profile legt Version 1 an; Profile Name, Content Version und optional Change Description dokumentieren den Stand. Danach werden Regeln auf den Tabs Detection Analytics, Smart Policy und BETA Ransomware gezielt ein- oder ausgeschaltet. Ein neues oder geändertes Profil wird zuerst einer Linux Runtime Detection Policy für Pilotserver zugewiesen und anhand eines erwarteten Test-Alerts geprüft. Create New Version erhält die Historie für spätere Anpassungen. Duplicate klont die neueste Version als eigenständiges Profil; Änderungen und Zuweisungen der Kopie wirken nicht auf das Quellprofil zurück. Ein aktives Profil kann erst gelöscht werden, nachdem es aus allen zugewiesenen Policies entfernt wurde.

Bei der erweiterten Abstimmung helfen die Filter Category, Enabled, Modified und Configurable. Hide filters blendet Filter nur aus; erst Clear All entfernt sie. Allow-/Block-List-Einträge gelten jeweils für die ausgewählte Regel. Für Sophos Protection for Linux wird aktualisierter SophosLabs-Content automatisch übernommen; beim Sophos Linux Sensor muss der Content bewusst aktualisiert werden. Eine über Export Latest Version exportierte YAML-Datei enthält nur die eigenen Abweichungen vom Standard und ist keine vollständige runtimedetections.yaml. Für den Sophos Linux Sensor werden diese Abweichungen nur in die vorhandene Datei übernommen; bearbeitet werden ausschliesslich Felder und Datentypen, die das Schema der eingesetzten Content-Version unterstützt. Vor dem Pilot stoppen konkrete Fehler den Rollout: ungültige YAML-Syntax oder Einrückung, unbekannte Schlüssel, falsche Datentypen, fehlende Pflichtfelder oder ungültige Regelwerte. Erst nach erfolgreicher Parser- und Schema-Validierung wird die Datei versioniert, auf Pilotservern ausgerollt und mit Alert- und Runtime-Kontrolle geprüft. Bei Problemen wird die vorherige Profilversion erneut zugewiesen beziehungsweise die vorherige validierte Sensor-Konfiguration wiederhergestellt.

4. Identitäten, Gruppen und Policies entwerfen

Benutzer-Policies folgen einer Person, Computer-Policies einem Gerät. Daher wird zuerst festgelegt, aus welcher autoritativen Quelle Benutzer und Gruppen stammen und wie doppelte oder veraltete Identitäten vermieden werden. Die Umsetzung erklärt Sophos Fusion Endpoint Benutzer und Gruppen verwalten.

Ein wartbares Gerätemodell beginnt typischerweise mit wenigen klaren Gruppen:

• Pilotgeräte mit aktiv betreuten Benutzern,
• produktive Standardgeräte,
• kritische oder technisch abweichende Geräte,
• befristete Ausnahmen,
• Testgeräte für neue Softwarestände.

Für jeden Policy-Typ gilt die erste passende aktive Policy. Baseline, Reihenfolge und effektive Zuweisung werden deshalb vor dem Massenrollout geprüft. Das Löschen einer Policy lässt sich in Central nicht rückgängig machen: Einstellungen und Zuweisungen werden vorab exportiert oder dokumentiert und die betroffenen Geräte identifiziert. Sophos Fusion Endpoint-Richtlinien richtig aufbauen führt durch dieses Modell.

Schutz- und Kontrollfunktionen werden nicht pauschal ein- oder ausgeschaltet. Threat Protection, Web, Applications, Peripherals, DLP, DNS Protection, Updates, Tamper Protection, Data Collection und Response werden nach Lizenz, Plattform und Geschäftsbedarf bewertet. Neue Kontrollen beginnen dort, wo es möglich und sinnvoll ist, in einer kleinen Pilotgruppe. Ausnahmen benötigen Grund, Owner, begrenzten Scope und Prüftermin.

5. Netzwerk und Updates vor der Installation prüfen

Der Endpoint muss die erforderlichen Sophos-Dienste über den tatsächlich verwendeten Geräte- und Dienstkontext erreichen. Ein erfolgreicher Browseraufruf des Administrators beweist nicht, dass Installation, Agentkommunikation und Updates über Proxy, TLS-Inspection oder segmentierte Netze funktionieren.

Vor dem Pilot werden daher DNS, HTTPS, Proxy-Authentisierung, Zertifikatsprüfung und die vorgesehenen Fallback-Wege getestet. Die aktuelle Verbindungsreihenfolge und die dynamischen Sophos-Ziele stehen in Sophos Endpoint Netzwerk- und Proxy-Anforderungen.

Update-Bandbreite, Softwarepakete, Wartungsstufen, Update Cache und Message Relay sind ein eigener Betriebsentscheid. Die globale Bandbreiteneinstellung ersetzt weder eine Kapazitätsplanung noch einen Pilot. Details und Ausfallszenarien erklärt Sophos Endpoint Updates, Cache und Message Relay.

6. Einen repräsentativen Pilot ausrollen

Unter My Environment > Installers wird der zum vorgesehenen Tenant und Zweck passende Installer bezogen. Installer werden wie Zugangsmaterial behandelt und nur über kontrollierte Verteilwege bereitgestellt.

Im Bereich Endpoint stehen die Installer für Protection, ZTNA und Device Encryption bereit. Die vollständigen Windows- und macOS-Installer enthalten die Endpoint-Produkte, die von der Lizenz des Tenants abgedeckt sind; mit Choose Components lässt sich der benötigte Umfang vor dem Download gezielt auswählen. Dieser Endpoint-Installer gilt nicht für Linux, das wie oben beschrieben zum getrennten Server-Protection-Track gehört.

Soll DNS Protection for endpoints im Rahmen von Workspace Protection genutzt werden, gilt dieser Handoff ausschliesslich für unterstützte Windows-Endpunkte; macOS und Windows Server sind nicht eingeschlossen. Auf diesen Windows-Endpunkten ist der installierte Endpoint-Agent nur die gemeinsame Voraussetzung. Die DNS-Komponente und ihre eigene Policy werden anschliessend nach dem separaten Runbook Sophos DNS Protection für Endpoints konfigurieren eingerichtet und geprüft; sie werden nicht als allgemeine Endpoint-Schutzrichtlinie in diesen Ablauf übernommen.

Die plattformspezifischen Abläufe werden nicht vermischt:

• Windows: Sophos Fusion Intercept X installieren
• macOS: Sophos Fusion Endpoint installieren
• automatisierter Windows-Rollout: Sophos Endpoint unter Windows automatisiert ausrollen

Der Pilot enthält nicht nur unkomplizierte IT-Notebooks. Er bildet verwendete Betriebssystemstände, Netzwerksegmente, Homeoffice oder VPN, geschäftskritische Anwendungen sowie vorhandene Security-, Backup-, DLP- und Verschlüsselungssoftware ab. Änderungen werden zuerst auf wenigen Geräten beobachtet; eine zeitliche Welle allein ersetzt keine technische Abnahme.

7. Pilot technisch abnehmen

Ein Pilotgerät ist freigegeben, wenn alle vorgesehenen Kontrollen nachvollziehbar bestanden sind:

1. Der lokale Agent meldet einen gesunden Zustand.
2. Das Gerät erscheint im richtigen Tenant und in der geplanten Gruppe.
3. Agent Mode und installierte Komponenten entsprechen der freigegebenen Planung.
4. Auf der Geräteseite sind die erwarteten Policies effektiv.
5. Last Active, Events und Updates entwickeln sich plausibel.
6. Ein freigegebener Schutztest erzeugt das erwartete Event oder den erwarteten Alert.
7. Fachanwendungen, Netzwerkwechsel und ein notwendiger Neustart wurden geprüft.
8. Alert-Empfang, Triage und Eskalation funktionieren.
9. Deinstallation oder anderer definierter Rückweg wurde auf einem Testgerät verifiziert.

Sichere Tests beschreibt Sophos Endpoint Schutzfunktionen sicher testen. Bleibt ein Gerät ungesund, wird nicht blind neu installiert; Sophos Endpoint Alerts und Account Health bearbeiten und Sophos Endpoint Installationsfehler systematisch beheben führen zur passenden Diagnose.

Der Account Health Check ist dabei eine zusätzliche Kontrollsicht. Er findet bestimmte Abweichungen von Sophos-Empfehlungen, beweist aber weder die fachliche Funktion einer Anwendung noch die vollständige Sicherheit des Tenants. Automatische Korrekturen können viele Geräte oder Policies betreffen und werden als Change behandelt. Die Einordnung steht in Sophos Fusion Account Health Check richtig nutzen.

8. Response- und Forensikbereitschaft bewusst entscheiden

Vor dem breiten Rollout ist geklärt, wer Alerts übernimmt, wann ein Gerät isoliert wird und welche Daten für Investigation und Support erhoben werden dürfen. Forensic Snapshots erfassen Aktivitätsdaten eines Geräts; Speicherung, Export, optionale Übertragung in einen eigenen S3-Bucket und Zugriff darauf benötigen daher eine bewusste Sicherheits- und Datenschutzentscheidung.

Forensic Snapshots erstellen, aufbewahren und konvertieren

Ein Snapshot wird auf der Geräteseite unter My Environment > Computers & Servers > Gerät > Summary > More actions > Create forensic snapshot > Create now oder in einem Threat Graph über Create forensic snapshot erstellt. Manuell erzeugte Snapshots liegen standardmässig unter %PROGRAMDATA%\Sophos\Endpoint Defense\Data\Forensic Snapshots\, automatisch bei einer Erkennung erzeugte Daten unter %PROGRAMDATA%\Sophos\Endpoint Defense\Data\Saved Data\. Bei aktivem Tamper Protection ist für den Zugriff eine erhöhte Eingabeaufforderung nötig. Der Standardzeitraum umfasst die vergangenen zwei Wochen; unter Global Settings > Products and Services > Endpoint and Server > Forensic Snapshots kann man einen anderen Zeitraum oder All log data wählen. Vorher werden freier Speicher, Zugriffsberechtigte, Aufbewahrungsfrist und sichere Löschung festgelegt.

Für die Analyse wird die .tgz-Kopie beweissicher abgelegt. Auf einem 64-Bit-Windows wird der 64-Bit-Exporter gewählt; nur ein 32-Bit-Windows benötigt die 32-Bit-Ausgabe. Die Architektur lässt sich vor dem Download in PowerShell mit (Get-CimInstance Win32_OperatingSystem).OSArchitecture prüfen.

Der Bezug wird erst an dieser Stelle über HTTPS bei Sophos begonnen: SDR Exporter 64 Bit beziehen beziehungsweise SDR Exporter 32 Bit beziehen. Nach dem Sophos-Formular wird ausschliesslich die von Sophos bereitgestellte Datei übernommen. Sie kommt in ein neu angelegtes, nur für die zuständigen Ermittler beschreibbares Arbeitsverzeichnis und wird weder aus einem Mail-Anhang noch aus einem Drittanbieter-Mirror übernommen. Vor der Ausführung werden Authenticode-Signatur und eigener Beweissicherungs-Hash geprüft; der Hash dokumentiert genau den bezogenen Stand, ist aber mangels separat veröffentlichtem Sophos-Sollwert kein unabhängiger Herkunftsnachweis:

$tool = '.\SDRExporterx64.exe'
$expectedSubject = $env:SDR_EXPORTER_EXPECTED_SUBJECT
$expectedThumbprint = $env:SDR_EXPORTER_EXPECTED_THUMBPRINT
if ([string]::IsNullOrWhiteSpace($expectedSubject) -or
    [string]::IsNullOrWhiteSpace($expectedThumbprint)) {
    throw 'Set the approved signer subject and thumbprint before validation.'
}
$expectedThumbprint = ($expectedThumbprint -replace '\s', '').ToUpperInvariant()
if ($expectedThumbprint -notmatch '\A[0-9A-F]+\z') {
    throw 'The approved signer thumbprint is not hexadecimal.'
}

$sig = Get-AuthenticodeSignature -FilePath $tool
if ($sig.Status -ne 'Valid' -or $null -eq $sig.SignerCertificate) {
    throw "SDR Exporter: Authenticode status is $($sig.Status)."
}
$actualThumbprint = ($sig.SignerCertificate.Thumbprint -replace '\s', '').ToUpperInvariant()
if (-not [string]::Equals($sig.SignerCertificate.Subject, $expectedSubject,
        [StringComparison]::Ordinal) -or
    -not [string]::Equals($actualThumbprint, $expectedThumbprint,
        [StringComparison]::Ordinal)) {
    throw 'SDR Exporter: signer does not exactly match the approved acquisition record.'
}

$chain = [Security.Cryptography.X509Certificates.X509Chain]::new()
$chainBuilt = $chain.Build($sig.SignerCertificate)
[pscustomobject]@{
    Status              = $sig.Status
    StatusMessage       = $sig.StatusMessage
    SignerSubject       = $sig.SignerCertificate.Subject
    SignerThumbprint    = $actualThumbprint
    SignerIssuer        = $sig.SignerCertificate.Issuer
    SignerNotBefore     = $sig.SignerCertificate.NotBefore
    SignerNotAfter      = $sig.SignerCertificate.NotAfter
    ChainBuilt          = $chainBuilt
    ChainStatus         = ($chain.ChainStatus.Status -join ', ')
    TimestampSubject    = $sig.TimeStamperCertificate.Subject
    TimestampThumbprint = $sig.TimeStamperCertificate.Thumbprint
}
$chain.ChainElements | ForEach-Object {
    [pscustomobject]@{
        ChainSubject    = $_.Certificate.Subject
        ChainThumbprint = $_.Certificate.Thumbprint
        ChainStatus     = ($_.ChainElementStatus.Status -join ', ')
    }
}
Get-FileHash -Algorithm SHA256 -Path $tool

Vor Ausführung des Blocks werden SDR_EXPORTER_EXPECTED_SUBJECT und SDR_EXPORTER_EXPECTED_THUMBPRINT auf die exakten Werte aus einem intern freigegebenen, über einen separaten vertrauenswürdigen Prozess erhaltenen Bezugsnachweis gesetzt; sie dürfen niemals aus der zu prüfenden Datei übernommen werden. Status Valid und die exakte Übereinstimmung beider Werte sind Freigabekriterien. Die ausgegebenen Details zu Signiererkette und Zeitstempel werden zusammen mit dem SHA-256-Wert als Nachweis aufbewahrt. Der Hash identifiziert die bezogene Datei, belegt aber ohne einen separat vertrauenswürdigen Referenzwert nicht ihre Herkunft. Fehlt ein freigegebener Wert, schlägt eine Prüfung fehl oder weicht der Hash später ab, wird die Datei nicht gestartet, sondern gelöscht und untersucht oder erneut über den obigen Sophos-Link bezogen. Tool und Eingabedatei werden danach nur aus dem geschützten Ablageort in einer erhöhten Eingabeaufforderung verarbeitet; Ein- und Ausgabe verwenden unterschiedliche Pfade:

SDRExporterx64.exe -i <snapshot.tgz> -o <snapshot.sqlite> -f sqlite

Für JSON wird -f json und ein passender Ausgabename verwendet; bei 32 Bit heisst das Programm SDRExporterx86.exe. Pfade mit Leerzeichen stehen in Anführungszeichen. Nach einem Exit ohne Fehler wird geprüft, dass die Ausgabedatei nicht leer ist und sich als SQLite-Datenbank öffnen und abfragen beziehungsweise als JSON parsen lässt. Eingabe-Hash, Exporter-Hash, Befehl, Zeitpunkt und Ausgabepfad kommen ins Incident-Protokoll; die konvertierte Datei erhält dieselben Zugriffsschutz- und Aufbewahrungsregeln wie der Snapshot.

Schlägt die Konvertierung fehl, wird nicht am Original weiterprobiert: Architektur und Dateiname, Signatur, Anführungszeichen, Lese- und Schreibrechte, freier Speicher sowie Integrität der .tgz-Arbeitskopie werden geprüft und anschliessend ein neuer Ausgabepfad verwendet. Eine Teil-Ausgabe gilt nicht als Ergebnis. Der Exporter installiert nichts; der Rückweg besteht darin, den Prozess zu beenden und unvollständige Ausgaben sowie nach Abschluss den Exporter aus dem Arbeitsverzeichnis sicher zu entfernen. Eine Arbeitskopie der .tgz wird erst nach verifizierter Konvertierung gemäss Incident-Prozess gelöscht. Das beweissicher abgelegte Original und erforderliche Protokolle bleiben bis zum Ende ihrer Aufbewahrungsfrist unverändert erhalten.

Optional in einen eigenen S3-Bucket hochladen

Der direkte S3-Upload ist nur für Windows-Geräte mit XDR- oder MDR-Lizenz verfügbar. In AWS erhält eine dedizierte Managed Policy ausschliesslich s3:ListBucket für arn:aws:s3:::<bucketName> und s3:PutObject für arn:aws:s3:::<bucketName>/*. Unter Global Settings > Products and Services > Endpoint and Server > Forensic Snapshots wird Upload forensic snapshot to an AWS S3 bucket aktiviert. Die dort angezeigten AWS Account ID und AWS External ID werden in der Trust Policy einer eigenen IAM Role für sts:AssumeRole verwendet. Nach der AWS-Propagation werden S3 bucket name, optional ein Verzeichnis und die Role ARN in Central gespeichert.

Bei der Wahl der AWS-Region werden Datenresidenz, Übertragungslatenz und -kosten sowie eigene Notfallvorgaben berücksichtigt. Die IAM Role muss vor dem Speichern in Central in allen AWS-Regionen propagiert sein; das kann bis zu fünf Minuten dauern.

Bucket Policy und IAM Permissions Boundary beschränken den Zugriff auf diese Rolle und die zuständigen Ermittler. Eine Lifecycle-Regel entfernt abgebrochene Multipart-Uploads und später Daten gemäss eigener Aufbewahrungsfrist. KMS-verschlüsselte Buckets werden für diesen Upload nicht unterstützt; AES-256 wird unterstützt und von Sophos beim Upload angefordert. Bucket-Namen dürfen keine nicht unterstützten Sonderzeichen enthalten, und Firewalls müssen den S3-Zugriff erlauben. Die Freigabe erfolgt erst, wenn ein Pilot-Snapshot vollständig im erwarteten Bucket-Pfad erscheint, von einem berechtigten Ermittler gelesen und konvertiert werden kann und unberechtigte Zugriffe abgewiesen werden. Nicht mehr benötigte Rollen, Policies und Central-Zuordnungen werden anschliessend entfernt.

Investigation, Threat Graphs und weitere Response-Schritte sind in Sophos Endpoint Detections und Threat Graphs untersuchen eingeordnet.

Dateien tenantweit erlauben oder blockieren

Datei-Freigaben und Hash-Blockierungen gehören in einen verifizierten Response- beziehungsweise False-Positive-Prozess, nicht in die allgemeine Baseline. Unter Global Settings > Protection and Remediation > Allow and Block > Files zeigt Allowed Applications, wo und wie eine Ausnahme entstand. Eine Freigabe kann je nach Plattform über Zertifikat, SHA-256 oder Pfad erfolgen; Zertifikat und Pfad können mehr als eine Dateiversion erfassen. Eine erlaubte Anwendung darf tenantweit für alle Benutzer laufen und wird von weiteren Threat-Erkennungen ausgenommen, wobei Exploit-, Ransomware- und Malicious-Behavior-Prüfungen bestehen bleiben. Vor Allow werden daher Hersteller, Signatur beziehungsweise Hash, Owner, Grund, Scope und Ablaufdatum geprüft. Remove nimmt die Freigabe zurück; anschliessend wird auf einem Pilotgerät kontrolliert, dass eine absichtlich ausgelöste Erkennung wieder greift.

Blocked Items benötigt eine XDR-Lizenz und blockiert verdächtige Anwendungen anhand ihres SHA-256 auf Windows-Geräten. Trusted-Reputation-Dateien und andere Objekttypen werden dadurch nicht blockiert. Über Add werden SHA-256 und Reason eingetragen, danach wird mit Save tenantweit aktiviert. Erlaubte und blockierte Dateieinträge teilen sich tenantweit ein gemeinsames Limit von 5'000 Einträgen. Vor Sammelimporten wird deshalb die kombinierte Kapazität beider Listen geprüft. Nach der Änderung testet man auf einem Pilotgerät, dass die Anwendung nicht startet und das erwartete Event entsteht. Remove ist der Rückweg; auch dieser wird auf dem Pilotgerät geprüft. Weitere Ausnahmeregeln erklärt Sophos Fusion Endpoint-Ausnahmen sicher konfigurieren.

9. Wellen freigeben und Regelbetrieb übernehmen

Nach der Pilotfreigabe wird pro Welle festgelegt, welche Geräte enthalten sind, wer den Fortschritt überwacht und bei welchen Signalen gestoppt wird. Geeignete Stoppsignale sind beispielsweise gehäufte Installationsfehler, fehlende Agentkommunikation, unerwartete Policy-Zuweisungen, Anwendungsstörungen oder eine nicht bearbeitbare Alertmenge.

Zum Regelbetrieb gehören mindestens:

• tägliche Zuständigkeit für kritische Alerts und Ausbrüche,
• regelmässige Prüfung inaktiver oder ungesunder Geräte,
• Review von Lizenzen, Agent Modes und Plattform-Lifecycle,
• kontrollierte Software- und Policy-Piloten,
• Ablaufkontrolle für Ausnahmen,
• Prüfung von Proxy, Update Cache und Message Relay,
• dokumentierte Response-, Datenschutz- und Supportwege.

Eine Welle ist erst beendet, wenn ihre Geräte nicht nur installiert, sondern technisch abgenommen und in diese Betriebsprozesse übernommen wurden.

Häufige Fragen