Configurer Server Data Collection and Investigation dans Sophos

La stratégie Server Data Collection and Investigation dans Sophos Fusion (anciennement Sophos Central) contrôle deux fonctions distinctes : Upload to the Data Lake transmet la télémétrie des serveurs pour les enquêtes ultérieures ; Allow Live Response connection to servers autorise un accès direct et privilégié à un serveur. Cette stratégie s’applique aux serveurs Windows et Linux. Activer l’envoi des données n’autorise pas à lui seul une session Live Response, et autoriser Live Response ne remplace pas les données du Data Lake.

En bref : Vérifier la licence et le rôle d’administration donnant accès à Server Protection dans son propre tenant. Sous My Products > Server > Policies > Data Collection and Investigation, relever les stratégies de base et personnalisées, leurs attributions et l’état des deux options. Attribuer une stratégie dédiée à un groupe pilote ; vérifier, sur un serveur pilote et sur un serveur sensible hors pilote, la stratégie effectivement appliquée et l’état des deux options. Décider ensuite seulement si l’envoi des données et Live Response sont autorisés dans le périmètre voulu.

Définir les prérequis et le périmètre

Avant toute modification, vérifier le contrat Server Protection concerné, les fonctions disponibles dans le tenant et le mode de l’agent sur les serveurs pilotes. Selon Sophos, Live Response nécessite EDR, XDR ou MDR ; la présence d’un bouton ne prouve pas qu’un contrat ou un serveur donné y donne droit. Les requêtes Data Lake et les fonctions d’investigation disponibles doivent également être vérifiées à partir de la licence réelle et de l’interface du tenant. Modifier une stratégie ne crée pas une licence manquante. Les principes de licence Sophos Fusion aident à comprendre le contexte, sans remplacer la vérification du contrat concerné.

La Base Policy s’applique initialement à tous les serveurs qui ne sont pas couverts par une stratégie de priorité supérieure. Des stratégies supplémentaires permettent de traiter différemment certains groupes. Par exemple, un petit groupe SRV-Investigation-Pilot, dont les membres sont suivis avec soin, reçoit sa propre stratégie Data Collection. Le nom est libre ; ce qui compte, ce sont les membres réels, l’attribution et l’ordre des stratégies. Une stratégie générale placée au-dessus de celle du pilote peut prévaloir sur ses paramètres. Sophos convertit automatiquement les anciennes exclusions de Live Response et de l’envoi des données en stratégies personnalisées où la fonction correspondante est désactivée. Une stratégie pilote seule ne limite ni l’envoi des données ni Live Response au groupe pilote : sur les serveurs hors pilote, l’envoi des données, activé par défaut, et, avec MDR, l’autorisation Live Response, également activée par défaut, peuvent rester en vigueur. Si seules les machines pilotes doivent bénéficier de ces fonctions, prévoir et vérifier des paramètres désactivés adaptés dans les stratégies effectivement appliquées aux autres serveurs. Ne pas modifier la Base Policy à la légère : elle touche tous les serveurs auxquels elle s’applique par défaut ; par ailleurs, un groupe de serveurs ne restreint pas le droit d’un administrateur à démarrer une session.

Pour modifier les deux paramètres de la stratégie, il faut être Super Admin ou disposer d’un rôle personnalisé doté de Manage Data Collection and Investigation settings for servers. Le démarrage ultérieur d’une session requiert un droit distinct, Start Live Response sessions on servers ; les droits sur les ordinateurs ne s’étendent pas automatiquement aux serveurs. Pour le rôle permettant les sessions, Sophos indique comme rôle de base Full ou Help desk, avec Full access to Server Protection et le droit de session sur les serveurs. Vérifier dans le tenant le rôle d’administration réel et son accès à Server Protection ; attribuer une stratégie ne confère aucun droit d’administration. L’attribution et le contrôle de ces droits relèvent des rôles d’administration, et non d’un octroi systématique du rôle Super Admin.

Configurer la stratégie de façon ciblée

1. Sous My Products > Server > Policies, ouvrir le type Data Collection and Investigation. Avant toute modification, consigner pour la stratégie de base et toutes les stratégies personnalisées concernées la valeur actuelle des deux options, les groupes et serveurs cibles, ainsi que l’ordre des stratégies. Relever les paramètres effectifs sur un serveur pilote et sur un serveur sensible représentatif hors du groupe pilote. Si un pilote distinct est nécessaire, créer avec Add Policy une autre stratégie de ce type et l’attribuer au groupe de serveurs vérifié au préalable. Ne pas modifier la Base Policy pour un simple test : cela pourrait toucher tous les autres serveurs.
2. Ouvrir la stratégie pilote et accéder à Settings. Régler Upload to the Data Lake selon la collecte de données autorisée. Selon Sophos, l’envoi est activé par défaut. Si le comportement des serveurs pilotes diffère, vérifier d’abord la stratégie effectivement appliquée et les anciennes exclusions éventuelles.
3. N’activer Allow Live Response connection to servers que si le processus de réponse aux incidents et l’accès privilégié aux serveurs ont été approuvés. Selon Sophos, Live Response est activé par défaut avec Sophos MDR et désactivé par défaut dans les autres cas. Ne pas prendre cette valeur par défaut pour l’état réel ou une preuve de licence : vérifier la stratégie effective sur le serveur cible. Pour les serveurs sensibles qui ne doivent pas autoriser d’accès direct, attribuer à un groupe distinct une stratégie sans Live Response.
4. Enregistrer les paramètres, puis vérifier sur le serveur pilote la stratégie pilote active, sa priorité et son attribution réelle. Vérifier aussi les deux options effectivement appliquées au serveur hors pilote ; le périmètre souhaité du pilote n’est démontré que si ces résultats correspondent aux attentes. Une modification ultérieure d’une stratégie partagée touche également les autres groupes auxquels elle est attribuée.

L’envoi des données et l’investigation directe ne sont pas interchangeables. Désactiver l’envoi limite les transmissions futures selon la stratégie effective, mais ne supprime pas les données déjà transmises et réduit la visibilité historique disponible pour les enquêtes futures. Autoriser Live Response ouvre, en revanche, un accès puissant au système en cours d’exécution. Documenter séparément chaque décision, sa finalité, les personnes responsables et sa date de révision. Sur un grand nombre de serveurs, activer l’envoi peut augmenter brusquement le trafic réseau ; surveiller donc le pilote et la capacité de la liaison avant un déploiement étendu.

Vérifier les effets sans risque et reconnaître les limites

Sous My Products > Server > Servers, vérifier les serveurs pilotes et leur appartenance au groupe. Sous Server Groups, ouvrir le groupe pilote et consulter dans Policies les stratégies activées et appliquées ; puis relever la stratégie effective et l’état des deux options sur le serveur pilote identifié et sur un serveur sensible hors pilote. L’appartenance au groupe ne prouve pas, à elle seule, le paramétrage effectif d’un serveur donné.

Pour vérifier l’envoi au Data Lake, choisir explicitement Data Lake Queries sous Threat Analysis Center > Live Discover, et non Endpoint Queries. Choisir une requête prédéfinie existante, compatible avec le système d’exploitation et une source de données appropriée, et limiter la période interrogée. Les requêtes Data Lake incluent toujours tous les appareils ; le Device Selector ne limite que les requêtes Endpoint et ne restreint pas les requêtes Data Lake aux serveurs pilotes. Si la requête fournit l’identifiant de l’appareil et un horodatage, n’évaluer que les résultats correspondant au serveur pilote connu par son nom et à une période pertinente postérieure à la modification ; des résultats couvrant tout le tenant ou des lignes anciennes ne prouvent pas que ce serveur transmet actuellement ses données. Sans identification de l’appareil ni données temporelles adéquates, cette requête ne convient pas comme preuve pour le pilote. L’absence de résultats ne prouve pas non plus, à elle seule, un défaut de transmission : vérifier la licence et la disponibilité de la fonction, l’état du serveur, la stratégie effective, l’option d’envoi, le schéma et la période, puis solliciter le support si nécessaire. Une Endpoint Query directe réussie peut lire les Event Journals locaux, mais ne prouve pas l’envoi au Data Lake. Ne pas créer d’événement de test contenant de vraies données personnelles, des identifiants de production ou un programme malveillant factice. Le guide Live Discover et Data Lake explique les sources, la conservation des données et les requêtes sûres.

Les Event Journals existent aussi sur les serveurs administrés, mais ne sont pas équivalents à un envoi au Data Lake. Pour les limites des journaux côté serveur, sous Global Settings > Products and Services > Endpoint and Server > Event Journals, choisir l’onglet Server (distinct de l’onglet Endpoint) ; ces limites ne se définissent pas serveur par serveur. Selon Sophos, ce réglage nécessite XDR, MDR ou MDR Plus. Réduire les limites peut évincer les anciennes données des journaux ; il ne s’agit pas d’un interrupteur réservé à un seul groupe de serveurs pilotes. Le diagnostic détaillé des journaux et des requêtes figure dans le guide Live Discover cité plus haut.

Pour Live Response, une stratégie active ne suffit pas non plus : la licence, le rôle d’administration avec accès à Server Protection, le droit de démarrer une session, l’accessibilité du serveur cible et un objectif d’investigation approuvé doivent tous être réunis. Dans le cadre d’un test autorisé, vérifier l’accès uniquement sur le serveur pilote identifié sans ambiguïté et sans exécuter de commande modificatrice, puis fermer la session. Faire contrôler les preuves d’audit dans le processus de réponse aux incidents par une personne habilitée : le seul droit de session serveur ne permet pas de télécharger le journal détaillé de la session ; Sophos exige pour cela le rôle Super Admin ou un rôle personnalisé doté à la fois de Manage Live Response settings for computers et de Manage Live Response settings for servers. Le runbook sur l’isolation et Live Response décrit la conduite des sessions, la MFA et les droits d’audit. Ne pas appliquer sans vérification aux serveurs ses étapes d’isolation destinées aux endpoints.

Si le pilote ne se comporte pas comme prévu : arrêter toute nouvelle autorisation et fermer la session de test. Rétablir uniquement les valeurs initiales documentées, les attributions de groupes et l’ordre de la stratégie pilote, puis revérifier les deux options effectives sur des serveurs pilotes et hors pilote. Ne pas simplement supprimer la stratégie pilote si cela risque d’activer l’envoi des données ou Live Response sur des serveurs sensibles par l’effet de la Base Policy ou d’autres stratégies. Il s’agit d’une procédure opérationnelle de retour à l’état initial fondée sur la priorité des stratégies et la séparation des deux options, et non d’une annulation Sophos en un clic. Elle ne récupère pas les données déjà transmises au Data Lake et n’annule pas les actions réalisées pendant une session Live Response ; examiner séparément la conservation ou la suppression des données selon les règles applicables.

Sous Exclusions dans la stratégie serveur se trouve également une Event collection exclusion : elle arrête la collecte d’événements pour les journaux Sophos et le Data Lake, ce qui peut limiter les possibilités de détection et d’investigation. Sophos demande de n’utiliser cette exclusion que sur instruction du support. Elle n’est pas disponible sous Global Exclusions et ne remplace pas la décision d’envoi propre à un groupe. Aucune procédure d’exclusion de fichiers ou de processus n’est volontairement recommandée ici. Pour toute décision liée à la confidentialité des données ou à la bande passante, convenir d’abord du périmètre, des droits, de la conservation et de l’objectif d’investigation nécessaire ; ne pas mettre en place d’exclusion de collecte d’événements sans instruction du support.