Sophos Server Application Control: erst erkennen, dann blockieren

Kurzweg: Unter My Products > Server > Policies eine Application Control-Policy für ausgewählte Windows Server zunächst ohne Zuweisung und mit Off anlegen.

Erkennen: Unter Controlled Applications > Add/Edit List relevante Kategorien wählen; unter Detection Options ausschliesslich Detect controlled applications during scheduled and on-demand scans einschalten und speichern. Erst danach die Pilotserver zuweisen, die Policy auf On stellen und die wirksame Zuweisung prüfen.
Auswerten: Nach einem Scan die Treffer unter Reports > General Logs > Events mit Event-Typ Application Control gegen die Server-Workloads prüfen.
Blockieren: Erst wenn benötigte Serverprogramme aus der kontrollierten Auswahl abgewählt sind, im eng begrenzten Pilot Detect controlled applications when users access them und Block the detected application aktivieren.

Application Control setzt eine betriebliche Entscheidung über von Sophos katalogisierte Anwendungen durch, die nicht zwangsläufig schädlich sind. Sie ist weder Malware-Erkennung noch die Dateifreigabe von Sophos Unauthorized File Protection (SUFP). Die hier beschriebene Server-Policy gilt nur für Windows Server, nicht für Linux und nicht für die Endpoint-Policy auf Arbeitsplätzen. Der Endpoint-Ablauf ist daher keine Vorlage für die Zielzuweisung an Server.

Vor der ersten Sperre: Server-Workloads erfassen

Eine Sperre betrifft nicht nur interaktive Admin-Sitzungen. Prüfen Sie auf jedem Pilotsystem mit dem zuständigen Applikationsteam auch Dienste, geplante Aufgaben, Backup- und Monitoring-Agenten, Fernwartung, Installer und herstellereigene Updater. Beispiel: Auf einem Anwendungsserver kann ein Fernwartungsprogramm für den freigegebenen Support benötigt werden, auf einem anderen Server aber nicht. Entscheidend ist die tatsächliche Aufgabe je Server, nicht der pauschale Kategoriename.

Notieren Sie vorab Pilotserver, verantwortliche Person, betroffene Programme und Versionen, Zeitpunkt des nächsten geplanten Scans, Wartungsfenster sowie einen funktionierenden Administrationszugang und Rückweg. Die Registerkarte Applications unter My Products > Server > Servers > [Servername] zeigt installierte Programme als zusätzliche Inventarquelle; sie ist nicht gleichbedeutend mit den Treffern der Application-Control-Erkennung. Prüfen Sie die im Tenant tatsächlich angebotene Policy und Berechtigung, bevor Sie eine produktive Zuweisung ändern. Ist eine Option gesperrt, können globale Einstellungen des Partners oder Enterprise-Administrators der Grund sein.

⚠️ Nicht die gemeinsame Base-Policy für einen ersten Blocktest ändern: Sie kann alle Server treffen, für die keine spezifischere Policy greift. Auch eine vorhandene produktive Policy nicht ohne Prüfung bearbeiten; eine Änderung wirkt auf alle ihr zugewiesenen Server.

Erkennungsphase einrichten

Unter My Products > Server > Policies über Add Policy die Funktion Application Control auswählen und die Policy etwa Server-AppControl-Pilot nennen. Die neue Policy zunächst mit Off und ohne Serverzuweisung anlegen; noch nicht auf On stellen. Der Name ist frei wählbar. Unter Settings zuerst die reine Erkennung konfigurieren, bevor ein Server die Policy erhält.
Unter Controlled Applications > Add/Edit List die für den Pilot relevanten Kategorien öffnen. Select all applications nimmt zunächst alle Einträge der gewählten Kategorie in die zu untersuchende Liste auf; mit Save to List übernehmen. Nur Kategorien erfassen, deren Einfluss man auswerten kann. Sophos pflegt diese Anwendungsliste; ein Programm ausserhalb des Katalogs kann nicht durch eine erfundene Kategorie kontrolliert werden.
Unter Detection Options ausschliesslich Detect controlled applications during scheduled and on-demand scans auswählen. Detect controlled applications when users access them und Block the detected application bleiben aus. Die Einstellungen speichern und erneut prüfen, bevor die Policy zugewiesen oder eingeschaltet wird.
Erst jetzt ausschliesslich die vorgesehenen Windows-Pilotserver beziehungsweise ihre Servergruppe zuweisen und die Policy auf On stellen. Unter My Products > Server > Servers > [Servername] > Policies für jeden Pilotserver prüfen, ob die vorgesehene Application-Control-Policy tatsächlich angewendet wird; erst danach den Testscan abwarten. Bei mehreren Policies desselben Typs gilt die erste passende aktivierte Policy in der Reihenfolge; die Base-Policy bleibt der Rückfall für Server ohne spezifischere Policy. Nur das Speichern oder Zuweisen einer Policy bestätigt keine wirksame Zuweisung.
Die Scan-Erkennung nutzt die geplanten Scans und Dateityp-Einstellungen der Threat Protection-Policy; warten, bis die Pilotserver einen geeigneten geplanten Scan abgeschlossen haben. Unter Reports > General Logs > Events alle Event-Typen ausser Application Control abwählen. Falls eine ausgewählte, erfassbare Anwendung beim Scan erkannt wird, ist ein Treffer mit Servername, Anwendung und Zeitpunkt zu erwarten; diese Angaben gegen das Workload-Inventar abgleichen. Fehlt der Treffer, zuerst Scanabschluss, gescannte Dateitypen, effektive Policy und Event-Filter beziehungsweise Zeitraum prüfen. Ein leerer Report beweist auch nach dem Scan nicht, dass keine relevanten Anwendungen vorhanden sind. Fehlen etwa ein seltener Updater oder eine nur bei Wartung gestartete Aufgabe, werden diese Abläufe vor einer Sperre separat in einem geeigneten Testfenster bewertet. Ein Scan-Treffer allein beweist weder aktive Nutzung noch eine nebenwirkungsfreie spätere Blockierung.

Eine begrenzte Blockierung testen

In Controlled Applications > Add/Edit List alle geschäftlich benötigten Anwendungen aus der kontrollierten Auswahl abwählen. Für den Sperrtest genau einen verbleibenden Katalogeintrag wählen, dessen Anwendung auf dem Pilotserver tatsächlich vorhanden, dort bewusst nicht benötigt und mit dem Workload-Verantwortlichen für einen einmaligen Test im Wartungsfenster abgestimmt ist. Alle übrigen Einträge für diesen ersten Blocktest ebenfalls abwählen und Save to List wählen: Jeder weitere ausgewählte Eintrag wäre sonst gleichfalls von der Sperre betroffen. Gibt es keinen geeigneten Testeintrag, die Blockoption nicht aktivieren und keinen Sperrtest erzwingen. Die optionale Einstellung New applications added to this category by Sophos im ersten Blockpilot nicht aktivieren: Neue Katalogeinträge und neuere Versionen bereits gelisteter Anwendungen würden sonst automatisch kontrolliert und bei aktivem Blockschalter gesperrt.
Nur mit geprüftem Testeintrag und für die bereits geprüfte Pilotzuweisung unter Detection Options Detect controlled applications when users access them und Block the detected application aktivieren; Policy speichern. Damit wird der Zugriff auf kontrollierte Anwendungen blockiert, nicht bloss ein Fund in einem Scan gemeldet. Die reine Scan-Erkennung ohne diese Zugriffserkennung und Blockoption ist noch keine Durchsetzung.
An einem repräsentativen Pilotserver die effektive Policy erneut unter Servers > [Servername] > Policies prüfen. Im Wartungsfenster nur die Anwendung des vereinbarten, nicht benötigten Katalogeintrags testweise starten: Negativtest ist die verweigerte Ausführung; unter Reports > General Logs > Events das zugehörige Application Control-Ereignis für diesen Server, diese Anwendung und den Zeitpunkt prüfen. Bleiben Sperre oder Ereignis aus, nicht von erfolgreicher Durchsetzung ausgehen, sondern kontrollierten Eintrag, Version, beide Schalter, effektive Policy und Event-Filter prüfen. Positivtest: Eine aus der kontrollierten Auswahl abgewählte, erlaubte Fachanwendung sowie den betroffenen Dienst oder geplanten Job und Backup/Monitoring nach dem Test auf Funktion prüfen. Nur wenn Sperre und erlaubte Workloads wie vorgesehen beobachtet wurden, die nächste Servergruppe planen.

Desktop Messaging ist laut Sophos standardmässig eingeschaltet. Ein eigener Text ergänzt die Standardmeldung, ein leeres Feld lässt nur die Standardmeldung erscheinen. Bei Hintergrunddiensten und Aufgaben ohne interaktiven Benutzer ersetzt eine mögliche Desktop-Meldung weder das Event noch den Workload-Test; verlassen Sie sich dort nicht auf sichtbares Feedback. Fehlt eine gewünschte Anwendung im Sophos-Katalog, führt Application Control Request am Ende des Tabs Settings zum Aufnahmeantrag – nicht zu einer sofort wirksamen lokalen Signatur.

Störung eingrenzen und nur den Pilot zurücknehmen

Keine Events in der Erkennungsphase: Zuerst am betroffenen Server die effektive Policy, deren On-Status, Scanzeitpunkt und Threat-Protection-Scaneinstellungen prüfen. Danach Event-Filter und Zeitraum kontrollieren. Applications zeigt installierte Programme, nicht zwangsläufig Application-Control-Treffer.
Erwartete Sperre bleibt aus: Kontrollieren, ob der konkrete Eintrag in Controlled Applications gewählt ist, ob Zugriffserkennung und Blockierung aktiv sind und welche Policy unter Servers > [Servername] > Policies tatsächlich gilt. Andere Programmversionen oder ein nicht katalogisierter Launcher sind nicht automatisch gleich erkannt.
Ein benötigter Dienst oder Updater wird blockiert: Betroffenen Server, Event, Zeitpunkt und Anwendung dokumentieren. In der Pilot-Policy den benötigten Eintrag aus der kontrollierten Auswahl entfernen oder die Blockoption für den Pilot ausschalten und speichern. Falls die Störung breiter ist, die Pilot-Policy deaktivieren oder ihre Pilotzuweisung entfernen; vorher prüfen, welche andere Policy, insbesondere Base, dann wirksam wird. Nach der Aktualisierung am Server die effektive Policy und den betroffenen Dienst beziehungsweise Job erneut testen. Keine globale Malware-Ausnahme als Ersatz für diese Application-Control-Korrektur anlegen.

Dieser Rückweg nimmt nur die eigene Pilotentscheidung zurück. Er ist keine Zusage für sofortige Policy-Verteilung, Wiederanlauf bereits gestoppter Prozesse oder automatische Reparatur unterbrochener Jobs. Bleibt ein kritischer Workload gestört, nach internem Wiederanlaufplan vorgehen und mit Event, Policy-Zuweisung und Zeitstempeln an den zuständigen Support eskalieren.