Sophos Mobile : analyser un incident de conformité et vérifier l’accès Wi-Fi
Face à une alerte de conformité, commencer par lire les informations, sans relancer immédiatement une vérification ni bloquer l’accès. Sophos Mobile ne bloque pas à lui seul l’accès au réseau ; une restriction Wi-Fi dépend de la configuration de Sophos Wireless. Ce guide décrit une démarche de vérification et de décision, pas une autorisation d’exécuter des commandes dans un environnement Sophos donné.
Décision pendant l’incident : consulter, qualifier, transmettre
- Lecture seule – consigner les constatations : Identifier l’appareil concerné et la politique qui lui est attribuée, la règle enfreinte et l’horodatage sous Compliance ; examiner Events séparément. Dans le canal d’incident approuvé, selon ses règles d’accès et de conservation, ne consigner que les identifiants d’appareil autorisés, les dates et heures des règles et événements, la politique pertinente et le strict minimum de constatations techniques nécessaires. Ne pas recueillir de contenu de fichiers privés, d’inventaires d’applications, de captures d’écran ou d’exports complets de l’appareil sans nécessité distincte et autorisation.
- Lecture seule – qualifier les effets : Ne pas assimiler une détection d’application à une non-conformité ni à un blocage Wi-Fi effectif. Vérifier la plateforme, le mode de gestion, la licence et l’édition confirmées, l’action associée à la règle, l’état de l’intégration et la correspondance des adresses MAC ; évaluer l’effet sur le Wi-Fi uniquement à partir de l’appareil concerné et du point d’accès/client correspondant.
- Arrêt avant toute modification : Check now, la correction des politiques et l’activation du NAC à l’échelle du tenant ne font pas partie du tri initial ; transmettre au responsable des politiques ou au responsable Wireless/réseau compétent. N’envisager des dérogations manuelles qu’avec une autorisation propre à l’appareil, la valeur initiale documentée et l’effet attendu. Après une mesure autorisée, confirmer séparément l’état de l’appareil et son accès réel via le point d’accès/client.
Lecture seule : distinguer règle et événements
Identifier l’appareil cible autorisé, la personne à laquelle il est attribué et, séparément, son propriétaire, ainsi que la plateforme, la licence et l’édition Sophos Mobile, les modes d’inscription et de gestion, le groupe d’appareils, la politique et la dernière synchronisation. Pour un appareil personnel, limiter les vérifications au périmètre de gestion approuvé.
Dans Sophos Fusion > My Environment > Mobile Devices, cliquer sur le nom de l’appareil autorisé et ouvrir l’onglet Compliance. Pour un appareil géré par Sophos Mobile, cet onglet affiche le détail des violations de conformité lorsque l’appareil n’est pas conforme. Un appareil devient non conforme lorsqu’il enfreint une règle de sa politique de conformité. La politique applicable à l’appareil cible est celle attribuée à son groupe d’appareils pour son type de propriété : Compliance policy (corporate) pour les appareils professionnels et Compliance policy (personal) pour les appareils personnels. Vérifier en lecture seule que le type de propriété de l’appareil correspond à l’attribution du groupe ; les deux champs peuvent contenir des politiques différentes.
Dans la liste, Severity indique la gravité de la violation de conformité, avec les valeurs High, Medium ou Low. Type désigne la règle enfreinte et Info en fournit les détails. Created at indique quand la violation de conformité a été détectée. Par exemple, si la politique contient la règle Minimum OS version et que la version du système d’exploitation de l’appareil est antérieure à celle exigée, Type affiche OS version too old. Info indique la version requise et la version réelle du système d’exploitation. Cela permet de comparer l’exigence à l’état de l’appareil sans abaisser la version minimale en première réponse.
L’icône Refresh en haut à droite recharge les informations de l’onglet Compliance. Cela ne prouve ni une nouvelle analyse de l’appareil ni la réception d’une mesure. Au besoin, filtrer la liste Compliance à l’aide des filtres de gravité situés au-dessus de la liste ; choisir les niveaux en fonction de l’incident concerné, sans reprendre la sélection donnée en exemple.
Sur la même page de l’appareil, ouvrir l’onglet Events. Il affiche les événements associés à l’appareil géré par Sophos Mobile. Event contient le texte de l’événement et Severity sa gravité, avec les valeurs High, Medium, Info ou None. Ces valeurs ne correspondent pas à l’échelle de conformité. Created at indique quand Sophos Mobile a créé l’événement, et non quand une violation de conformité a été détectée. Cet horodatage ne prouve pas qu’une correction a eu lieu. Distinguer également le résultat de la vérification de l’état réel de l’appareil.
L’icône Refresh en haut à droite recharge les informations de l’onglet Events ; ici non plus, cela ne prouve ni une nouvelle analyse de l’appareil ni la réception d’une mesure. Au besoin, filtrer la liste Events par date de création à l’aide des filtres situés au-dessus de la liste et consigner la référence temporelle choisie dans les constatations. Pour consulter les événements de tous les appareils, ouvrir Reports > General Logs > Events.
Android Enterprise en gestion intégrale de l’appareil : Selon Sophos, lorsqu’un tel appareil devient non conforme, toutes ses applications sont désactivées. Ne pas généraliser cet effet à Android avec profil professionnel ni à Mobile Threat Defense seul. Établir le mode de gestion et les actions possibles des règles avant toute nouvelle vérification.
Check now n’est pas Refresh : La vérification de conformité dans Sophos Mobile et Mobile Threat Defense examine tous les appareils inscrits et exécute les actions configurées. La documentation des politiques de Sophos Mobile Device Management et de l’édition combinée Sophos Mobile décrit notamment le transfert de lots de tâches ; des lots mal employés peuvent effacer des appareils. En revanche, la page de création de politiques de Sophos Mobile Threat Defense affiche Create alert. Avant toute action, confirmer la licence réelle, l’interface d’administration, le rôle, la plateforme et le mode auprès du responsable des politiques ; ne pas lancer Check now comme test improvisé.
Lecture seule : examiner séparément la détection d’application et l’effet sur le Wi-Fi
Détection d’application : Pour Sophos Intercept X for Mobile géré par Sophos Mobile sous Android, distinguer application malveillante, application potentiellement indésirable (PUA), fichier et application de faible réputation. Une application malveillante détectée est bloquée ; une PUA déclenche par défaut un avertissement sur l’appareil, mais la politique et les exceptions peuvent modifier ce comportement. L’analyse des applications de faible réputation est désactivée par défaut ; si elle est activée, Apps with low reputation contrôle l’avertissement ou le blocage de l’accès. L’incidence des détections d’applications et de PUA sur la conformité est définie séparément par Malware apps allowed et PUAs allowed. Ne pas transposer ces effets de détection Android à iOS.
La politique de protection Android permet de vérifier les différents paramètres en lecture seule. Si Detect PUAs est désactivé, aucune analyse des PUA n’est effectuée. Enable user to allow PUAs permet à l’utilisateur d’autoriser une application, qui sera alors ignorée lors des analyses PUA ultérieures. L’App group sélectionné peut exclure certaines applications de l’analyse des PUA ou de la réputation. Ces exceptions ne corrigent pas une détection et ne constituent pas une première réponse à l’incident. Comparer la détection précise, la règle et les paramètres de la politique : un avertissement PUA ne prouve ni la présence d’un logiciel malveillant ni un blocage Wi-Fi.
Fichiers malveillants : Scan storage est désactivé par défaut. Lorsqu’il est activé, IXM avertit sur l’appareil en cas de détection, mais ne bloque pas le fichier et ne le nettoie pas automatiquement. Pour le retirer, la personne concernée doit le supprimer manuellement. Ne pas faire supprimer systématiquement les fichiers suspects ; n’indiquer à la personne concernée une éventuelle suppression qu’après autorisation propre à l’appareil, examen des éléments de preuve nécessaires et du risque de perte de données. Ne pas recueillir systématiquement le contenu de fichiers privés à titre de preuve.
L’intégration est-elle active ? Avec Synchronized Security, les produits Sophos échangent des informations de sécurité par le Security Heartbeat. Sophos Wireless peut utiliser l’état de conformité Sophos Mobile des appareils Android et iOS pour restreindre l’accès au réseau ; cette restriction exige qu’une règle d’accès fondée sur l’état de santé y soit configurée. Pour cette intégration Wireless documentée, Sophos cite exclusivement APX 320, APX 530 et APX 740. Uniquement si un environnement existant utilise cette intégration, vérifier les points d’accès qui y sont enregistrés dans Sophos Fusion, la règle Wireless, l’activation de l’intégration NAC et l’attribution d’une politique de conformité au groupe d’appareils. Cette dépendance à l’ancienne gamme APX dépasse le cadre du contrôle Mobile et ne constitue pas une recommandation de nouvelle installation APX. Un état de santé Mobile ou une intégration NAC Mobile activée ne prouve ni la présence de cette intégration sur AP6 ni sa prise en charge sur cette gamme. Le réglage Setup > Sophos setup > Network Access Control > Sophos Wireless > Save modifie tout le tenant : ce n’est pas une étape de tri en lecture seule.
Cet appareil peut-il être identifié ? Synchronized Security peut aussi être utilisé avec des appareils inscrits par une solution EMM tierce : la configuration personnalisée de l’application Intercept X for Mobile doit alors contenir l’adresse MAC de l’appareil pour que le point d’accès Sophos APX Series puisse l’identifier. Cela ne démontre pas que l’identification fonctionne sur le Wi-Fi concerné. Une adresse MAC absente ou propre à un réseau empêche l’identification prévue. La documentation de Device Management et de l’édition Mobile combinée cite comme restrictions les Chromebooks, Apple User Enrollment et les appareils utilisant Private address ou Randomized MAC ; la page Threat Defense cite les Chromebooks et les adresses MAC privées/aléatoires, mais ne mentionne pas expressément Apple User Enrollment. Ne pas en déduire que ce mode est pris en charge dans Threat Defense. Dans la documentation de Device Management et de l’édition Mobile combinée, Set network access exclut aussi les Mac et Apple User Enrollment.
Quelle édition et quelle action de règle sont établies ? Selon la page Synchronized Security, la politique de conformité définit l’état de santé attribué à un appareil en cas de non-conformité ; des états différents peuvent être définis pour chaque règle. En revanche, la page de création de politiques de Sophos Mobile Threat Defense n’affiche que Create alert. Le passage automatique d’une règle MTD à un état de santé, puis à un blocage Wi-Fi, n’est pas établi ici et ne doit pas être présumé comme mesure d’intervention. Clarifier la licence et l’édition, l’interface d’administration et l’action de règle réellement disponible avec les responsables des politiques et Wireless/réseau.
Uniquement après autorisation : modifications strictement limitées
Avant toute modification par le rôle habilité, documenter l’appareil cible, la licence et l’édition, la plateforme et le mode, les dérogations manuelles existantes, les valeurs initiales des deux paramètres, l’effet attendu, la réception de la mesure et la méthode de vérification. Les modifications de politiques et Check now relèvent du responsable des politiques ; le guide consacré à la planification et à la vérification des politiques de conformité décrit cette tâche distincte, mais n’accorde aucune autorisation opérationnelle. L’intégration NAC et les règles Wireless relèvent du responsable Wireless/réseau. Une autorisation propre à l’appareil pour les dérogations décrites ci-dessous n’autorise ni la modification des politiques, ni l’activation du NAC à l’échelle du tenant, ni la modification des règles Wireless.
Modification NAC à l’échelle du tenant : Uniquement si l’intégration Wireless documentée s’applique à l’environnement existant, le responsable Wireless/réseau compétent ouvre, après une autorisation distincte, l’onglet Network Access Control sous Setup > Sophos setup. Avant toute modification, il consigne dans le suivi des modifications la sélection d’intégration antérieure effectivement enregistrée dans cet onglet et la sélection cible approuvée, séparément des dérogations d’accès réseau et d’état de santé propres aux appareils. La procédure Sophos Turn on Synchronized Security documente uniquement l’activation, pas le retour à la configuration précédente. Vérifier donc avant l’activation que la sélection antérieure peut être à nouveau choisie dans l’interface réelle et que sa restauration est documentée comme prise en charge pour cet environnement. Si cette possibilité de retour n’existe pas ou reste incertaine, ne pas activer, mais clarifier la situation avec le responsable Wireless/réseau et Sophos Support. Si ces conditions sont remplies, sélectionner Sophos Wireless et enregistrer avec Save ; rouvrir ensuite l’onglet Network Access Control et comparer la sélection enregistrée à la cible approuvée. Vérifier séparément l’accès réel des clients Wireless concernés via le point d’accès/client correspondant : ni Save ni un état de santé ne prouve l’effet sur le Wi-Fi.
Retour à la configuration NAC précédente : En cas d’écart, arrêter toute modification supplémentaire. Uniquement après autorisation et si la procédure de retour est confirmée et documentée comme prise en charge, sélectionner à nouveau, dans le même onglet, exactement la sélection d’intégration consignée auparavant, enregistrer avec Save, puis rouvrir l’onglet et comparer à la valeur initiale ; vérifier à nouveau séparément l’accès via le point d’accès/client concerné. Si la sélection antérieure n’est pas disponible ou si sa restauration n’est pas documentée comme prise en charge, ne pas supposer qu’une désélection, une commande de désactivation ou une réinitialisation permet le retour à la configuration précédente, mais faire remonter le problème au responsable Wireless/réseau et à Sophos Support. Auto mode et l’annulation des dérogations des appareils ne rétablissent pas la sélection NAC à l’échelle du tenant. Ces précautions constituent un plan préventif de vérification et de retour à la configuration précédente ; elles n’ont été testées ni dans un tenant ni en laboratoire et ne prouvent pas qu’une restauration a réussi.
- Accès réseau (documentation de Sophos Mobile Device Management et de l’édition Mobile combinée ; confirmer la disponibilité dans l’environnement concerné) : Après autorisation propre à l’appareil et documentation de la valeur initiale :
- Ouvrir Devices et sélectionner dans la liste uniquement l’appareil cible identifié et autorisé. Vérifier que la sélection correspond à l’autorisation ; ne sélectionner plusieurs appareils qu’après vérification explicite de la liste et autorisation.
- Choisir Actions > Set network access.
- Sélectionner la valeur autorisée : Allow autorise l’accès indépendamment de la conformité, Deny le refuse indépendamment de celle-ci ; Auto mode lie l’accès à la conformité. Allow peut contourner une règle de sécurité et ne corrige pas la non-conformité.
- Vérifier de nouveau la sélection des appareils et la valeur choisie, puis enregistrer avec Yes. Vérifier ensuite séparément la valeur d’accès réseau enregistrée, l’état de l’appareil et l’accès réel via le point d’accès/client ; la confirmation seule ne prouve pas un effet sur le Wi-Fi.
- État de santé (Mobile ou Threat Defense avec Synchronized Security activé ; confirmer les droits et la disponibilité) : Après autorisation propre à l’appareil et documentation de la valeur initiale :
- Ouvrir Devices dans la barre de menus et cliquer sur le nom de l’appareil identifié et autorisé.
- Sur la page Show device, choisir Actions > Set health status.
- Sélectionner l’état de santé autorisé. Red peut être défini manuellement indépendamment de la conformité ; Auto mode annule uniquement cette dérogation manuelle sur l’état de santé et recalcule cet état à partir de la conformité.
- Sophos Mobile transmet l’état de santé de l’appareil à Sophos Wireless. La règle Wireless détermine si un blocage peut s’appliquer ; vérifier donc séparément l’état réel de l’appareil et l’accès via le point d’accès/client. Pour plusieurs appareils, les sélectionner sur la page Devices, puis choisir Actions > Set health status. Cette opération exige une vérification explicite de la liste des appareils et une autorisation.
Annulation des dérogations des appareils : Pour chacun des deux paramètres de l’appareil, rétablir la valeur précédemment documentée ; n’utiliser Auto mode que si c’était sa valeur initiale. Pour l’accès réseau, reprendre dans Devices la même sélection d’appareils vérifiée, ouvrir Actions > Set network access, choisir la valeur initiale documentée, puis enregistrer avec Yes après une nouvelle vérification de la sélection et de la valeur. Vérifier ensuite de nouveau la valeur d’accès réseau enregistrée et l’accès réel via le point d’accès/client. Annuler une dérogation sur l’état de santé n’annule pas une dérogation distincte Allow/Deny et ne résout pas la non-conformité. Observer séparément la réception de la mesure, l’état réel de l’appareil et l’accès via le point d’accès/client ; un état vert ne prouve pas une connexion Wi-Fi.
Suivre la cause et le résultat – exclure les mesures destructrices
Avec Sophos Mobile Control, la personne concernée peut recevoir une notification et voir les non-conformités dans son tableau de bord avec Fix it. Le lien du Self Service Portal n’apparaît que pour les types d’appareils pris en charge ; la documentation ne précise pas les types exclus. Son absence ne prouve pas la conformité. Intercept X géré sous Android ou iOS peut afficher la non-conformité et des indications ; des restrictions réseau ou fonctionnelles sont possibles, non garanties. Vérifier les consignes destinées à l’utilisateur au regard de la règle précise. Une action dans l’application n’annule pas une dérogation administrative.
Afficher les non-conformités dans Intercept X sous Android et iOS
Lorsque Sophos Intercept X for Mobile sous Android ou iOS est géré par Sophos Mobile, le tableau de bord local de l’application affiche l’état de conformité selon la politique de l’organisation. La personne concernée ouvre les indications sur son appareil comme suit :
- Dans le tableau de bord, appuyer sur la tuile Corporate management. En cas de non-conformité, cette tuile présente une icône rouge.
- Appuyer sur la non-conformité concernée pour ouvrir les consignes correspondantes. Avant de les suivre, vérifier ces indications au regard de la règle précise et de l’autorisation propre à l’appareil. Clarifier les mesures incertaines ou risquées avec le responsable des politiques. Si les mesures sont autorisées, suivre les consignes affichées pour corriger cette non-conformité.
L’icône rouge appartient à la tuile Corporate management. Sous Android, la distinguer de l’évaluation Insecure sous Device security ; sur les deux plateformes, elle ne prouve ni un état de santé Red défini manuellement ni un blocage Wi-Fi effectif. Ouvrir les indications ne corrige aucune non-conformité et n’annule aucune dérogation administrative. Suivre les consignes ne garantit pas non plus la correction ni le rétablissement de l’accès Wi-Fi ; les vérifications des résultats décrites ci-dessous restent nécessaires. Ce parcours s’applique à l’application gérée sous Android et iOS, et non à Sophos Mobile Control ou au Self Service Portal.
Afficher les non-conformités dans le Self Service Portal
Cette procédure s’adresse à la personne concernée dans le Self Service Portal ; elle ne décrit pas des actions dans Mobile Admin :
- La personne concernée se connecte au Sophos Central Self Service Portal, ouvre Mobile et sélectionne son propre appareil concerné.
- À côté de Compliance Status, elle clique sur le lien Noncompliant pour afficher les non-conformités. Ce lien n’est disponible que si l’appareil n’est pas conforme. La restriction aux types d’appareils pris en charge mentionnée ci-dessus s’applique également.
Pour que l’appareil redevienne conforme, la personne concernée doit effectuer les mesures nécessaires sur son appareil. Avant de lui donner ces consignes, vérifier les non-conformités affichées au regard de la règle précise et clarifier l’autorisation propre à l’appareil. Ouvrir le lien ne corrige aucune non-conformité, n’annule aucune dérogation administrative et ne prouve pas que l’accès Wi-Fi a été rétabli. Clarifier les mesures incertaines ou risquées avec le responsable des politiques compétent, plutôt que de contourner les exigences de protection ou de déclencher des mesures destructrices. Les vérifications ultérieures des résultats restent nécessaires et doivent être effectuées séparément.
En cas de possible fausse alerte, comparer la règle, les exceptions, l’appartenance au groupe, le seuil de version du système d’exploitation, le minimum nécessaire d’informations sur la détection d’application, la synchronisation, les autorisations pertinentes, la correspondance des adresses MAC et les dérogations existantes avec les données d’incident approuvées. Faire corriger de manière ciblée une évaluation erronée de la politique uniquement par son responsable. Après une correction autorisée, consulter de nouveau Compliance, Events et, le cas échéant, l’application de l’utilisateur ; vérifier séparément l’accès Wi-Fi réel auprès du point d’accès/client correspondant. Si l’état reste contradictoire, faire remonter l’incident avant toute autre modification.
Arrêt avant toute mesure destructrice : Wipe, Factory Reset, la suppression de l’entrée de l’appareil, Unenroll, la suppression du profil professionnel et le transfert de lots de tâches ne sont pas des réponses initiales et ne peuvent pas être annulés par Auto mode. Ces mesures relèvent d’une procédure distincte et autorisée : en cas de perte d’appareil, le brouillon consacré à la décision de sécurité en cas de perte d’appareil aide à évaluer la situation avant toute autorisation ; en cas de changement ou de suppression d’utilisateur, l’attribution des utilisateurs et l’offboarding doivent être examinés séparément. Aucun de ces renvois n’accorde d’autorisation propre à l’appareil. Chaque procédure exige la vérification de la propriété et des données privées, du mode de gestion, de la sauvegarde et de l’autorisation relative à la perte de données, d’Android FRP ou d’Apple Activation Lock, des accès nécessaires à la récupération, ainsi que de la réception de la commande et de son achèvement constaté. Réessayer une suppression est particulièrement dangereux : supprimer un appareil Android Enterprise inscrit et entièrement géré peut déclencher une réinitialisation d’usine. La portée de Wipe dépend de la console et du mode ; pour Android avec profil professionnel, Fusion décrit la suppression du profil professionnel, et non une réinitialisation d’usine systématique. Le Lock à distance n’est pas un test d’incident de conformité : sur un appareil Android Enterprise avec profil professionnel, il verrouille l’appareil entier, pas seulement le profil ; un Mac verrouillé à distance ne peut ensuite pas être effacé par Wipe. Sans autorisation propre à l’appareil, s’arrêter ici.