Sophos Managed Risk: Scans und Appliance systematisch diagnostizieren

Wenn ein Managed-Risk-Scan ausbleibt, hängen bleibt oder unerwartet wenige Resultate liefert, hilft eine Einordnung nach Symptom schneller als ein Neustart oder eine breite Firewall-Freigabe. Dieses Runbook führt durch vier mögliche Fehlerbereiche: externer Cloud-Scan, interne Scanning Appliance, Zielerreichbarkeit und authentifizierter Zugriff.

In fünf Schritten zum passenden Diagnosezweig

1. Betroffenen Scan, Scanner, Zeitfenster und exakten sichtbaren Status erfassen.
2. In der folgenden Tabelle den passenden Symptomzweig wählen.
3. Zuerst Scope, Netzwerkpfad und Konfiguration prüfen; nur eine begrenzte Korrektur auf einmal vornehmen.
4. Mit demselben Ziel und einem vergleichbaren Zeitfenster erneut validieren.
5. Bleibt der Fehler bestehen, ein von Geheimnissen bereinigtes Beweispaket erstellen und an den richtigen Empfänger eskalieren.

Zuerst den Ausgangszustand sichern

Unter My Products > Managed Risk > Scans den passenden Tab External oder Internal öffnen. Bei einem internen Scanner zusätzlich mit der Maus über Status fahren und den Detailstatus festhalten.

Zunächst genügen die Angaben, die den Fall reproduzierbar machen:

• Tenant beziehungsweise Account-ID und Account-Region
• Scan-Name und bei internen Scans Scanner-Name
• Scan-Typ: Discovery, Authenticated oder Unauthenticated
• erwartetes und tatsächlich erfasstes Ziel
• geplanter Start, beobachteter Beginn und Ende mit Zeitzone
• vollständiger Status- oder Fehlertext
• letzte Änderung an Scan, Scope, Exclusion, Credential, Firewall, VLAN, Hypervisor oder IP-Zuweisung
• ein betroffenes Ziel und, sofern vorhanden, ein funktionierendes Vergleichsziel

Danach immer nur eine Variable ändern. So bleibt nachvollziehbar, welche Korrektur tatsächlich geholfen hat.

Externer Scan erreicht das Ziel nicht

Managed Risk verwendet für externe Vulnerability Scans regionale Tenable Cloud Sensors. Entscheidend sind daher die Account-Region und die aktuell veröffentlichten Sensor-Netze – nicht eine ältere IP-Liste aus einem Ticket.

Die vollständige Konfiguration und die geltenden Scope-Grenzen stehen unter Externe Managed-Risk-Scans einrichten. Hier geht es nur darum, anhand des Symptoms die fehlerhafte Stelle einzugrenzen.

1. In der E-Mail Welcome to Sophos Managed Risk Service die Region des Sophos-Fusion-Accounts prüfen.
2. Fehlt die E-Mail, unter Threat Analysis Center > Cases den Welcome Case öffnen und dort die Region ablesen.
3. In der aktuellen Cloud-Sensors-Liste von Tenable genau die IP-Bereiche dieser Region ermitteln.
4. In der Firewall prüfen, ob eingehende Verbindungen aus diesen Bereichen zu den autorisierten öffentlichen Targets zugelassen werden. Zieladresse und veröffentlichte Dienste eng begrenzen.
5. Im verfügbaren Firewall- oder Load-Balancer-Ereignisfenster nachsehen, ob eine Verbindung vom erwarteten Sensorbereich abgewiesen wurde. Es wird kein herstellerspezifischer Logpfad vorausgesetzt.
6. Nach einer Korrektur den nächsten autorisierten Scan beziehungsweise einen mit dem Managed Risk Team vereinbarten Test abwarten und dasselbe Ziel erneut prüfen.

Eine temporäre Freigabe des gesamten Internets ist kein geeigneter Test. Auch eine zusätzliche Web-App-Scanning-Adresse aus einem fremden Tenable-Supportfall darf nicht in das Managed-Risk-Allowlisting übernommen werden.

External zeigt keine Scan-Einstellungen

Die externen Scan-Einstellungen werden erst verfügbar, nachdem mindestens ein autorisierter Kontakt gespeichert wurde:

1. My Products > Managed Risk > Settings > Authorized Contacts öffnen.
2. Prüfen, ob Primary mit einem Sophos-Fusion-Admin belegt ist und die Kontaktdaten vollständig sind.
3. Save wählen.
4. My Products > Managed Risk > Scans > External erneut öffnen.

Bereits gespeicherte externe Scan-Einstellungen lassen sich nicht selbst ändern. Für einen Reset oder eine Änderung unter Threat Analysis Center > Cases > Create case den Typ Managed Risk service request wählen. Nicht versuchen, die Einschränkung durch einen zweiten, abweichenden Scope zu umgehen.

Scope wird abgelehnt oder enthält unerwartete Ziele

Externen Scope gegen die Grenzen prüfen

Unter My Products > Managed Risk > Scans > External gelten folgende Grenzen:

• Add Domains: höchstens 25 öffentlich registrierte und im Internet routbare Domains
• Add IP addresses: höchstens 100 einzelne IP-Adressen oder CIDR-Bereiche
• externe CIDR-Bereiche: kein Präfix kleiner als /24
• maximal 1'000 externe Geräte
• keine privaten Bereiche wie 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16

Ein Name wie firma.local oder eine private IP ist kein gültiges externes Ziel. Bei einer Fehlermeldung die Eingaben einzeln statt als grosse Liste hinzufügen. So wird sichtbar, welcher Wert am Format, an der öffentlichen Erreichbarkeit oder an einem Limit scheitert. Keine fremde öffentliche IP als Platzhalter verwenden.

Interne Targets und globale Exclusions vergleichen

Discovery- und Vulnerability-Scans akzeptieren unter Add scan targets IP-Adressen, CIDR-Bereiche und Hostnamen. Ein syntaktisch gültiges Ziel kann trotzdem fehlen, wenn es global ausgeschlossen wurde.

Unter Managed Risk > Settings > Global Exclusions alle Einträge gegen den betroffenen Hostnamen, die IP-Adresse und den übergeordneten CIDR-Bereich prüfen. Eine Global Exclusion wirkt auf interne und externe Scans. Deshalb eine Exclusion nicht vorschnell löschen oder verbreitern. Zuerst Name, Beschreibung, Add targets und den genehmigten Zweck mit dem tatsächlichen Scope abgleichen. Ist eine Änderung nötig, nur das falsche Ziel korrigieren und danach beide Scanarten auf unbeabsichtigte Abdeckung prüfen.

Scanner bleibt stehen oder erscheint offline

Direkt nach dem Anlegen zeigt ein neuer Scanner Waiting for Deployment. Nach der Bereitstellung durchläuft er die sichtbaren Zustände Downloaded, Waiting for appliance, Loading plugins und schliesslich Connected. Der Status zeigt, an welcher Stelle sich die Suche lohnt.

Installation und Grundkonfiguration gehören in Interne Scans und Scanning Appliance einrichten. Die folgenden Prüfungen setzen voraus, dass diese Einrichtung abgeschlossen ist.

1. Die VM mit den unterstützten Hypervisor-Versionen sowie der Mindestgrösse für vCPU, RAM und Storage im verlinkten Bereitstellungsleitfaden vergleichen.
2. Die effektive CPU-Generation prüfen, die der VM bereitgestellt wird. Bei VMware zusätzlich kontrollieren, ob EVC mindestens der dokumentierten Basis entspricht; bei Hyper-V darf der Processor Compatibility Mode nicht aktiviert sein.
3. Bestätigen, dass die Appliance weiterhin ihre reservierte DHCP-Adresse beziehungsweise dokumentierte manuelle Adresse verwendet und Gateway, DNS sowie Zeitsynchronisation funktionieren.
4. In den zutreffenden Firewall- oder Proxy-Ereignissen den ausgehenden Zugriff ausschliesslich auf die im Bereitstellungsleitfaden dokumentierten Ports und Domains prüfen. Diese Liste nicht durch eine breite Internetfreigabe ersetzen.
5. Bleibt die Image-Generierung länger als einige Minuten ausstehend, die Sophos-Fusion-Seite wie im Bereitstellungsleitfaden beschrieben aktualisieren. Muss eine VMware-Bereitstellung neu begonnen werden, eine neu generierte Einmal-OVA statt der alten Datei verwenden.
6. Für den ersten Start und das erstmalige Laden der Plugins bis zu 30 Minuten einplanen. Loading plugins erst danach als festgefahren behandeln; dann den Status beim Darüberfahren und die verstrichene Zeit erfassen, statt die Appliance neu zu starten.

Interner Scan läuft zu lange oder erreicht Targets nicht

Ein grosser Scope kann wie ein Appliance-Fehler aussehen. CIDR-Bereiche mit /16 oder kleinerem Präfix können Timeouts verursachen, weil sehr viele Adressen geprüft werden. Solche Netze in fachlich sinnvolle Bereiche aufteilen und die Scans an verschiedenen Tagen oder zu verschiedenen Zeiten planen. Dabei dürfen keine nicht autorisierten Netze neu in den Scope gelangen.

Fehlen dagegen nur einzelne Ziele, führt diese kurze Pfadprüfung meist schneller weiter:

1. Ist das Ziel im richtigen Discovery- oder Vulnerability Scan eingetragen?
2. Deckt eine Global Exclusion das Ziel direkt oder über einen CIDR-Bereich ab?
3. Nutzt der Scanner weiterhin die reservierte beziehungsweise manuell konfigurierte IP-Adresse?
4. Liegt das Ziel in einem anderen VLAN? Dann benötigt die Scanning Appliance vollständigen bidirektionalen Zugriff auf alle Ports und Protokolle, die für den Scan dieses Ziels erforderlich sind.
5. Blockiert eine Network ACL, Host Firewall, IPS-/IDS-Regel oder Endpoint-Schutzrichtlinie den Zugriff von der IP-Adresse der Scanning Appliance?

VLANs nicht pauschal untereinander freigeben. Eine Regel von der festen Scanner-IP auf die genehmigten Targets begrenzen und beim nächsten Scan genau diese Ziele validieren. Bleibt selbst ein kleiner, erreichbarer Scope in Running oder erscheint nach Abschluss kein Report unter Managed Risk > Report History, Zeitpunkt, Scope und Status für Product Support sichern.

Authentifizierte Resultate fehlen

Ein Unauthenticated Scan simuliert einen externen Angreifer und erkennt typischerweise weniger Schwachstellen. Ein Authenticated Scan erhält tieferen Zugriff und findet üblicherweise mehr. Das funktioniert jedoch nur, wenn das richtige Credential zugewiesen ist und das Ziel die benötigten Zugriffe zulässt.

Credential-Typen, Anlage und sichere Zuweisung beschreibt Credentials für authentifizierte Scans konfigurieren. Dieser Abschnitt prüft nur, warum eine bestehende Zuweisung keine authentifizierten Resultate liefert.

Unter My Products > Managed Risk > Scans > Internal den Vulnerability Scan öffnen. Die Konfiguration ist nur dann stimmig, wenn alle folgenden Punkte erfüllt sind:

• Scan type steht auf Authenticated.
• Unter Select credentials ist das für das Ziel vorgesehene Credential ausgewählt.
• Ein Scan verwendet höchstens zehn Credentials.
• Optionale Targets eines SSH-Credentials enthalten den betroffenen Host beziehungsweise dessen Bereich.
• Credential-Typ und Ziel passen zusammen: Windows, SSH, SNMPv3 oder VMware ESX SOAP API.
• Das Credential wurde nach einer Kennwort-, Schlüssel-, Domain-, KDC- oder Berechtigungsänderung unter Managed Risk > Settings > Credentials aktualisiert.

Credentials nicht als Test löschen. Das Löschen entfernt ein Credential aus allen Scan-Konfigurationen, die es verwenden.

Für Windows sollte ein dediziertes lokales Administratorkonto für normale Systeme verwendet werden. Domain-Administrator-Credentials gehören nur in separate, besonders geschützte Scans für Domain Controller. Host Firewall, lokale beziehungsweise Domain Policies, Endpoint-Schutz, IPS/IDS, WMI, administrative Shares und Remote Registry dürfen den Scanpfad nicht blockieren.

Bei macOS und Linux den SSH-Zugang, die gewählte Authentifizierung, Berechtigungen und allfällige Privilege Elevation auf dem Ziel prüfen. Bei Kerberos müssen KDC, Realm, Transport und Reverse DNS zusammenpassen. Keine Betriebssystemeinstellungen nur zum Test global abschwächen.

Windows-Credential kontrolliert testen

Die folgenden dokumentierten Tests gelten nur für Windows-Credentials. Als Ausgangspunkt dient ein autorisiertes Windows-System im selben Subnetz wie die Scanning Appliance, damit die Netzwerkbedingungen vergleichbar bleiben. Eine administrative Command Prompt oder PowerShell-Sitzung und exakt dasselbe Credential wie in Sophos Fusion verwenden. Vorher sicherstellen, dass weder ein persistenter Befehlsverlauf noch eine Sitzungsaufzeichnung die Eingaben speichert.

Zuerst IPC$ und den administrativen Share prüfen:

net use \\<Target_IP>\ipc$ /user:<username> *
net use \\<Target_IP>\admin$ /user:<username> *

Erwartet wird jeweils The command completed successfully. Der erste Erfolg bestätigt grundlegende Netzwerk- und Credential-Funktion, der zweite Administratorzugriff und Share-Zugriff.

Wenn beide Verbindungen funktionieren, folgen Remote Registry und WMI:

reg query \\<Target_IP>\HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion /v ProgramFilesDir
wmic /node:"<Target_IP>" /user:"<username>" /password:* os get name

Eine zurückgegebene ProgramFilesDir bestätigt, dass Remote Registry mit diesem Credential erreichbar ist. Eine Betriebssystemausgabe bestätigt den WMI-Zugriff. Schlägt nur einer dieser Schritte fehl, genau diesen Pfad – Share, Service-Erreichbarkeit, WMI-Regel oder Berechtigung – auf dem Ziel korrigieren. Keine zusätzliche Berechtigung vergeben, bevor die konkrete Ablehnung feststeht.

Die beiden Sitzungsverbindungen nach den Prüfungen immer trennen – auch wenn ein Teilschritt fehlschlägt:

net use \\<Target_IP>\ipc$ /delete
net use \\<Target_IP>\admin$ /delete

Anschliessend mit net use kontrollieren, dass keine Verbindung zum Testziel mehr aufgeführt wird, die Shell schliessen und sicherstellen, dass kein Kennwort in Notizen oder Diagnoseanhängen gespeichert wurde. Danach einen autorisierten Scan mit demselben Credential ausführen und die Resultate vergleichen.

Abweichende Resultate richtig einordnen

Unterschiedliche Findings sind nicht automatisch ein Fehler. Zwei Tools oder Scanläufe können andere Regeln, Plugins und Updatezyklen verwenden. Zusätzlich bestimmen Betriebssystem, offene Ports und Scan type, welche Prüfungen überhaupt anwendbar sind.

Für einen belastbaren Vergleich folgende Punkte festhalten:

• Produkt und Scan-Typ beider Vergleiche
• Scanzeitpunkt und Ziel-Scope
• authentifiziert oder unauthentifiziert
• erfolgreich verwendetes Credential, ohne Secret
• erreichbare Dienste und Änderungen zwischen den Läufen
• betroffene Schwachstelle beziehungsweise CVE und sichtbarer Begründungstext

Managed Risk bewertet keine Web-Application- oder API-Level-Vulnerabilities. Ein fehlendes Web-App- oder API-Finding ist deshalb kein Beweis für einen defekten Netzwerk-Vulnerability-Scan. Umgekehrt beweist ein Authenticated Scan mit mehr Findings nicht, dass der frühere Unauthenticated Scan fehlerhaft war.

Bleibt ein konkretes Finding trotz vergleichbarer Bedingungen unklar, unter Threat Analysis Center > Cases > Create case > Managed Risk service request eine fachliche Prüfung durch das Managed Risk Team anfordern.

Beweispaket ohne Secrets zusammenstellen

Das Beweispaket soll die Rückfragequote senken, aber keine neuen Risiken schaffen. Dazu gehören:

• Tenant beziehungsweise Account-ID und Account-Region
• Scan- und Scanner-Name
• sichtbarer Status und vollständiger Fehlertext
• Start, Ende und Reproduktionszeitpunkt mit Zeitzone
• Scan-Typ, Targets und relevante Exclusions
• bei Appliance-Problemen: Hypervisor und Version, VM Hardware Version, CPU-Modell beziehungsweise EVC-Modus, vCPU, RAM, Storage und IP-Zuweisungsart
• bei Netzwerkproblemen: Scanner-IP, betroffenes Ziel, VLANs und Ergebnis der Firewall-/ACL-Prüfung
• bei Credential-Problemen: Credential-Name und -Typ, Zuweisung zum Scan sowie Ergebnis von IPC$, ADMIN$, Remote Registry und WMI
• letzte relevante Änderungen und Business Impact
• bereits ausgeführte sichere Korrektur und Resultat der Wiederholungsprüfung

Nicht beilegen: Kennwörter, NTLM-Hashes, private Schlüssel, Passphrases, KDC-Secrets, Session-Daten oder vollständige unnötige Systemausgaben. Screenshots und Logs können interne IP-Adressen, Hostnamen und Benutzernamen enthalten und werden nur über den vereinbarten geschützten Supportkanal übermittelt.

Den richtigen Eskalationsweg wählen

Wie Cases erstellt, geschützt übermittelt und nachverfolgt werden, zeigt Managed-Risk-Cases erstellen und verwalten.

Managed Risk Team

Fragen zum Service, zur Scan-Abdeckung, zu Resultaten oder Reports sowie Änderungen an gespeicherten externen Scan-Einstellungen gehören in einen Managed Risk Case:

Threat Analysis Center > Cases > Create case > Managed Risk service request

Einen aussagekräftigen Case-Namen verwenden und das bereinigte Beweispaket ergänzen. Die gemeinsame Cases-Liste enthält XDR-, MDR- und Managed-Risk-Cases; deshalb unter Case type auf Managed Risk achten. Nur Sophos Teams bearbeiten Managed-Risk-Cases.

Product Support

Ein reproduzierbarer Produkt- oder Appliance-Fehler gehört zu Product Support. Dazu zählen eine Appliance, die trotz erfüllter Plattform- und Netzwerkvoraussetzungen nicht Connected wird, ein anhaltender Zwischenstatus oder ein technischer Fehler der Oberfläche. In Sophos Fusion das Help-Symbol öffnen, Create support case wählen und das bereinigte Beweispaket mitsenden.

MDR Operations

Nur aktive MDR Incidents gehören zu MDR Operations. Ein fehlgeschlagener Vulnerability Scan, eine Scan-Einstellung oder eine fehlerhafte Scanning Appliance wird stattdessen über den oben passenden Managed-Risk- oder Product-Support-Weg eskaliert.

Remote Assistance nur für einen konkreten Supportfall

Remote Assistance erst aktivieren, wenn Product Support sie für einen bestehenden Fall anfordert. Die Appliance muss dafür online sein.

1. My Products > Managed Risk > Scans > Internal öffnen.
2. In der Zeile der richtigen Appliance ganz rechts das Drei-Punkte-Menü öffnen.
3. Remote Assistance wählen.
4. Im Dialog Enable aktivieren.
5. Die Checkbox zur Sophos Group Privacy Notice bestätigen und Save wählen.
6. Warten, bis Sophos Fusion die Access ID anzeigt.
7. Die Access ID nur über den vereinbarten Supportkanal und nur für den zugehörigen Fall senden.

Remote Assistance endet automatisch nach sieben Tagen. Wird sie früher nicht mehr benötigt, im Dialog Remote Assistance die Option Enable ausschalten. Lässt sich keine Access ID abrufen, zuerst bestätigen, dass die Appliance online ist; danach den sichtbaren Fehler im bestehenden Product-Support-Case ergänzen. Die Appliance weder neu starten noch löschen, um Remote Assistance zu erzwingen.