Exploiter Sophos XDR Cases et Detection Rules

Sophos XDR regroupe des Detections et les entités concernées dans des Cases pouvant être examinés. Un Case n’est pas un Incident résolu automatiquement, mais l’espace de travail commun pour les preuves, la responsabilité et la Response.

Les procédures existantes de cet article décrivent la gestion des Cases et Detection Rules dans Threat Analysis Center, la Classic view de Security Operations qui reste disponible. La section distincte sur Security Operations explique les limites actuelles de responsabilité et de statut MDR. Avant toute modification, vérifiez quelle vue votre tenant utilise. Security Operations propose aussi Cases, Detections et Detectors ; cela ne prouve pas que les mêmes statuts, rôles, délais de suppression ou règles de masquage des Detections s’y appliquent. En particulier, Detectors n’est pas assimilé aux Detection Rules de Classic décrites ci-dessous.

Dans Classic, la fonction Cases exige EDR, XDR ou MDR. Sophos crée automatiquement un Case lors d’une High Risk Detection, sauf si elle appartient déjà le même jour à un Case approprié. Des Detections ultérieures du même type peuvent être ajoutées.

Un Case Sophos-managed basé sur des MDR Detections est examiné par l’équipe MDR. Un Case Self-managed issu de XDR Detections reste sous la responsabilité du client et est attribué à un administrateur. Sophos le crée, mais ne l’examine pas automatiquement.

Cette limite de responsabilité s’applique également aux signaux NDR et aux résultats de test NDR autorisés : la source NDR ne transfère pas automatiquement un Case XDR Self-managed à Sophos MDR. L’administrateur du client en reste l’Owner jusqu’à ce que le Case soit clôturé conformément à son propre processus. Seul un Case désigné comme Sophos-managed et fondé sur des MDR Detections relève de l’équipe MDR. Le runbook consacré à la détection de test NDR explique comment corréler sans ambiguïté un résultat de test et effectuer le nettoyage nécessaire.

Detection, Alert et Case dans Classic

Plusieurs Detections peuvent appartenir à la même chaîne d’attaque. Inversement, une seule Detection inhabituelle peut déjà justifier une investigation.

Pour les Cases Self-managed, New, Investigating, On Hold et Resolved constituent le cycle complet des statuts : nouvellement créé, en cours d’investigation, temporairement suspendu ou clôturé. Les Cases Sophos-managed utilisent plutôt Investigating, Action required et Resolved. Action required signifie que le client doit agir ; Sophos en informe les contacts configurés.

Traiter un Case dans Classic

Commencez sous Threat Analysis Center > Cases. Ouvrez un Case Self-managed généré automatiquement via son Case ID. Dans Overview, utilisez le menu à côté du nom du Case pour définir la gravité. Passez ensuite le statut de New à Investigating et sélectionnez l’administrateur responsable sous Owner. S’il manque, ajoutez-le avec Add user. L’Owner peut aussi être attribué ultérieurement.

Deux méthodes officielles permettent de créer manuellement un Case Self-managed :

• Sous Threat Analysis Center > Cases > Create case > Self-managed case, saisissez un nom et une description, choisissez Severity, le statut New et éventuellement un Assignee, puis validez avec Create. Sous Threat Analysis Center > Detections, sélectionnez ensuite les résultats et utilisez Actions > Add to Case.
• Ou sélectionnez d’abord les résultats sous Threat Analysis Center > Detections, puis choisissez Actions > Create Case. Ajoutez d’autres Detections plus tard via Actions > Add to Case.

Les Cases créés manuellement ne peuvent contenir que des Sophos XDR Detections, pas de MDR ou Managed Risk Detections. Sophos recommande de limiter le nom du Case aux caractères alphanumériques, espaces et signes de ponctuation simples, car les API peuvent interpréter les caractères spéciaux comme de la syntaxe.

Pour l’investigation elle-même :

1. Lire le résumé, la gravité et la chronologie.
2. Vérifier les appareils, utilisateurs, processus, IPs et fichiers concernés.
3. Classer les techniques MITRE ATT&CK et la source de Detection.
4. Utiliser Threat Graph, Live Discover et les Enrichments disponibles.
5. Documenter les mesures de confinement telles que Isolation ou Live Response.
6. Consigner la cause, l’étendue et la décision de clôture.

Pour un Case Self-managed, conservez les notes d’investigation dans l’onglet Notebook. Les preuves et les décisions restent ainsi directement rattachées au Case.

Les résumés générés par l’IA peuvent accélérer le Triage, mais sont vérifiés par rapport aux données brutes et à la chronologie.

Detection Rules

Les règles suivantes s’appliquent à la vue Classic sous Threat Analysis Center > Detection rules, et non à Security Operations dans son ensemble. Detection Rules permet actuellement uniquement de masquer les Detections indésirables et exige un Super Admin. Une règle empêche une Detection correspondante d’apparaître dans la liste des Detections et de créer un Self-managed XDR Case. Les MDR Cases ne peuvent pas être masqués de cette manière.

Créez une règle depuis une Detection existante : Threat Analysis Center > Detections, menu à trois points à côté du nom, puis Add detection rule. Sous Rule Details, saisissez le nom et la description ; la règle est activée par défaut. Suppress est actuellement la seule option sous Actions. Sous Conditions, sélectionnez les caractéristiques du résultat existant qui doivent déclencher la règle, puis cliquez sur Save. Un tenant accepte au maximum 25 Detection Rules.

Avant d’enregistrer la règle, activée par défaut, documentez son nom, son objectif, la source de données, la fréquence attendue, l’Owner et la date de révision. Les conditions doivent identifier uniquement le déclencheur légitime confirmé, et non une simple gravité ou une caractéristique de processus trop large.

Une nouvelle règle peut mettre jusqu’à 20 minutes à prendre effet et ne s’applique qu’aux Detections créées après elle. Les conditions sont sensibles à la casse : Windows et windows peuvent être traités différemment.

Gérez les règles existantes sous Threat Analysis Center > Detection rules. Une règle peut être activée, désactivée, dupliquée ou supprimée, mais pas directement modifiée. Pour la changer, dupliquez-la et adaptez la copie via le menu à trois points, puis désactivez ou supprimez l’original après un remplacement contrôlé.

Contrôler le masquage des détections

Le masquage (Suppression) réduit les résultats connus et attendus. Il ne constitue pas un nettoyage et ne doit pas masquer une activité réelle. Chaque masquage exige :

• une condition précise plutôt qu’un motif large,
• un déclencheur légitime documenté,
• un Owner et une date de révision,
• la vérification des Detections déjà masquées.

Une console silencieuse n’est pas un signe de qualité si les règles masquent un périmètre trop large.

Pour contrôler le résultat, ouvrez Threat Analysis Center > Detections > Show filters. Sous Detection Visibility, décochez Hide Suppressed Detections, puis cliquez sur Apply. Vous voyez ainsi ce que la règle couvre réellement. Comme les règles ne sont pas rétroactives, cette vue constitue une meilleure base pour la prochaine révision que la seule diminution des résultats visibles.

Security Operations : Cases et responsabilité MDR

Cette section concerne Security Operations, pas les statuts et règles Classic précédents. Sous Security Operations > Cases, un clic sur le nom du Case ouvre d’abord le résumé. L’icône New Tab donne accès à la page de détails complète, avec Overview, Evidence, Response, History et Enrichment. Les commentaires se lisent dans le résumé, mais ne s’ajoutent que sur la page complète.

Décider de Managed By avant confirmation

Pour les Cases MDR actuels, Managed By définit qui gère le Case : Self signifie responsabilité du client ; Sophos MDR signifie gestion par l’équipe MDR. Assignee désigne en revanche l’utilisateur ou le groupe chargé de l’action suivante. Changer l’Assignee ne transfère pas la responsabilité du Case.

Sur la page de détails complète, sélectionnez la responsabilité proposée sous Manage Case > Managed By et confirmez seulement après le contrôle ci-dessus. Vérifiez ensuite la valeur affichée. Self n’est sélectionnable que pour les types de Cases MDR Investigation et Other ; Threat Hunt, Health Check et Incident sont gérés par Sophos. Le client ne crée pas d’Incident. Lors d’une création manuelle, Managed By est défini dès la création. Pour les Cases générés automatiquement par des règles Sophos, il doit être défini avant l’utilisation des commandes Manage Case. Pour les Cases issus de règles du client, il vaut automatiquement Self.

Votre équipe examine un Case Self-managed ; les modifications, actions de réponse et possibilités de scission/fusion dépendent aussi du type et des droits. Pour les Cases Sophos-managed, vous pouvez lire les détails, commenter, attribuer à Sophos et clôturer si une action de clôture est disponible. Cela n’autorise pas à changer librement le statut, modifier Key Findings, ajouter d’autres événements ou Detections comme preuves, ni scinder ou fusionner le Case.

Statuts MDR actuels et actions du client

Selon leur type, les Cases MDR actuels utilisent New, In Progress, Customer Action Required, Awaiting Sophos Assignment et Closed. Ces valeurs ne sont assimilées ni aux statuts Classic ni aux statuts XDR généraux Open, Active, Awaiting Action, Suspended et Closed. Awaiting Sophos Assignment indique que l’attribution interne à l’équipe MDR est en attente ; Customer Action Required exige au contraire une action de l’organisation.

Lorsque l’équipe MDR place un Case Sophos-managed dans Customer Action Required, le compteur d’inactivité démarre. Sans action du client, un rappel par e-mail suit toutes les 24 heures ; après cinq jours d’inactivité, le Case est clôturé automatiquement. Un commentaire, une action de réponse, un changement d’Assignee ou un nouveau lien ou une pièce jointe réinitialise le compteur. Cela ne remplace pas le travail de fond demandé : clarifiez une question avec l’équipe MDR au lieu de prolonger le délai par des modifications purement formelles. N’exécutez jamais une action de réponse uniquement pour réinitialiser le compteur.

Sur la page complète, l’icône de commentaire à droite ouvre Comments. Saisissez les informations nécessaires dans Comment et enregistrez avec Save. @sophos avertit l’équipe MDR. Après l’enregistrement, vérifiez que le commentaire figure sur le bon Case. Configurez les contacts MDR et autorisations de réponse avant un incident, pas seulement après une première demande manquée.

La clôture marque aussi les Detections associées comme résolues et leur attribue un libellé selon le verdict choisi. MDR propose True Positive – Benign, True Positive – Malicious, Inconclusive et False Positive ; pour Inconclusive, le libellé de Detection est Not Actionable. Un Case clôturé n’est pas une preuve technique de nettoyage. Vérifiez le résultat de l’investigation et les tâches du client encore ouvertes avant de clôturer.

Dans les 30 jours suivant la clôture, un Case MDR Sophos-managed peut être rouvert par un commentaire avec @sophos ; pour un Case customer-managed, changez le statut Closed. Après ces 30 jours, un nouveau Case est nécessaire. Cette limite de réouverture ne dit rien sur la suppression ou la conservation des Cases MDR actuels ; les délais Classic indiqués plus haut ou plus bas restent limités à Classic.

Rules plutôt que le seul masquage de Classic

Sous Security Operations > Rules, deux types distincts de Customization Rules existent : les Custom detection rules créent de nouvelles Detections à partir d’événements normalisés au moyen d’une requête de recherche avancée. Les Detection suppression rules résolvent les Detections correspondantes comme masquées dès leur création, afin qu’elles n’apparaissent pas par défaut dans la liste. Detectors n’est pas le même espace de gestion que ces règles.

Les Cases générés automatiquement par les règles du client sont gérés par le client et ne déclenchent pas d’investigation MDR automatique. Les limites Classic de 25 règles, l’exigence Super Admin, les 20 minutes d’attente et la duplication au lieu de la modification ne sont pas transposées à cette nouvelle interface. Cette section explique les distinctions, pas une procédure complète de création de règle personnalisée. Avant tout masquage, confirmez toujours la cause légitime et évaluez la perte de visibilité.

Clôture et retour d’expérience dans Classic

Un Case est clôturé lorsque l’étendue, la cause, le confinement, le nettoyage et la récupération sont documentés. Detection Rules, politiques, exceptions et Runbooks sont ensuite adaptés si l’investigation a révélé une lacune.

Un Case Self-managed est clôturé en lui attribuant le statut Resolved. Il reste 30 jours dans la liste, puis Sophos le supprime. Les Partner Super Admins et Enterprise Super Admins ne peuvent ni clôturer ni supprimer des Cases; cette limite de rôle doit être prise en compte avant l’attribution de l’Owner.

La télémétrie et les requêtes sous-jacentes sont expliquées dans Sophos XDR Data Collection et Live Discover.

Questions fréquentes

Le parcours actuel complet sous Security Operations > Rules est décrit dans Exploiter Custom Detection et Suppression Rules. Les conditions de streaming, le circuit breaker, les limites de prévisualisation et le retour arrière y sont traités séparément des règles Classic conservées ici.