Déployer en toute sécurité Unauthorized File Protection sur les serveurs Windows

En bref : Dans My Products > Server > Policies, créer une stratégie Unauthorized File Protection pour un petit groupe pilote de serveurs Windows et activer la stratégie elle-même. Dans Settings, activer également Enable tracking of unauthorized file changes et sélectionner Monitor execution of unauthorized files without blocking. Sur chaque serveur, vérifier la stratégie appliquée dans Policies, examiner les événements et les logiciels nécessaires, puis n’autoriser que les éléments justifiés. Ensuite seulement, tester Block execution of unauthorized file sur le même groupe pilote. Enregistrer et attribuer la stratégie ne prouve ni qu’elle est activée ni qu’elle agit sur le serveur.

Important pour les installations Server Lockdown existantes : Le renommage de la stratégie en Unauthorized File Protection (SUFP) ne constitue pas une migration avérée du produit Lockdown installé. Selon Sophos, les fichiers et dossiers déjà autorisés ou bloqués dans les stratégies Lockdown existantes ne sont pas affectés par ce changement de nom. Un serveur verrouillé doit être déverrouillé avant l’utilisation de la nouvelle stratégie. Ne pas utiliser cet article pour supprimer des composants Lockdown, convertir automatiquement des stratégies ou rétablir un ancien état de l’hôte. L’inventaire de l’existant, le déverrouillage et le changement de configuration de l’hôte relèvent de la procédure distincte de migration de Lockdown vers UFP ; l’équipe responsable doit d’abord vérifier et approuver la procédure adaptée à l’hôte concerné.

Ce que protège la stratégie et ses limites

Unauthorized File Protection est une stratégie réservée aux serveurs Windows. Elle suit les opérations sur les fichiers effectuées par des processus non privilégiés lorsqu’ils créent, modifient ou déplacent des fichiers Portable Executable (PE). La création de liens physiques (hardlinks) et le renommage de dossiers font également partie des activités surveillées. Il s’agit de contrôler l’exécution de fichiers non autorisés, et non de bloquer globalement toutes les écritures ni d’assurer un contrôle de l’intégrité de n’importe quel fichier.

La réputation des fichiers influe sur la décision : les fichiers locaux jouissant d’une réputation élevée peuvent être exécutés s’ils ne figurent pas dans la liste de blocage. Les modifications des fichiers de réputation faible à moyenne sont suivies ; après une modification par un processus non autorisé, leur exécution peut être interdite en mode blocage. En mode blocage, une entrée de la liste de blocage interdit l’exécution d’un fichier quelle que soit sa réputation, sous réserve des exceptions indiquées par Sophos pour les fichiers Sophos et système ; en mode surveillance, une exécution non autorisée est signalée à la place. Si l’objectif est d’interdire systématiquement une application légitime et largement répandue, examiner la stratégie distincte Server Application Control plutôt que de créer une autorisation SUFP générale.

MSI n’est pas PE. Un package d’installation MSI n’est pas simplement bloqué comme un fichier PE. Les fichiers PE extraits pendant l’installation ou lancés ensuite peuvent toutefois être bloqués, notamment s’ils n’ont pas une réputation élevée et ne correspondent à aucune entrée de la liste d’autorisation. Une installation peut ainsi échouer ou sembler réussir alors que l’application installée ne démarre pas par la suite. Les chemins MSI ou les dossiers contenant des fichiers MSI peuvent être ajoutés à la liste d’autorisation ou de blocage ; Sophos en tient compte pour décider de l’installation et de l’exécution des fichiers PE qui en sont issus. Autoriser un MSI ne dispense donc pas d’évaluer l’éditeur, la provenance et les fichiers exécutables effectivement nécessaires.

Préparer le pilote et commencer en mode surveillance

Choisir quelques serveurs Windows représentatifs et déverrouillés, avec une fenêtre de maintenance connue : par exemple, un serveur de test utilisant la même chaîne applicative et de mises à jour que les serveurs de production visés. Consigner le tenant, les noms des serveurs, le groupe de serveurs attribué, la stratégie actuellement appliquée, les services ainsi que les installations ou mises à jour planifiées. Sauvegarder les paramètres et l’attribution de la stratégie précédente afin de pouvoir les rétablir de manière ciblée si nécessaire. Une sauvegarde ou une restauration testée de l’application ne remplace pas le contrôle de la stratégie.

1. Ouvrir My Products > Server > Policies et créer une stratégie de type Unauthorized File Protection. Lui donner un nom explicite, par exemple SUFP-Windows-Pilot ; ce nom est libre et n’est pas une valeur imposée par Sophos. Ne l’attribuer qu’aux serveurs pilotes documentés ou à leur petit groupe de serveurs. Avant d’enregistrer, vérifier qu’une stratégie de même type et de priorité supérieure ne prend pas le pas sur la stratégie pilote et qu’aucun autre serveur n’entre par erreur dans son périmètre. Sur la page de détail, vérifier expressément que la stratégie elle-même est activée : attribuer une stratégie désactivée ou activer son suivi ne suffit pas à l’activer.
2. Ouvrir Settings, activer Enable tracking of unauthorized file changes et sélectionner Monitor execution of unauthorized files without blocking. Enregistrer la stratégie. Enable tracking est un paramètre interne à la stratégie, distinct de son interrupteur d’activation. Le mode surveillance signale les exécutions non autorisées au lieu de les bloquer ; il ne constitue pas un mécanisme d’approbation capable de distinguer automatiquement les fichiers légitimes des fichiers malveillants.
3. Pour chaque serveur pilote, ouvrir My Products > Server > Servers > [Servername] > Policies. Avant le test, y comparer le nom et le type Unauthorized File Protection effectivement appliqués à ceux de la stratégie pilote ; si Base ou une autre stratégie de priorité supérieure s’applique à la place, corriger d’abord le périmètre, l’activation et la priorité. Consigner l’état initial et revérifier le même onglet après toute modification. Ce n’est qu’alors qu’il faut faire fonctionner les services habituels, les tâches planifiées et les mises à jour, et effectuer un test approuvé d’installation d’application pendant la fenêtre pilote. Pour chaque événement notable, relever le serveur, l’heure, le fichier, le chemin, le SHA-256 ou le signataire (si disponibles), le processus à l’origine de l’exécution et l’application concernée. Une période sans événement, en l’absence de charge de travail représentative, ne prouve pas que le mode blocage est sans risque en production.

Limiter strictement les autorisations et les blocages

Sous Allowed items, Add allowed item permet d’ajouter une entrée de type File, Folder, SHA256 ou Signer ; après validation de la boîte de dialogue, cliquer également sur Save sur la page de la stratégie. Les entrées autorisées correspondantes sont considérées comme privilégiées. Privilégier le chemin complet du fichier ou, pour un fichier précis et immuable, son empreinte SHA-256 vérifiée. Un dossier et ses sous-dossiers ou un signataire peuvent couvrir davantage de logiciels et nécessitent une évaluation des risques distincte. Ne pas autoriser globalement les dossiers de téléchargement ou temporaires dans lesquels les utilisateurs peuvent largement écrire ; examiner d’abord la chaîne de mise à jour effective et les droits d’écriture.

Sous Blocked items, Add blocked item permet aussi de choisir File, Folder, SHA256 ou Signer. Une liste de blocage ne remplace ni la détection des logiciels malveillants ni l’examen des fichiers d’un répertoire. Les caractères génériques et les variables peuvent être utilisés dans les chemins de fichiers et de dossiers, mais pas indistinctement pour SHA256 ou Signer. Pour les lecteurs réseau mappés, utiliser le chemin UNC d’origine ; pour les dossiers locaux mappés avec subst, utiliser le chemin local d’origine. La lettre du lecteur mappé ne constitue pas ici un chemin de stratégie fiable. Enregistrer après chaque entrée, dans la boîte de dialogue puis sur la page de la stratégie, et revérifier son effet dans le pilote.

Vérifier l’effet et tester le blocage de manière ciblée

Ouvrir My Products > Server > Servers, sélectionner le serveur pilote et vérifier à nouveau, dans l’onglet Policies, que la stratégie pilote SUFP est appliquée. Examiner aussi Events et, en cas de blocage, les entrées récentes de Summary : l’onglet Policies confirme la stratégie appliquée, tandis que les événements attestent les exécutions observées ou les blocages effectifs. La liste des événements indique notamment l’heure, l’événement et, le cas échéant, Details. Pour une période définie, utiliser Reports > General Logs > Events. Avec EDR ou XDR, les administrateurs habilités peuvent obtenir des précisions supplémentaires au moyen de leurs propres requêtes Live Discover sur sophos_unauthorized_actions_journal ; cela n’est ni nécessaire à la procédure de base ni une garantie que toutes les installations disposent des mêmes données de requête.

Une fois les opérations légitimes observées en mode surveillance et les autorisations nécessaires justifiées, passer uniquement la stratégie pilote à Block execution of unauthorized file, puis vérifier de nouveau dans Policies qu’elle s’applique au serveur pilote. Test positif : Répéter le processus d’application ou de mise à jour approuvé, précédemment observé en mode surveillance. Il doit continuer à fonctionner sans produire de blocage inattendu ; si aucune exécution n’est volontairement bloquée, aucun événement de blocage n’est requis. Test négatif facultatif : Uniquement dans un environnement pilote isolé et après autorisation, exécuter un fichier PE inoffensif, réservé à ce test et non autorisé, dont l’exécution non autorisée a déjà été observée sous forme d’événement en mode surveillance. N’attendre un événement de blocage correspondant sur le bon serveur que si une exécution est effectivement bloquée ; dans le cas contraire, ne pas conclure sans vérification que le blocage fonctionne, mais contrôler les paramètres et la réputation. Ne tester ni avec un logiciel malveillant ni en déclenchant par inadvertance une opération de production. Lors d’un blocage, une notification du Sophos Endpoint Agent peut également apparaître ; sur un serveur sans surveillance directe, la console ou l’événement constitue le moyen de vérification le plus fiable.

Critères de validation avant élargissement : La stratégie activée est appliquée, avec le bon nom et le bon type, dans l’onglet Policies de chaque serveur pilote ; les services et programmes d’installation nécessaires fonctionnent encore après les mises à jour ; les événements inattendus ont été examinés ; et une personne est chargée des nouvelles demandes d’autorisation. Le test négatif facultatif est documenté séparément : son événement de blocage n’est pas une condition de réussite du test positif. Élargir le périmètre progressivement après ces vérifications. Ne pas reprendre sans examen, à l’échelle du tenant, toutes les autorisations suggérées par les événements du mode surveillance.

En cas de blocage : identifier la cause et annuler la modification

Si un service ne démarre pas ou si une installation MSI échoue, commencer par recouper l’heure et le serveur avec Events. Vérifier que l’événement relève bien d’Unauthorized File Protection, identifier le chemin PE concerné et déterminer si une autre stratégie, le contenu du MSI ou un autre mécanisme de protection pourrait être en cause. Vérifier ensuite l’attribution réellement appliquée, le chemin (UNC plutôt que lecteur mappé), la réputation, les entrées de blocage et les autorisations ciblées existantes. Ne pas autoriser sans examen tout un dossier d’installation parce qu’un seul fichier PE a été signalé.

Pour annuler les modifications apportées à sa propre stratégie pilote, remettre la stratégie pilote documentée sur Monitor execution of unauthorized files without blocking, supprimer de manière ciblée les entrées d’autorisation ou de blocage inadaptées ajoutées pendant le pilote et rétablir le périmètre ou l’attribution d’origine à partir des notes prises auparavant. Enregistrer, vérifier dans l’onglet Policies de chaque serveur concerné que la stratégie effectivement appliquée correspond à l’état initial documenté, refaire le test du processus applicatif et surveiller les nouveaux événements. Cette procédure annule la modification de stratégie ; elle ne promet ni de restaurer les fichiers déjà modifiés, ni d’annuler automatiquement une installation MSI ou une migration depuis l’ancien Lockdown. Si le service ne refonctionne pas même en mode surveillance ou si l’hôte est encore verrouillé, ne pas improviser d’autres interventions sur Lockdown ou l’agent : conserver l’état et les événements, puis clarifier ce cas précis avec le support Sophos et l’équipe chargée de la migration distincte de l’ancien système.