Sophos Managed Risk Reports prüfen und Schwachstellen beheben

Sophos Managed Risk erstellt wöchentlich Reports zu Schwachstellen und zur externen Angriffsfläche. Unter My Products > Managed Risk > Report History lädt man sie herunter, grenzt betroffene Systeme ein und leitet die nächsten Schritte ab. Managed Risk empfiehlt Massnahmen zur Behebung. Änderungen an Servern, Anwendungen, Netzwerkgeräten oder Cloud-Ressourcen müssen jedoch kontrolliert im eigenen Betrieb umgesetzt werden.

Für die schnelle Orientierung:

1. Benachrichtigung über einen neuen Report prüfen und Report History direkt im richtigen Sophos-Fusion-Tenant (ehemals Sophos Central) öffnen.
2. Auf External, Internal oder Account den erwarteten Wochenreport anhand von Name und Scan-Kontext finden.
3. Für die Triage den Schwachstellenreport als HTML öffnen; CSV und PDF je nach Arbeitszweck ergänzend verwenden.
4. Zuerst hohe Risiken und kritische Assets prüfen. Danach betroffenes Asset, Erkennungsgrundlage und Sophos-Empfehlung nachvollziehen.
5. Den zuständigen System- oder Service-Owner ausserhalb von Managed Risk bestimmen, die Änderung planen und technisch validieren.
6. Fragen oder Probleme zu Scanresultaten und Reports über einen Managed Risk Case untersuchen lassen; Empfehlungen zur Abhilfe im regelmässigen Review mit dem Managed Risk Team besprechen.

Report-Typ und Format richtig wählen

Report History ist in drei Tabs gegliedert. Am Dateinamen erkennt man, aus welchem Lauf ein Report stammt:

Die Teile Account_Name und Scan_name stehen für den jeweiligen Account- beziehungsweise Scannamen. Es sind Platzhalter, die mit den Namen im eigenen Tenant abgeglichen werden müssen.

Die Formate erfüllen unterschiedliche Aufgaben:

• HTML ist die beste Arbeitsansicht für die Triage. Sie zeigt aktive und aufgelöste Schwachstellen nach Risikostufe und betroffenem Asset und bietet interaktive Filter.
• CSV eignet sich zur strukturierten Auswertung und zum Abgleich mit dem internen Arbeitsnachweis. ASM- und Discovery-Reports sind ausschliesslich als CSV verfügbar.
• PDF ist eine statische Lesefassung eines Schwachstellenreports. Für das Eingrenzen einzelner Assets ist HTML in der Regel zweckmässiger.

Eine ASM- oder Discovery-CSV-Datei ist kein Schwachstellenreport in einem anderen Format. ASM beschreibt die erkannte externe Angriffsfläche, Discovery die bei einem internen Discovery-Scan gefundenen Assets. Beide können den Umfang weiterer Prüfungen klären, enthalten aber nicht dieselbe Schwachstellenanalyse wie ein Vulnerability Report.

Einen Wochenreport finden und den Download prüfen

1. My Products > Managed Risk > Report History öffnen.
2. Den passenden Tab External, Internal oder Account wählen.
3. Den erwarteten Wochenreport anhand des dokumentierten Namensmusters und des betreffenden Scans suchen.
4. In der Spalte Download report den Link für das benötigte Format anklicken.
5. Die heruntergeladene Datei öffnen und vor der Auswertung kontrollieren, ob Account beziehungsweise Scan und Report-Typ zum Prüfauftrag passen.

Sophos benachrichtigt, wenn neue Reports bereitstehen. Die Benachrichtigung stösst die Prüfung an; massgebend ist jedoch Report History. Dort muss der erwartete Report im richtigen Tab verfügbar und herunterladbar sein. Bei mehreren internen Scans verhindert der Abgleich des Scannamens, dass man versehentlich den Report eines anderen Netzbereichs auswertet.

Fehlt ein erwarteter Report, prüft man zuerst den Tenant, den ausgewählten Tab, das Namensmuster und den betroffenen Scan. Danach folgt der Abgleich, ob die Benachrichtigung tatsächlich zum aktuellen Wochenlauf gehört. Bleibt die Abweichung bestehen, hält man Report-Name, Tab, erwarteten Scan und Zeitpunkt der Benachrichtigung für eine Anfrage an das Managed Risk Team fest. Zugangsdaten oder andere Geheimnisse gehören nicht in diese Angaben.

Jeder Scanreport ist in Sophos Fusion bis zu zwei Jahre ab Abschluss des jeweiligen Scans zugänglich. Er ist ausschliesslich für den internen Gebrauch des Kunden beziehungsweise MSP bestimmt und darf nicht ausserhalb seiner Organisation weiterverteilt, weiterverkauft oder anderweitig übermittelt werden.

HTML-Report filtern und priorisieren

Einen Schwachstellenreport in HTML herunterladen und lokal öffnen. In dieser Ansicht lassen sich die Resultate nach Risk level, Device type und IP address filtern.

Der Account-Report ergänzt Filter für Scan-Typen und einzelne Scans. Er fasst die Daten des externen Schwachstellenscans und aller internen Schwachstellenscans zusammen. Er ist deshalb für die übergreifende Priorisierung geeignet, ersetzt bei Detailfragen aber nicht die Prüfung des passenden Einzelreports.

Für die erste Triage beginnt man mit den höchsten Risikostufen und grenzt die Resultate danach nach Asset, Gerätetyp oder Scan ein. Die Risikostufe allein bestimmt die Reihenfolge jedoch nicht. Ein internetexponiertes System oder ein geschäftskritisches Asset kann innerhalb derselben Stufe dringender sein als ein isoliertes Testsystem. Ausserdem ist zu prüfen, ob mehrere Einträge dieselbe technische Ursache auf demselben Asset betreffen.

Kritische Assets erkennen

Im HTML-Report steht links die Liste Assets. Bewegt man den Mauszeiger über den Namen eines entsprechend markierten Systems, zeigt ein Popover das Label Critical Asset und weiter unten die Critical Asset Description. Mit Show critical assets only begrenzt man die Ansicht auf Schwachstellen, die kritische Assets betreffen. Die Widgets am oberen Rand zeigen danach die Anzahl der zugehörigen Schwachstellen und betroffenen Assets.

Diese Markierung liefert Geschäftskontext, entscheidet aber nicht automatisch über die konkrete Behebung. Beschreibung, tatsächliche Funktion und aktueller Owner des Systems müssen weiterhin mit der eigenen Asset-Dokumentation abgeglichen werden.

Scans können falsch-positive und falsch-negative Resultate liefern. Zudem garantiert Sophos nicht, dass sie ein vollständiges und richtiges Bild der Sicherheitslücken ergeben. Ein Befund muss deshalb technisch verifiziert werden; umgekehrt beweist ein fehlender Befund nicht, dass keine Schwachstelle vorhanden ist. Die Scans dürfen nicht als alleinige Entscheidungsgrundlage dienen.

Vom Befund zur sicheren Abhilfe

Ein Report-Eintrag ist der Ausgangspunkt einer technischen Prüfung, nicht bereits eine freigegebene Änderung. Jede Massnahme aufgrund von Sophos-Empfehlungen zu Patching und Schwachstellenbehebung liegt ausserhalb des Leistungsumfangs; für ihre Umsetzung ist allein der Kunde beziehungsweise MSP verantwortlich und haftbar. Für jeden priorisierten Befund arbeitet man folgende Schleife ab:

1. Asset bestätigen: IP-Adresse, Hostname, Gerätetyp, Scan-Typ und gegebenenfalls die Beschreibung des kritischen Assets mit der aktuellen Asset-Dokumentation abgleichen. Bei einer unbekannten Zuordnung nicht auf Verdacht ändern.
2. Befund verstehen: Risikostufe, betroffene Komponente und die im Report enthaltenen Hinweise beziehungsweise Nachweise lesen. Prüfen, ob der Report aus einem externen, internen, authentifizierten oder nicht authentifizierten Scan stammt; unterschiedliche Scanarten können unterschiedlich tiefe Resultate liefern.
3. Empfehlung einordnen: Die von Sophos empfohlene Behebung mit den Herstellerhinweisen, der eingesetzten Version, den Abhängigkeiten und dem tatsächlichen Zustand des Systems abgleichen. Eine allgemeine Empfehlung wie ein Update oder eine Konfigurationsänderung muss zum betroffenen Produkt und zur eigenen Umgebung passen.
4. Technischen Owner bestimmen: Den verantwortlichen System-, Applikations-, Netzwerk- oder Cloud-Owner im eigenen Betriebsprozess identifizieren. Report History dokumentiert keine Zuweisungsfunktion; der Arbeitsnachweis und die Änderungsfreigabe liegen deshalb im dafür vorgesehenen internen System.
5. Änderung absichern: Auswirkungen, Wartungsfenster, Backup- oder Rückfallmöglichkeit und einen geeigneten Funktionstest vor der Umsetzung festlegen. Besonders bei produktiven oder kritischen Assets ist die Risikostufe kein Grund, Abhängigkeiten zu übergehen.
6. Abhilfe umsetzen und validieren: Nach der autorisierten Änderung die Version oder den Konfigurationszustand am Zielsystem kontrollieren und die betroffene Funktion testen. Der Report-Eintrag allein weist nicht nach, dass das System korrekt funktioniert.
7. Folgebericht prüfen: Im nächsten verfügbaren Report denselben Scan und dasselbe Asset erneut untersuchen. Ein veränderter Report ist ein zusätzlicher Nachweis, ersetzt aber weder die technische Prüfung am System noch eine zugesicherte Retest- oder Abschlussfunktion.

Für den eigenen Arbeitsnachweis hält man die belegbaren Fakten fest: Report und Woche, Scan, Asset, Schwachstelle, geprüfte Empfehlung, zuständiger technischer Bereich, autorisierte Änderung und Ergebnis der technischen Validierung. Daraus dürfen keine Managed-Risk-Felder oder -Status abgeleitet werden, die in der Oberfläche nicht dokumentiert sind.

Grenze der Berichtsfunktion: Für die Managed-Risk-Berichtsansicht sind keine Zuweisung, Risikoakzeptanz, manuell ausgelöste Nachprüfung, Schliessung oder SLA-Steuerung dokumentiert. Solche Prozesse können intern notwendig sein, sind aber keine zugesicherten Bedienelemente oder Produktstatus von Managed Risk. Auch die Bezeichnungen «aktiv» und «aufgelöst» im HTML-Report sind nicht mit einem vom Administrator steuerbaren Ticketstatus gleichzusetzen.

Empfehlungen und regelmässige Reviews nutzen

Das Managed Risk Team prüft die Reports, spricht Empfehlungen aus und bespricht aktuelle Befunde, neue Risiken und empfohlene Massnahmen in regelmässigen Meetings. Zur Vorbereitung stellt man die noch unklaren Hochrisiko-Befunde, betroffenen Assets, bereits geprüften technischen Fakten und konkreten Fragen zusammen. So wird deutlich, ob die Erkennung erklärt, der Scan-Kontext geklärt oder eine alternative Massnahme bewertet werden muss.

Ein Managed Risk Case ist der dokumentierte Weg, wenn Fragen oder Probleme zu Schwachstellen-Scanresultaten oder Reports durch das eigene Team nicht geklärt werden können. Das gilt zum Beispiel, wenn:

• ein hochriskantes Scanresultat unklar oder nicht plausibel ist,
• Report und aktueller Systemzustand voneinander abweichen,
• Scan-Kontext, Erkennung oder Report-Inhalt Fragen aufwerfen.

Fragen zur empfohlenen Behebung kann man auch für das regelmässige Review mit dem Managed Risk Team vorbereiten. Ein Case ersetzt weder die interne Änderungsfreigabe noch dient er als zugesicherte Abnahme oder Schliessung einer Behebung.

In eine Case-Anfrage gehören der genaue Report-Name, Tab und Woche, der betroffene Scan, das Asset, die fragliche Schwachstelle, die beobachtete Abweichung und bereits durchgeführte sichere Prüfungen. Passwörter, private Schlüssel und andere Geheimnisse werden nicht übermittelt.

Schwachstellenbehebung von aktiver Incident Response trennen

Managed Risk ist ein Vulnerability-Management-Service und setzt eine bestehende MDR- oder MDR-Plus-Lizenz voraus. Der normale Ablauf dieses Artikels bewertet Schwachstellen, plant Hardening oder Updates und prüft deren technische Wirkung. Das ist nicht dasselbe wie die Reaktion auf eine aktive Kompromittierung.

Zeigt die Untersuchung Hinweise auf laufenden Missbrauch, eine aktive Bedrohung oder bereits kompromittierte Systeme, wird nicht auf den nächsten Wochenreport gewartet. Dann gilt der vereinbarte Incident-Response- beziehungsweise MDR-Eskalationsweg. Der Schwachstellenreport kann dabei Kontext liefern, ersetzt aber weder die Incident-Untersuchung noch Eindämmung und Wiederherstellung.

Abschlusskontrolle pro Review-Zyklus

Zum Abschluss jedes Review-Zyklus prüfen:

• alle erwarteten wöchentlichen Reports auf External, Internal und Account geprüft wurden,
• Report-Typ, Name, Scan und Format zur jeweiligen Auswertung passen,
• hohe Risiken und Schwachstellen auf kritischen Assets zuerst technisch bewertet wurden,
• Asset und Erkennungsgrundlage nachvollziehbar sind,
• jede umgesetzte Abhilfe am Zielsystem und mit einem passenden Funktionstest validiert wurde,
• offene oder unklare Hochrisiko-Befunde für das Managed Risk Team mit konkreten Fragen vorbereitet sind,
• aktive Bedrohungshinweise nicht mit der normalen Schwachstellenbehebung vermischt wurden.

Diese Kontrolle dokumentiert den eigenen Review. Sie begründet weder einen Abschlussstatus in Managed Risk noch eine garantierte Frist, innerhalb der eine Änderung in einem späteren Report sichtbar wird.