Sophos Incident Response, Readiness und Assessments einordnen

Bei einem aktiven oder vermuteten Sicherheitsvorfall wird der bereits vereinbarte Incident-Prozess gestartet. Ein laufender Angriff ist kein gewöhnliches Implementierungsprojekt. Man nutzt den im Notfallplan festgelegten Kontakt und den bestätigten Serviceanspruch, statt zunächst ein Assessment oder einen neuen Retainer zu bestellen.

Digital Forensics and Incident Response (DFIR) verbindet die forensische Untersuchung mit der Reaktion auf einen konkreten Vorfall. Readiness bereitet Verantwortliche und Abläufe darauf vor. Security Testing und Assessments untersuchen einen vorab abgegrenzten Sicherheitsumfang. Diese Leistungen liefern unterschiedliche Ergebnisse und ersetzen sich nicht gegenseitig.

Einen Vorfall richtig übergeben

Sophos beschreibt DFIR als Unterstützung bei der Identifikation und Neutralisierung aktiver Bedrohungen sowie bei Ursachenanalyse, Compromise Assessment und Threat Hunting. Welche Arbeiten tatsächlich übernommen werden, richtet sich nach der beauftragten Leistung und dem bestätigten Anspruch. Eine Herstellerbeschreibung eines rund um die Uhr verfügbaren Teams ist keine individuelle Zusage für Einsatzbeginn, Vor-Ort-Anwesenheit oder eine bestimmte Wiederherstellungsdauer.

Für die erste Übergabe bereitet man einen kurzen, nachvollziehbaren Stand vor:

1. Ansprechpartner und Entscheidungskompetenz: technische Einsatzleitung, geschäftlich Verantwortliche und freigegebener Rückkanal.
2. Beobachtung statt Vermutung: Zeitpunkt mit Zeitzone, betroffene Systeme beziehungsweise Identitäten, konkrete Meldungen und erkennbare Auswirkungen.
3. Bereits ausgeführte Massnahmen: beispielsweise Isolationen, Kontensperren oder Wiederherstellungen mit Zeitpunkt und ausführender Person.
4. Verfügbare Nachweise: Logs, Case-IDs und vorhandene Sicherungen samt Herkunft und Aufbewahrungsort. Unbekannte Vollständigkeit ausdrücklich kennzeichnen.
5. Anspruch und Umfang: Kunde, Vertrag beziehungsweise Retainer sowie der bekannte betroffene Bereich. Ungeklärte Berechtigung nicht als bestehenden Anspruch ausgeben.

Diese Liste ist eine Avanet-Empfehlung für die organisatorische Übergabe, kein vollständiges forensisches Verfahren. Sie soll die erste Bearbeitung ermöglichen, ohne wichtige Informationen durch voreilige Änderungen zu verlieren. Kontaminierte Systeme werden nicht allein zum Erstellen einer «sauberen Ausgangslage» neu installiert. Über Isolierung, Abschaltung, Beweissicherung und Wiederherstellung entscheiden die zuständigen Incident-Verantwortlichen anhand des konkreten Falls.

Nachweise können Kennwörter, personenbezogene Daten oder vertrauliche Geschäftsinhalte enthalten. Deshalb werden nur benötigte Daten über einen bestätigten sicheren Kanal übergeben. Ein öffentliches Ticket, Chat oder ungeschützter Dateilink ist kein geeigneter Ersatz. Bei Verdacht auf kompromittierte Kommunikationskonten wird vor der Übergabe ein vertrauenswürdiger Rückkanal abgestimmt.

MDR und DFIR nicht verwechseln

MDR ist der laufende verwaltete Dienst für Bedrohungssuche, Erkennung und vereinbarte Response. DFIR bearbeitet einen konkreten Vorfall mit dem bestätigten Untersuchungsumfang. Auch wenn dieselbe Organisation Leistungen anbietet, folgt aus einem Product-Alert nicht automatisch ein DFIR-Auftrag oder ein unbegrenzter Untersuchungsanspruch.

Im bestehenden MDR-Betrieb sind Kontakte und Threat-Response-Modus sowie der tatsächliche Case-Owner und die benötigte Kundenaktion massgeblich. Ein customer-managed Case wird nicht allein wegen einer Sophos-Lizenz automatisch vom MDR-Team untersucht. Offene Kundenaktionen brauchen eine zuständige Person und werden nicht durch einen vermeintlichen Servicewechsel erledigt.

Der Security Services Retainer erklärt Service Units und besondere DFIR-Bedingungen. Ein SU-Guthaben ist weder eine allgemeine Reaktionsfrist noch eine Garantie, einen Vorfall innerhalb einer bestimmten Stundenanzahl abzuschliessen. Bestehende Ansprüche werden anhand der konkreten Vereinbarungen geprüft.

Readiness: die Reaktion vor dem Ernstfall üben

Readiness bedeutet, dass Zuständigkeiten, Zugänge und Entscheidungswege bereits vor einem Vorfall verwendbar sind. Eine Tabletop Exercise ist eine geführte Übung mit einem Szenario: Das Team bespricht seine Entscheidungen und Übergaben, ohne dafür einen echten Angriff in der Produktivumgebung auszuführen.

Für eine solche Übung legt man Ziel und Teilnehmer fest, etwa die Abstimmung zwischen IT, Geschäftsleitung und Kommunikation bei kompromittierten Administratoridentitäten. Die Übung sollte zeigen, wer einen Vorfall erklärt, wer Eindämmung freigibt, wie ausserhalb möglicherweise betroffener Systeme kommuniziert wird und wie Wiederanlaufentscheidungen entstehen. Ergebnis sind dokumentierte Beobachtungen und konkrete Verbesserungen mit Verantwortlichen und Termin.

Ein vorhandener Notfallplan allein ist noch kein Nachweis funktionierender Wiederherstellung oder erreichbarer Kontakte. Avanet empfiehlt, nach relevanten Änderungen die Kontakt- und Freigabekette sowie einen angemessenen Wiederherstellungsablauf erneut zu prüfen. Eine reine Besprechung ersetzt keinen separat geplanten technischen Restore-Test.

Assessments und Sicherheitstests passend auswählen

Ein externes Penetration Testing betrachtet den Zugang von aussen. Interne Tests untersuchen beispielsweise, was mit bereits vorhandenem Netzwerkzugang möglich wäre. Wireless-Tests prüfen WLAN-bezogene Angriffswege; Web-Application-Assessments untersuchen Anwendungen und deren konkrete Sicherheitsprobleme. Die Bezeichnung ist keine Zusage, dass jede Niederlassung, Anwendung oder Schnittstelle enthalten ist.

Ein Assessment ist auch kein Beweis einer vollständigen Kompromissfreiheit. Ein Compromise Assessment sucht innerhalb seines vereinbarten Umfangs nach Anzeichen eines Eindringens; ein Penetrationstest prüft ausgewählte Angriffswege. Beides ist vom laufenden Managed-Risk-Betrieb und von der Reaktion auf einen bereits aktiven Vorfall zu unterscheiden.

Vor einem Test werden schriftlich Zielsysteme und Ausschlüsse, Eigentümerfreigaben, erlaubte Methoden, Zeitfenster, Datenzugriff und Stop-Kriterien festgelegt. Bei Cloud- oder Fremdsystemen muss die entsprechende Testberechtigung vorliegen. Verantwortliche brauchen einen erreichbaren Abbruchkontakt; Verfügbarkeit und produktive Auswirkungen werden ausdrücklich berücksichtigt. Ohne geklärte Freigabe wird kein Test gestartet.

Zum Ergebnis gehören ein verständlicher Befund mit betroffenen Systemen, Nachweis, Auswirkung und priorisierter Behebung. Ein Nachtest prüft die vereinbarten behobenen Punkte; ob, wann und in welchem Umfang er enthalten ist, wird im Angebot bestätigt. Ein Bericht ist kein Zertifikat für ein künftig unangreifbares System. Die Umsetzung der Verbesserungen und deren Abnahme bleiben als eigene Aufgaben sichtbar.

Für geplante Änderungen nach dem Befund hilft die Abgrenzung von TAM, Support und Deployment Services. Damit wird aus einer Empfehlung ein klar beauftragtes Projekt mit technischer Übergabe, statt dass offene Risiken zwischen Dienstleistern weitergereicht werden.